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).
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.
- 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".
Attachment:
signature.asc
Description: OpenPGP digital signature