On Fri, Mar 22, 2013 at 07:30:57PM +0100, Guido Witmond wrote:
> > So no new OpenSSL library code is required to support this, if one
> > stares at the (lightly documented) OpenSSL API hard enough, but
> > still "IN TLSA x 0 0" looks unwieldy.
[ I should probably mention that my issue is even worse with "2 1 0".
I now have the public key of the TA, but as with "2 0 0" potentially
no TA certificate either in the server trust chain, or in the system
trust store. So now I need a new API to validate trust chains
starting from just a public key (which is worse than with "2 0 0",
where I need to inject a possibly missing TA certificate into the
trust chain.). ]
> I use the 2-0-0 right now to set the TLS-context to that certificate
> only.
Why "2 0 0" and not "2 1 1" (with the certificate configured in
your server chain)? So that instead of the TA cert coming from DNS,
it is explicitly included in the server's SSL/TLS HELO (response)?
> (No global CA's), so that only server certificates signed with
> that certificate will pass validation. The connection fails if the
> server certificate doesn't match when my connection is hijacked with
> a MitM.
The effect of "2 1 1" is the same, but the DNS data is much more
sensible, and the TA certificate is supplied during the SSL handshake
inline, rather than out-of-band via DNS.
> If I understand you correctly, dropping TLSA 2 0 0 (full
> certificates) means that I would have to connect to a server, learn
> its certificates in the handshake and then perform the hash
> verification against the TLSA-record.
Yes, you have to connect to the server either way. With "2 0 0"
the trust-anchor certificate is out-of-band in DNS, and the handshake
might omit the TA cert from the server response (send only the
stuff signed by the TA down to the leaf). With "2 1 1" just the
TA fingerprint is in DNS and the actual TA cert is in the TLS
handshake.
"2 1 1" does not tax DNS caches, especially when servers have certs
from multiple CAs and perhaps multiple versions of a CA when key
rollover happens. And it dramatically simplifies client-side
implementation, when the TA is not already in the system store.
> It could tempt some into
> adding a 'override tlsa-record validation' button later.
This is a non-sequitur.
> I have a very good use case to set the 2-0-0 certificate as the only
> certificate in the session connection context. It allows clients to
> limit their connections only to servers signed with the certificate
> from the TLSA-record.
Why is this better than "2 1 1".
> I call it Cryptographic Same Origin Policy.
How does "2 1 1" fail to serve the same need, with the server trust
chain containing the cert you publish via DNS?
A deployment guide for DANE should likely specify that domain owners
publishing "2 1 1" or "2 0 1" TLSA records MUST include the TA cert
in the server's configured trust chain. The "x y 0" RRs are a pain
to implement, and substantially increase the effectiveness of
DNS reply amplification attacks.
> I humbly believe that creating a new session context (with just a
> single CA-cert) for each session is the way forward. Having a single
> certificate store is the old way of the global 'Trusted' CAs.
I seems you're somehow confused, or I'm not understanding your
reply. The "3 1 1" and "2 1 1" use cases cover everything other
than how the mechanism for conveying the TA issuing certificate.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
