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

Viktor Dukhovni <> Fri, 13 April 2018 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA9FD12D77C for <>; Thu, 12 Apr 2018 18:08:58 -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 9w75hcE1TPq4 for <>; Thu, 12 Apr 2018 18:08:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09B1C1205D3 for <>; Thu, 12 Apr 2018 18:08:57 -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 25F147A3309 for <>; Fri, 13 Apr 2018 01:08:56 +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: Thu, 12 Apr 2018 21:08:35 -0400
Content-Transfer-Encoding: 7bit
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 01:08:59 -0000

> On Apr 12, 2018, at 7:47 PM, Eric Rescorla <> wrote:
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *could* pin, in order to ensure interoperability the server
> would have to provide authenticated denial at the risk of connection
> failure with such clients. However the text also does not require that
> the server do so. Thus, a conformant client and a conformant server
> can fail if the server just stops using TLSA.

Section 8 already says that some clients may require the extension.
Providing denial of existence improves interoperability when all
that the client requires is the extension, and given denial of
existence might accept something else.

Servers that support the extension really ought to provide denial
of existence, if that's all they can do.  Rather than suppress the
extension, if the client demands the extension and the server can't
provide it, interoperability is lost either way.

If your concern is that the new text is "license" for the clients
to arbitrarily require the extension in applications where servers
have no reason to expect such behaviour, I have no objection to
text that says that "the foregoing does not constitute a license
for clients to require the extension where this is not expected
application behaviour" or some such.

The idea is however to encourage servers to provide the denial
of existence, because it may be useful, and is not less interoperable
than eliding the extension.  Giving license to clients to then
expect this from servers is not the intent here.  I'm trying to
sneak in underhanded pinning.  That's not the goal.

I'd like to see explicit pinning (or not) hints from the server,
so we don't need to play guessing games.  Servers that consistently
return a TTL of zero would then be at liberty to drop the extension
rather than deliver DoE (denial of existence) at any time.

In your shoes I'd strongly advocate for the pin TTL, and make sure
that it is set to zero by any servers that be sure to avoid the
concerns that you're expressing.  That way we don't have to play
guessing games about client behaviour.