[Openswan dev] DNSSEC (was Re: [ldns-users] function call backs in ldns_resolver_send*?)
paul at xelerance.com
Wed Dec 15 11:09:48 EST 2010
On Wed, 15 Dec 2010, Miek Gieben wrote:
> My current view is the following. I think we should seperate the two
> o normal (plain DNS) resolving
> o DNSSEC validation
> So any app. just uses the DNS as it always has done and displays that
> information (a dns packet, a webpage, whatever) to the user. When
> security is needed, extra lookups are performed and the crypto is
> checked. And when this dane-protocol works you can check that too.
I assume you do mean that spoofed answers give a servfail and you go investigate?
> With this info you can then create a colored lock symbol.
> So the way forward would be to use libunbound IMHO and create
> only two functions:
> o is_this_secure(DNSKEY record), gives back yes/no, checks the chain
> o is_this_secure_dane(SSL cert), gives back yes/no, uses the dane protocol
In the case of firefox, I think what is going to happen is that DANE based cert/keys
are going to be treated as DV certificates, and their validation forks based on the
equivalent of using both is_this_secure() and is_this_secure_dane(). Additionally, if
any cert info is filled in (eg CN, O, OU) then since they might present it to the user,
they also want to validate that, so they need to walk the CA path as well. So for
DANE based certs, it is best to leave all of that empty.
Hoever, my question was more, where does the validating code and cache live? Should
openswan keep caches of the DNSKEYs in their lookup mechanism? Should it do validation?
Should it just trust the AD bit if resolver is localhost and use a local resolver, or
something in between like evldns/stubunbound where most of the "resolver" is linked into
Keeping the validating resolver within openswan protects against bad resolvers on the
host, at the expense of sharing the cache, which if any other application does similar
resolves, ends up with duplicated caches of infrastructure lookups.
In short, should openswan link a secure resolver library and cache, or trust the AD bit
on localhost? (or other last mile solution IETF comes up with)
More information about the Dev