On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:20 PM, 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 simply isn't true, for the reasons Richard Barnes indicated in his > response > to you.
See my response to him. For any non-mandatory use of this extension, without the pinning semantics there is a glaring downgrade attack. > HPKP had a TTL and yet as a practical matter, people found it very > problematic. I can see why: you have to commit to one certificate in the chain not changing. Whereas here you only have to commit to continue to publish TLSA RRs (and signing them and your zone). This is a big difference. > And, of course, if you're concerned with hijacking attacks, the > hijacker will just advertise a very long TTL. But it's a TOFU-ish thing. The server impersonator has to have the right timing or else be detected -- that's very risky for them, and a deterrent to even trying. It's not fool-proof, but it's not nothing either. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
