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

[Nico Williams <[e-mail]>]

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.

The TTL with pin-to-DANE semantics alleviates this by allowing the use
of DANE to become mandatory-like for some time after first-use.  It's
TOFU-ish (Trust On First Use).  TOFU has worked rather well for some
protocols, and it will probably work well in the future.

This mechanism to make this extension mandatory-for-some-time negates
the downgrade attack *and* simultaneously provides a path to undo the
use of DANE -- something that operators can reasonably be expected to
demand for any protocol where this extension is not mandatory.

Nico
--