Re: [TLS] Proposed text for dnsssec chain extension draft

Viktor Dukhovni <> Thu, 26 April 2018 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 013531243F3 for <>; Thu, 26 Apr 2018 06:51:50 -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 XTMQA-5O51qF for <>; Thu, 26 Apr 2018 06:51:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 595E912422F for <>; Thu, 26 Apr 2018 06:51:40 -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 886A07A3309 for <>; Thu, 26 Apr 2018 13:51:39 +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: Thu, 26 Apr 2018 09:51:37 -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] Proposed text for dnsssec chain extension draft
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, 26 Apr 2018 13:51:50 -0000

> On Apr 26, 2018, at 2:30 AM, Eric Rescorla <> wrote:
> If you look at HPKP and Expect-CT, you will note that there are a number of
> other fields besides just lifetime (report-uri, include subdomains). I recognize
> that opinions vary about whether these are good, but the advantage of having
> a whole new extension is that we need not resolve those now in order to move
> this document forward.

Let's ignore HPKP, as discussed previously it is a poor analogy
here, (and, not entirely surprisingly an impractical design).
A somewhat better comparison is Expect-CT or MTA-STS.

Both of these have a max-age.  Neither of them is "forever".  We
can safely assume that *any* mechanism to negotiate downgrade
protection for this extension between server and client will
have a finite duration.

Neither of the comparison specs are TLS extensions intended to cover
a broad range of applications.  They are single application policy
mechanisms communicated via HTTP headers.

Here, our scope is *all* end-user applications that choose to use
the DNSSEC chain extension to access the server's DANE TLSA

If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we

  * a lifetime field
  * enforce vs. test
  * a report URI

This specification is always "enforce" (though my pull request
changes a MUST use DANE to a SHOULD with some necessary added
conditions) and since the report URI is in good measure to
support non-enforce mode, we're back to just max-age.

> As far as I can tell, the primary disadvantage of a new
> extension is a slight increase in the size of the TLS handshake if the extension
> is used (balanced against two wasted bytes in this proposed design if it is
> not used). That doesn't seem like a good set of tradeoffs.

Well, here I appeal to Melinda's observation that specifications
need to closely consider implementation complexity, not just
specification complexity.  Indeed implementation complexity
should be the primary concern.

A major disadvantage of a separate extension (rather than
adding semantics to an existing field) is that implementations
will then need to add code to generate and consume a second
extension, integrate the new code point, handle combinatorial
logic of receiving either extension or both, ...

Including the field now removes the need to ask libraries to
add code for a second extension, complicating the API and
complicating the code that applications need to call to
make use of the combined data.

Worst case the chain extension carries an extra 16 bits of
zeros, which by the way explicitly signal: do not do
unilateral pinning.  There's really much too little to
object to and real potential benefit.