On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams <n...@cryptonector.com> wrote:
> 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. > I've responded to this separately. > > 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. No, this isn't correct, in two respects. 1. HPKP pins the SPKI, not the certificate, it's about the *key* not changing, and intermediates and roots change quite infrequently. (https://tools.ietf.org/html/rfc7469#section-2.1.1) 2. It's not one key. HPKP allowed you to pin multiple keys and in fact *required* you to set a backup pin (https://tools.ietf.org/html/rfc7469#section-2.5) Whereas here you only have to commit to continue to publish > TLSA RRs (and signing them and your zone). This is a big difference. > I don't think that's it all obvious that this is going to be easier to guarantee, especially given the rather high DNSSEC misconfiguration rate (https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf, https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf). > 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. > Given that the motivation for this kind of hijacking was generally expected to be vandalism or ransom, this doesn't seem very comforting. -Ekr > Nico > -- >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
