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

Viktor Dukhovni <> Wed, 25 April 2018 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2839126DEE for <>; Wed, 25 Apr 2018 08:19:38 -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 3HUoq64PEpyP for <>; Wed, 25 Apr 2018 08:19:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5CB91267BB for <>; Wed, 25 Apr 2018 08:19:36 -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 C26127A3309 for <>; Wed, 25 Apr 2018 15:19:35 +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: Wed, 25 Apr 2018 11:19:35 -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: Wed, 25 Apr 2018 15:19:39 -0000

> On Apr 25, 2018, at 10:02 AM, Willem Toorop <> wrote:
> We're actually working on
>> if there's interest in me doing that.  Below I list OLD/NEW text
>> chunks with the name of the section in which they fit.
> If you do, could you please make separate pull requests for denial of
> existence and another one for the lifetime field.

I'll try to get that done.  Thanks for the right repository pointer.

> Are you sure 16 bits is enough?  Other STS specs appear to use seconds
> for the max-age directive.

Yes, I'm sure that 16-bits is enough.  This is because an extension support
lifetime measured in seconds makes little sense, once this gets below an
hour it is commensurate with and often smaller than the TTL of the TLSA RRset.

There's no point in "pinning" the extension for a shorter time, the client
can just cache the TLSA records instead. The point of the extension support
lifetime is for ongoing downgrade resistance *beyond* the DNS TTL of the TLSA
records.  16 bits of hours is sufficient for a commitment between 1 hour and
7.5 years.

> They are also extensible with new directives
> (which have been introduced too, to overcome initial unforeseen
> limitations (i.e. preloading)).

Here I'm proposing a simple and general mechanism broadly applicable to
all TLS applications.  It would cover, for example, downgrade protection
for SUBMIT, POP, IMAP and XMPP clients.  There is deliberately no support
for including sub-domains as that would likely drag in the public suffix
list as a co-requisite and complicate deployment.

Preloading is rather browser-specific, and can be handled at the HTTPS
layer if desired.  Preloading only scales to the extent that it is not
too popular.

> Why do you require the SOA?  It is not needed for the denial of
> existence (or insecurity) proof.  NSEC ttls tell how long to cache the
> non-existence so it is not needed for the minimum field either.

You're probably right about that, the NSEC or NSEC3 records are required
to carry the same negative TTL (also limited by the RRSIG original TTL
and RRSIG expiration).  So probably the SOA can be omitted, with the NSEC
or NSEC3 records first after the relevant DNAME/CNAME chain.