Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla <[e-mail]>]

On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams <[e-mail]> 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 <[e-mail]>
> 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
> --
>