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. > The TTL allows one to put a bound on that commitment, thus alleviating > the risk. > > That's the whole point: to alleviate the risk of commitment to DANE in > order to not discourage opportunistic deployment. > HPKP had a TTL and yet as a practical matter, people found it very problematic. And, of course, if you're concerned with hijacking attacks, the hijacker will just advertise a very long TTL. -Ekr Nico > -- >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
