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

[Eric Rescorla <[e-mail]>]

On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams <[e-mail]> wrote:

> On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote:
> > Re-adding the list.
>
> Removing one level of quotes.
>
> > On Wed, Apr 4, 2018, 22:34 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 is just not true.  As I said in my earlier message, servers can
> > switch based on the ClientHello.
> >
> > Clients advertise which methods they support, servers switch, and they
> > both see how often DANE gets used.  When it gets high enough, they turn
> off
> > the fallback.  Just like every other TLS feature we've ever done.
>
> If clients and servers just negotiate the use of DANE, then there's a
> downgrade attack when DANE is the only outcome desired by the server
> operator but some WebPKI CA is willing to issue a rogue certificate for
> it.
>
> That downgrade is a fatal flaw for any protocols where this extension
> isn't mandatory.
>
> QED.
>
> We cannot be serious about security while promoting a protocol with a
> glaring downgrade attack.
>

Unfortunately, you are conflating the assertive and restrictive use cases.

To recap, there are two potential reasons why one might want thi
technology:

1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
a pain). This rationale was stronger back before Let's Encrypt, but
I suppose some people may still feel that way.

2. Restrictive: To protect yourself from compromise of the WebPKI.

Yes, if your motivation is #2, then the flow you suggest is a real problem,
but it's not a problem for #1. While not an author of this document, I'd
understood it's primary motivation to be #1, and that's what Richard's
earlier notes have said as well.

-Ekr