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

Viktor Dukhovni <> Fri, 13 April 2018 04:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9D57126BF0 for <>; Thu, 12 Apr 2018 21:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4d7mcy2zS7Pn for <>; Thu, 12 Apr 2018 21:43:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22006124239 for <>; Thu, 12 Apr 2018 21:43:26 -0700 (PDT)
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 D53197A3309 for <>; Fri, 13 Apr 2018 04:43:25 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Fri, 13 Apr 2018 00:40:41 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <20180410235321.GR25259@localhost> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
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: Fri, 13 Apr 2018 04:43:29 -0000

> On Apr 13, 2018, at 12:07 AM, Melinda Shore <> wrote:
> I'm okay with putting denial-of-existence in there as a should,
> but I do feel strongly that pinning belongs in a separate document.
> As I  said earlier, I have a problem with putting features in protocols
> that  nobody intends to use.  It's bad enough when it happens by
> circumstance but doing it deliberately strikes me as a bad idea.

The great irony of the situation, is that present draft already
describes pinning:

   If TLS applications want to mandate the use of this extension for
   specific servers, clients could maintain a whitelist of sites where
   the use of this extension is forced.  The client would refuse to
   authenticate such servers if they failed to deliver this extension.

And I've seen no discussion or working group consensus to *prohibit*
such pinning, only observations that it would be rather fragile in

What my proposal (B) (really (C), since (B) requires (A) as a foundation)
provides first and *foremost* is the ability for servers to DISABLE
pinning, by giving clients an upper bound pinning TTL of 0.

If you don't want to see pinning, voice your support for (B) (really C)
and have servers send a TTL of ZERO!

Keep in mind that the proposed TTL is an upper bound, it is NOT an
obligation to pin, and therefore is always a restriction on pinning,
while at the same supporting a signal that pinning may be safe at
the server's discretion.

So this both serves the overall interoperability objectives voiced
by Eric Rescorla, allows servers to disavow any pinning and supports
future cases.  It is a win-win, and carries ZERO implementation cost,
on the server, if pinning is explicitly unwanted, just the field to
zero and move along.  On the client if no pinning is desired, just
ignore the TTL.  This feature is a win/win and carries no implementation
burden, and the document is about to get a revision for (A) and still
awaits an IANA code point assignment.

If we act promptly on both (A) and (B) (i.e. (C)) there'll be zero
additional delay.

I sympathize strongly with the desire to keep specifications lean
and mean, but that desire is misplaced here.  The technical details
do matter, and both supporting DoE and setting a max "pin" TTL are
well motivated, improve interoperability and allow the server to
opt-out of the sort of fragile ad-hoc pinning described in the draft.

So please, let's not allow the general argument to deafen us to the
specific context of this document.  Though it needs at least (A) it
also needs (B) (i.e. (C)).