Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

[Marsh Ray <[e-mail]>]

On 10/04/2010 09:37 AM, Martin Rex wrote:
> Phillip Hallam-Baker wrote:
>>
>> The problem with the DNSSEC path is that it is vulnerable to attacks against
>> the information input to the DNS system. The weakest link there is the
>> safeguards on registration of the DNS names.
>
> It seems that you do not realize that the entire TLS PKI security model,
> as far as the automatic / no-prompt "server endpoint identification" is
> concerned, has always been relying completely on that DNS data being
> accurate.

How do you figure that?

I can put an entry in /etc/hosts (do this all the time for testing) and 
DNS isn't even queried. Yet the server certificate is validated as usual.

> But keep in mind that few TLS clients (such as browsers), currently
> support "pinning" of PKIX-authenticated server certs, so that on future
> connects only the very same server cert (with user-authenticated
> attributes other than DNS f.q.d.n) will be accepted from that server.
> In is very common misbehaviour in TLS clients to accept arbitrary other
> server certs on future connects, as long as the DNS f.q.d.n matches.

Is there a spec saying this is invalid behavior?

> One thing that needs to be addressed/solved is the key/cert rollover
> for any TLS-Server, so that it is possible to list more than one
> server cert as "valid" for a Server through DNS, at least for the
> time of the transition/rollover.

If you're going to trust certs you get out of DNS, you might as well 
just put a self-signed organizational CA cert in there. Maybe that's 
what's being proposed.

Say, what's the link to the Internet Draft proposal we're discussing anyway?

- Marsh