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

Viktor Dukhovni <> Wed, 04 April 2018 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3D6E126FB3 for <>; Wed, 4 Apr 2018 16:38:12 -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 xYgMvQ8O9fl0 for <>; Wed, 4 Apr 2018 16:38:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0F7D126C2F for <>; Wed, 4 Apr 2018 16:38:10 -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 031107A330D for <>; Wed, 4 Apr 2018 23:38:10 +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: Wed, 04 Apr 2018 19:38:09 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
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: Wed, 04 Apr 2018 23:38:13 -0000

> On Apr 4, 2018, at 6:12 PM, Melinda Shore <> wrote:
>> I support publication of the document as is.  I would also be
>> comfortable with a minor modification to say that TLSA certificate
>> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.
> The addition of text that clarifies that seems absolutely reasonable
> to me.

That addition is fundamentally flawed.  THere is no realistic scalable
adoption model in which a server publishes DANE-only certificates to
and expects thereby to support a meaningful set of clients that would
don't trust Let's Encrypt (for example).  Nor do I see the browser
community accepting DANE alone as a sufficient security mechanism.

> I do think there would be a problem with adding additional complexity

Ignoring a 16-bit field in the extension adds ZERO complexity.  Not
sending a denial of existence response and not accepting one if
given (in applications that don't need this feature) likewise adds
ZERO complexity.  The complexity argument is a mirage.

> to the extension to support functionality that nobody has said that
> they intend to use (including the proponents of the changes), given
> that the changes would not be introduced to correct an error in
> the existing spec.

The changes are needed to support the extension in any application
where adoption is necessarily incremental (i.e. all existing WebPKI
applications).  To refute that, one would need to refute the security
and cost-benefit analyses in my post and somehow demonstrate
"alternative facts" that establish the viability of an additive
model, and some other way to compensate for the fact the present
extension has a major downgrade hole.

It is precisely the "restrictive" use-case that Richard says can be
left out that users expect from DANE, that is tangible benefit over
and above just using WebPKI, from say Let's Encrypt.