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

Willem Toorop <> Mon, 05 March 2018 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5646127275; Mon, 5 Mar 2018 01:32:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 hcNbxRuk5HuR; Mon, 5 Mar 2018 01:32:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0706126579; Mon, 5 Mar 2018 01:32:27 -0800 (PST)
Received: from [IPv6:2a04:b900:0:1:a86b:a966:fd9c:f460] (unknown [IPv6:2a04:b900:0:1:a86b:a966:fd9c:f460]) by (Postfix) with ESMTPSA id E3C858E96; Mon, 5 Mar 2018 10:32:25 +0100 (CET)
Authentication-Results:; dmarc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1520242345; bh=SBwUUZIryUuoFsxfoesWhzMHUJWhYcRSTIkf6b190w4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=sCws/xsch+NnAl/JhN5BNwTjT4Hb9HsJLOWcpTZlWhL4F3S9lLq5fWpl5uY4ZGRdH AI/r6wSO19upfzSdLZKnMO4cljkxVyP5DI4TVjqCbcVxaGZcm/LTI3gRBkePX4DfN9 uCU+AnOrIoSXQkEwetW6PWkJVTtmaHTnk5iNWAjQ=
To: Viktor Dukhovni <>, TLS WG <>
Cc: Nico Williams <>, tls-chairs <>,, The IESG <>
References: <> <> <> <> <> <> <> <> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> <20180228200707.GF8921@localhost> <> <>
From: Willem Toorop <>
Message-ID: <>
Date: Mon, 05 Mar 2018 10:32:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Mon, 05 Mar 2018 09:32:29 -0000

Op 01-03-18 om 22:50 schreef Viktor Dukhovni:
>> 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.

How do you (all) feel about using the expiry date on the RRSIG for the
TLSA to be used for this purpose?