Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]

Viktor Dukhovni <> Thu, 12 April 2018 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 260DD12D9FE for <>; Thu, 12 Apr 2018 11:53:18 -0700 (PDT)
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 F3Kxbx7uUB7u for <>; Thu, 12 Apr 2018 11:53:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59420126C83 for <>; Thu, 12 Apr 2018 11:53:16 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A7B4F7A3309 for <>; Thu, 12 Apr 2018 18:53:15 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 12 Apr 2018 14:53:14 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
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: Thu, 12 Apr 2018 18:53:18 -0000

> On Apr 12, 2018, at 2:44 PM, John Gilmore <> wrote:
> If any ever did, the future RFC could specify
> how servers which do not have validated TLSA records should handle the
> situation.

They'd have to violate the text of this draft:

> Different future protocols might choose different ways
> to handle this (e.g. don't send the extension at all; or send a validated
> denial;

The draft precludes sending denial of existence in Section 3.4 which
requires to the first RRset to be the requested TLSA records.  Hence
option (A) in the initial last-call announcement.

> or send some kind of flag saying that the server doesn't even have
> a validated denial because it isn't using DNS

That'd be vulnerable to downgrade, defeating the purpose of this
extension to support DANE.

> or because some domain on
> its path to the DNS root isn't doing DNSSEC or isn't using NSECx records).

This can be handled by sending denial of existence.  The denial of existence
can either prove lack of TLSA records in the server's signed zone, or can
prove lack of signatures on that zone.

> Please, let this RFC go, rather than requiring that this committee
> first insert into it a paper spec for what some future protocol should
> do, without even knowing what the future protocol is.

The present draft limits its own applicability, and neither (A) nor (C)
close off future options.  Indeed (A) specifically lifts an unfortunate
restriction, and (C) provides additional information from the server that
would be quite useful to clients.  It is hard to see how either preëmpt
future use-cases.