Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Viktor Dukhovni <> Thu, 01 March 2018 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06C0C12FADA; Thu, 1 Mar 2018 13:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bXVNuas5j9VM; Thu, 1 Mar 2018 13:51:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B73CB12FAD0; Thu, 1 Mar 2018 13:51:10 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F2E997A3309; Thu, 1 Mar 2018 21:51:03 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 01 Mar 2018 16:51:03 -0500
Cc: Nico Williams <>, tls-chairs <>,, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> <20180228200707.GF8921@localhost> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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, 01 Mar 2018 21:51:26 -0000

> On Mar 1, 2018, at 2:13 PM, Shumon Huque <> wrote:
>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <> wrote:
>> IF there's an objection to modifying the extension in order to add a
>> pin-to-DANE TTL field, I would propose the following instead:
>>    Make the pin-to-DANE be "forever" but make it so it can easily be
>>    cleared if DANE is undeployed for the service.
> This option is already covered in the draft. It doesn't use the term pinning,
> but does mention caching the existence of DANE on first contact and 
> requiring it subsequently (if clients want to do so).
> I do not know if the draft authors and/or WG have an appetite to do the much 
> more major change suggested by Viktor (i.e in-protocol pinning TTL commitment
> and requiring subsequent denial of existence proof if DANE is removed).

Avoiding an explicit TTL, and clients unilaterally assuming the DANE extension
will always be available is not IMHO a good idea.

Websites that initially implement the extension should be able to eventually
stop using it, if for some reason they decide that they no longer want to do
so.  While the server can clear the caches of clients that see a denial of
existence of the TLSA records, or proof an unsigned delegation from a parent
domain, without a max TTL there are always clients that have not yet connected
since the policy change, and will be broken indefinitely if the extension is no
longer delivered.

Therefore, any long-term caching of a destination's support for the extension
should require server opt-in, and must have a maximum duration.