On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote: > > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams <n...@cryptonector.com> > wrote: > > > > > > 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) > > Either way it's the same impact: you cannot roll that key over. > > Whereas with pin-to-DANE there's no such problem. I thought I made that > clear. > Yes, I agree that you're relying on a different guarantee from your parent zone, I just don't think it's particularly obvious that that guarantee is easier to ensure, for the reasons I indicated previously. > > 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. > > The motivation for opportunistically using this is to be able to > incrementally deploy DANE for HTTPS (and browsers). Without that it > won't get deployed at all for HTTPS. > I don't see how this is responsive to the concern that this technique will be used for hijacking. -Ekr > Nico > -- >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
