Re-adding the list. On Wed, Apr 4, 2018, 22:39 Richard Barnes <r...@ipv.sx> wrote:
> > > 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. > > --Richard > > > >> 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. >> >> Nico >> -- >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
