Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Viktor Dukhovni <> Wed, 17 October 2018 01:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 340A8130E63 for <>; Tue, 16 Oct 2018 18:24:08 -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 oQR9tYQLCNw7 for <>; Tue, 16 Oct 2018 18:24:06 -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 6F8951271FF for <>; Tue, 16 Oct 2018 18:24:06 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 684992C21B for <>; Tue, 16 Oct 2018 21:24:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni <>
In-Reply-To: <20181017010720.3C81D2006F8412@ary.qy>
Date: Tue, 16 Oct 2018 21:24:04 -0400
Content-Transfer-Encoding: 7bit
Reply-To: "<>" <>
Message-Id: <>
References: <20181017010720.3C81D2006F8412@ary.qy>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-Mailman-Version: 2.1.29
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, 17 Oct 2018 01:24:08 -0000

> On Oct 16, 2018, at 9:07 PM, John Levine <> wrote:
> Something like "require DANE certs until time N" should be plenty.
> Remember that you can also unpin by publishing a signed NXDOMAIN or
> NODATA.  Since you need to have DNSSEC working to get the pin in the
> first place, that doesn't seem unduly onerous.

To be clear the "require DANE certs" above only holds so long as the
TLSA records remain published.  Since providing proof of non-existence
clears the pin, what's really pinned is the extension (and even then,
many clients will be able to recover by making independent DNS lookups).

So there's no discord here between "require DANE certs" and "just
pin the extension", the two are equivalent, because the former
really means "require the extension and if signed TLSA records are
present require DANE, else, with valid denial of existence, clear
the pin".

So regardless of how we frame it, the behaviour after first contact is
the same, that is:

  * Apply DANE in a downgrade-resistant manner when published
  * Drop pins and revert to default behaviour given valid denial of

So far, no substantive issues have been noted with the proposed pinning
approach to downgrade resistance (which bears no resemblance to HPKP).

All that remains is agreement on a maximum time limit (by setting the time
unit to max_time/2^16), and perhaps some sort of gradual scaling up of
that limit (if concerns about hijacking before the extension is widely
available in server software are deemed sufficiently compelling).