Marsh Ray wrote: > > On 10/04/2010 09:37 AM, Martin Rex wrote: > > > > 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.
In order to get a TLS server cert issued for a particular DNS f.q.d.n under most of the existing pre-configured trust anchors, you only need to provide some vague proof that you leased that DNS domain. The no-prompt server endpoint identification will ignore any information in the cert besides the DNS f.q.d.n, no matter how carefully that other part of information may be validated. > > > 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? No. For the existing specs, this issue fell into the huge "out-of-scope" gaps between rfc-2818, PKIX and TLS. I know there is a school of thought popular in the US that is build around "but it didn't come with a warning label that I must not shoot in my foot, so it isn't my fault". I assume that _very_ few of those TLS-enabled servers that offer TLS client cert authentication, base their authorization decision on only one particular certificate attribute and ignore all the rest of the certificate and allow it to chain to arbitrary CAs operated under any one of >100 pre-configured trust anchors. But for the server side, no-prompting usability has always been deemed MUCH more important than security. > > > 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. That only affects the frequency of the key/cert rollover, not the fact that key/cert rollover needs to be addressed. Distributing an organizations CA cert through DNS instead of the server certs is somewhat incompatible with how a lot of traditional PKI software works (like Microsoft's CryptoAPI on XP/2003). PKIX specs define certificate path validation only when you have a certificate chain to one of your trust anchors. You probably will _NOT_ want most of these CAs a trust anchor, even when you might allow the use of such organizational CA certs for verification of specific server certificates. I once received an S/Mime signed Email in Outlook 2003, and the signature included an end-entity and an intermediateCA cert. I found myself unable to make Outlook verify the digital signature of that Email, because of a lack of the (non-public, organizational) RootCA cert for that chain. > > Say, what's the link to the Internet Draft proposal we're discussing anyway? To me it sounded like it is a post-prototype implementation, pre-draft discussion about the charter of the "keyassurance" WG. -Martin _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
