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

Viktor Dukhovni <> Tue, 10 April 2018 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D07CA124B0A for <>; Tue, 10 Apr 2018 08:32:57 -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 8SaFtiWrAbPb for <>; Tue, 10 Apr 2018 08:32:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 318DE12DA06 for <>; Tue, 10 Apr 2018 08:32:56 -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 625C37A3309 for <>; Tue, 10 Apr 2018 15:32:55 +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: Tue, 10 Apr 2018 11:32:54 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <>
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: Tue, 10 Apr 2018 15:32:58 -0000

> On Apr 10, 2018, at 11:22 AM, Paul Wouters <> wrote:
> This hints at returning the proof of non-existence, but clearly even the
> authors are now saying they did not mean this and a server is not
> required to do this. Clearly the text needs clarification, and if it
> then leaves out denial of existence, it needs a justification for that
> as well.

Paul makes a good point.  If indeed at some later time (as Willem
suggests) a commitment to deliver the extension is made at some
application layer, then the underlying TLS extension code will need
to be able to return denial of existence of TLSA records when these
are deleted or not yet present.

And yet there is nothing in the document that describes returning
denial of existence for the requested TLSA records, except to
validate a wildcard TLSA RRset (which is still a positive response).
So indeed the present document does not support responses that are
a denial of existence *of the requested TLSA RRset*.

So at the very least this defect will need to be addressed, (option
(A)). This in no way weakens the imperative for (C) (both denial of
existence support and an extension support TTL).