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

Nico Williams <> Thu, 05 April 2018 02:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A566124BFA for <>; Wed, 4 Apr 2018 19:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w5K402GOKplQ for <>; Wed, 4 Apr 2018 19:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4F1412426E for <>; Wed, 4 Apr 2018 19:46:42 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 47033A00400F; Wed, 4 Apr 2018 19:46:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=Ou8lxpBHJhHH2L LYgVIsijPfE2Q=; b=RtoJfReNFTSTi4ThERQltvcFtoFOlVLUcqGVwuRilEed1U zwthfw60v5Zu7k4Hmoo/qw5M4QLYrCdQnnK0FatE0vwxSWI2sm6lr/g/BJG4Jr82 qpaAQsgL58dBYMWFncH24ksuj4CLYjahcE0XaaE8ycFuhUxMcu2BSqNbJVPD0=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id DBBCBA000B3C; Wed, 4 Apr 2018 19:46:41 -0700 (PDT)
Date: Wed, 04 Apr 2018 21:31:07 -0500
From: Nico Williams <>
To: Richard Barnes <>
Cc: "<>" <>
Message-ID: <20180405023106.GJ25259@localhost>
References: <> <> <> <> <> <20180405022007.GG25259@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Apr 2018 02:46:44 -0000

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

That downgrade is a fatal flaw for any protocols where this extension
isn't mandatory.


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.