On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote: > Re-adding the list.
Removing one level of quotes. > On Wed, Apr 4, 2018, 22:34 Nico Williams <n...@cryptonector.com> wrote: >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> > I don't think that this comparison is particularly apt.The >> > representation in HSTS is simply "I support HSTS". The representation >> > in HPKP is "I will use either consistent keying material *or* a >> > consistent set of CAs". The representation here is "I will continue to >> > have DNSSEC-signed DANE records". That is a significantly more risky >> > proposition than continuing to support TLS (and I'm ignoring the risk >> > of hijacking attacks that people were concerned with with HPKP), and >> > so this seems rather more like HPKP to me. >> >> Without a TTL (with zero meaning "clear the pin to DANE") this extension >> can only really be used with mandatory-to-use-with-DANE protocols, where >> the commitment to "continue to have DNSSEC-signed DANE records" is >> implied. > > This is just not true. As I said in my earlier message, servers can > switch based on the ClientHello. > > Clients advertise which methods they support, servers switch, and they > both see how often DANE gets used. When it gets high enough, they turn off > the fallback. Just like every other TLS feature we've ever done. If clients and servers just negotiate the use of DANE, then there's a downgrade attack when DANE is the only outcome desired by the server operator but some WebPKI CA is willing to issue a rogue certificate for it. That downgrade is a fatal flaw for any protocols where this extension isn't mandatory. QED. We cannot be serious about security while promoting a protocol with a glaring downgrade attack. The TTL with pin-to-DANE semantics alleviates this by allowing the use of DANE to become mandatory-like for some time after first-use. It's TOFU-ish (Trust On First Use). TOFU has worked rather well for some protocols, and it will probably work well in the future. This mechanism to make this extension mandatory-for-some-time negates the downgrade attack *and* simultaneously provides a path to undo the use of DANE -- something that operators can reasonably be expected to demand for any protocol where this extension is not mandatory. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
