Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Viktor Dukhovni <> Thu, 05 July 2018 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7723E130E79 for <>; Wed, 4 Jul 2018 19:08:57 -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 pJV5S_dXWVKT for <>; Wed, 4 Jul 2018 19:08:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B82C130E60 for <>; Wed, 4 Jul 2018 19:08:53 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 8C73629A1D4; Wed, 4 Jul 2018 22:08:52 -0400 (EDT)
Date: Wed, 4 Jul 2018 22:08:52 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-Mailman-Version: 2.1.26
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, 05 Jul 2018 02:08:58 -0000

On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:

> 3.  Do you support the proof of denial of existence text in the revision?
> The mechanism seems fine, but it doesn't seem to me that the specification
> is clear on what the semantics are. I think what they are is that you can
> configure the client to be in some "DNSSEC required" mode which will
> requires that the extension be returned and that it either (a) contain
> DNSSEC-signed records for the domain or (b) contain authenticated denial of
> existence. Is this correct? If so, I would be happy to have the text merged
> and then wordsmith this explanation.

More precisely, you can configure the client to require the extension,
and yet still interoperate with servers that (support the extension,
but) live in an unsigned zone, or live in a signed zone with no
TLSA records for the service in question.  The server just needs
to be able to return a denial of existence proof for the DS records
of a delegated containing domain or its TLSA records, respectively.

Agree that merging the text for further polish is a logical next step. 

> 4.  Do you support the new and improved security considerations?
> They seem like a good start. I'd be happy to have them merged and wordsmith
> them.