Re: [TLS] Draft updates: tls-dnssec-chain

Paul Wouters <> Sat, 28 April 2018 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5006F1276AF for <>; Sat, 28 Apr 2018 11:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 LnYKxXKRsKh2 for <>; Sat, 28 Apr 2018 11:34:56 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30C4F126DFB for <>; Sat, 28 Apr 2018 11:34:51 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 40YKGd23yrzCq8; Sat, 28 Apr 2018 20:34:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1524940489; bh=Dj8/klsRFIZB3xiVuABUxf6itooYf/Ad/kEIHbt8IYA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K6/gTJdZkFfhxSf05zLVOmn+eNjSvNtNGkAsvx7yqNbiFO5XOnwZjeRu3Ng7i+h7X 9OeOdO4W3JtO3rh3GsO/UCqDZooxcOi/Q32vtI5Y5olWj1/94A88oGIdi/HqKqB9oV h75qiraQG+XX2/RyphDfdKeRQT6oxUff31nkt4cc=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Fp4rkAVQQW4E; Sat, 28 Apr 2018 20:34:47 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sat, 28 Apr 2018 20:34:46 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 167E661CD5; Sat, 28 Apr 2018 14:34:45 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 167E661CD5
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E8DC40C1031; Sat, 28 Apr 2018 14:34:45 -0400 (EDT)
Date: Sat, 28 Apr 2018 14:34:45 -0400
From: Paul Wouters <>
To: Shumon Huque <>
cc: TLS WG <>, Joseph Salowey <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [TLS] Draft updates: tls-dnssec-chain
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: Sat, 28 Apr 2018 18:34:59 -0000

On Sat, 28 Apr 2018, Shumon Huque wrote:

>    TLS servers that do not have a signed TLSA record MAY instead return
>    a DNSSEC chain that provides authenticated denial of existence.  This
>    specification does not require TLS servers to provide such a denial
>    of existence chain,

The second sentence is just repeating the MAY and is not needed.

But more importantly, it does not specify what the extension content
should be in the absense of a signed TLSA record and not wanting to
put in the denial of existene. Are you expecting an empty payload?
A single NULL payload? Or are you expecting the extension should be
omitted entirely? And what is the expected client behaviour in that case?

>     otherwise it could not be deployed incrementally
>    in environments where not all TLS servers support this extension.

It can be deployed incremendally as Viktor, Nico and I have shown
repeatedly with a two byte value.

>    Authenticated denial chains include NSEC or NSEC3 records that
>    demonstrate one of the following facts:
>    o  The TLSA record does not exist.
>    o  There is no signed delegation to a DNS zone which is either an
>       ancestor of, or the same as, the TLSA record name.

"s/one of the following facts/either"

>    In the absence of such a proof, a TLS client
>    misdirected to a server that has fraudulently acquired a public CA
>    issued certificate for the real server's name, could be induced to
>    establish a PKIX verified connection to the rogue server that
>    precluded DANE authentication.  Application ecosystems where all TLS
>    servers are expected to implement this extension could require such
>    authenticated denial proofs to be delivered by TLS servers that don't
>    have signed TLSA records.

I think this belongs in the Security Section. It's a big security
problem and so should be explained in the Security Section.

> > 3. Remove current text about pinning
> * Remove client initiated pinning para from Section 8:
>   This paragraph was entirely deleted:
>    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.
>    Client applications could also employ a Trust on First Use (TOFU)
>    like strategy, whereby they would record the fact that a server
>    offered the extension and use that knowledge to require it for
>    subsequent connections.

And as stated before, removing this is not enough. You need to explain
what the expected client behaviour is when the extension appears and
disappears, either in this section, a seperate section, or the Security