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

[Nico Williams <[e-mail]>]

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.

> 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)

The problem remains: you're pinning to key material, which complicates
key management.

> 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).

I flubbed that up a bit.  With the pin you commit to continue to using
this extension for as long as the clients have pinned it (which you
control via the TTL).  You can actually stop signing your zone provided
that you continue to use the extension.

> > 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.

Nico
--