Re: Install DNS mappings based on TLS/IPsec?

Iljitsch van Beijnum wrote:

> On 2-aug-04, at 15:45, Joe Touch wrote:
> 
>> the use of the DNS for forward and reverse lookups is often to provide 
>> confirmation of identity.
> 
> Yes.
> 
>> To that end, DNSSEC is useful,
> 
> Sure, but that's not the point. The point is that requiring the presence 
> of a working DNS is dangerous. Obviously the set of working DNSSEC 
> implementations is smaller than the set of working DNS implementations 
> so adding DNSSEC only makes this part worse.

OK.

>> IKE relies either on X.509 keys (a different hierarchy) or preshared 
>> secrets. At best, all this does is move the problem (DNSSEC 
>> certificate hierarchy -> X.509 certificate hierarchy); 
> 
> This is an improvement as the X.509 hierarchy doesn't have to be 
> traversed in real time (barring caching).

How so? If the CA Certs aren't already imported, IKE won't accept them 
until they're verified. If they are, that's equivalent to DNS caching 
its keys, isn't it?

>> at worst, it exposes the endpoint to assuming identity when the 
>> pre-shared key could be open (compromised, or deliberate).
> 
>> I.e., it would be necessary (IMO) to limit this to identities 
>> exchanged by IKE/TLS based on CAs, not based on preshared keys. That 
>> may not be feasible.
> 
> I disagree. The ability to configure trust manually is very useful. 
> Obviously when trust is configured using a preshared key this means only 
> the configured identity must be injected into what the application 
> thinks is the DNS, not any arbitrary value the remote side comes up with.

I don't know how we could control where the identities get used based on 
the kind of trust that is provided - that's the concern.

>>> - the DNS is often insecure, so let the TLS or IKE derived 
>>> information override it to increase security
> 
>> The more independent trust mechanisms there are the less trust that 
>> results, IMO.
> 
> That depends on whether you do "or" or "and". Unfortunately, if you want 
> to optimize for avalability you need to do "or" rather than "and".

"or" usually decreases trust, in the sense that you can only assume the 
lowest common denomenator.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBDtBKE5f5cImnZrsRAi48AJ9VIYeZ4oEFel5L90tANe2x/cR4OQCgqgaj
viUzmDv1tSr3fD5Oc/q9+ec=
=NOnf
-----END PGP SIGNATURE-----