On Sun, May 05, 2013 at 12:46:10PM -0400, Paul Wouters wrote:
> If you trust the DNS for certificate information, then pinning is not
> needed. The whole idea behind pinning as I understood it was that people
> don't want trust the DNS.
I thought pinning had more to do with not trusting rogue/compromised
public CAs, than not trusting DNS. Or in any case little to do
with not trusting DNSSEC. But either way, publishing DANE TLSA
scales substantially better than pinning, so I agree that pinning
via DNSSEC makes little sense.
> I'm unclear what problem you are trying to solve. If you trust the dns,
> you don't need pinning. If you don't trust the dns, you cannot trust
> your new discovery scheme either?
The problem as I understand it is a generalization of DCE's CDS
which supported secure registration and discovery of DCE service
endpoints (which proto,addr,port hosts a particular service UUID).
We have MX records for SMTP and SRV records for Kerberos, LDAP, and now
also POP and IMAP. We also have NAPTR for SIP.
Now that TLS is potentially subject to one of two PKIs, when one
publishes a service address (whether directly as with a URL in an
HTML <a> element or indirectly via some sort of DNS lookup)
complications may arise when the address specifies TLS without
specifying the relevant PKI.
SMTP is lucky in that (email addresses unlike https URLs) can't
specify TLS, thereforre clients can use DANE to securely discover
support for DANE TLS, and thus have on hand not only the protocol
to use, but also the authentication parameters required to use it.
With other services, (where the endpoint is say an https URL) TLS
is signalled separately from DANE, and clients and servers may need
to support two PKIs in parallel at the same service endpoint.
The simplest solution, if one introduce new DNS-based service
location records, is to note that trusting the DNS is unavoidable,
since that's where one gets service location and security parameters.
Therefore, to the extent that any such new mechanism explicitly
specifies TLS, it should I think require and use some form of DANE
key management (be it TLSA or other forms public keys in DNS)
unconditionally. With new "better than SRV" records there is no
legacy install base to worry about.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
