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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
