On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams <n...@cryptonector.com> wrote: > > 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.
Sure it is. As long as the root zone is signed you can use this extension and prove that you are / are not using DANE. > > > 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. You're right. I believe this has been answered now separately by others, and also by me. This is not a pin-to-DANE feature we're asking for, but a pin-to-using-this-extension. I shouldn't have called it pin-to-DANE, but I did because it's short -- short, but not sufficiently pithy :( Now, it's true that an impersonator could force you to use this extension when you were not ready to, and that's a DoS, though an easy one to fix, relatively. I'll take that DoS over a downgrade attack. We could mitigate the DoS by saying that the pin TTL must be coerced to zero (or maybe 1) if the extension only bore an authenticated denial of existence. I would prefer to not have to do this, but I'd accept it. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
