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

[Eric Rescorla <[e-mail]>]

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