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

Viktor Dukhovni <> Thu, 05 April 2018 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91D8E127076 for <>; Wed, 4 Apr 2018 20:30:05 -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 v9D6NS3RF6Mq for <>; Wed, 4 Apr 2018 20:30:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C1EF126B6D for <>; Wed, 4 Apr 2018 20:30:03 -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 1C5EB7A330D for <>; Thu, 5 Apr 2018 03:30:03 +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: <20180405023456.GK25259@localhost>
Date: Wed, 04 Apr 2018 23:30:01 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <> <> <20180405022007.GG25259@localhost> <> <20180405023456.GK25259@localhost>
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: Thu, 05 Apr 2018 03:30:05 -0000

> On Apr 4, 2018, at 10:34 PM, Nico Williams <> wrote:
> I can see why: you have to commit to one certificate in the chain not
> changing.  Whereas here you only have to commit to continue to publish
> TLSA RRs (and signing them and your zone).  This is a big difference.

Even more strongly NOT ONLY do you not actually commit to publishing
TLSA records going forward since with (A) (denial of existence) you
can just prove they don't exist.  You can even stop using DNSSEC for
your domain entirely.  And yet still support the extension and just
furnish proof (again denial of existence) that your domain is no
longer signed (i.e. no DS records in the parent or ancestor thereof
as signed by that parent or ancestor).

THEREFORE, the pin is *precisely* just a capability pin (like STS),
saying I can present the extension, there is NO obligation to
provide any specific content in that extension.