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

Viktor Dukhovni <> Tue, 27 February 2018 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5F5912D965; Tue, 27 Feb 2018 07:12:18 -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 KdWWVuzG6pl5; Tue, 27 Feb 2018 07:12:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18D1612D77C; Tue, 27 Feb 2018 07:12:16 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 287BF7A3309; Tue, 27 Feb 2018 15:12:16 +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: Tue, 27 Feb 2018 10:12:15 -0500
Cc:, tls-chairs <>, The IESG <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
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: Tue, 27 Feb 2018 15:12:19 -0000

> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk <> wrote:
> There doesn't seem to be much interest in pinning-like schemes for TLS
> at this point (see also the "TLS server identity pinning" proposal from
> the SAAG/secdispatch session at IETF 100).
> And I do think the lack of authenticated denial of existence is
> something the WG was aware of during our earlier discussions, so it's
> unclear that there is a need to hold things up for this issue.

Awareness of is different from thinking through the full implications.
I for one did not have the cycles to consider all the implications,
and many others likely also focused on the data format, and may not
have considered the use-cases with care.

Note that DANE-based "pinning" is fundamentally different from other
"pinning" approaches, in that the client does not store the key
digests for any significant length of time.  All it may do is
cache the DANE TLSA records for a short time bounded by the DNS TTL.
The digests that "pin" the server's (or issuing CA's) keys are managed
in the server's DNS zone, and can be promptly updated by the server,
and the client can learn of the change when presented with new TLSA
records, OR as I now believe is essential for this specification to
be at all useful, presented with authenticated denial of existence.

The only thing needed for denial of existence to be workable, is
that the client cache a commitment by the server (a boolean value)
to support the extension until such time as the server provides
authenticated denial of existence of TLSA records.

This is much less brittle than client-side key pinning, with all
its attended problems with stale data.

If this protocol has no denial of existence, I don't see any reason
for anyone to deploy it.  Why publish something that's basically