Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Viktor Dukhovni <> Tue, 27 February 2018 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40AE1126C22; Tue, 27 Feb 2018 08:11:29 -0800 (PST)
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 Txu3V-MBOI5T; Tue, 27 Feb 2018 08:11:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A32F61243FE; Tue, 27 Feb 2018 08:11:27 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 559127A3309; Tue, 27 Feb 2018 16:11:26 +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: <>
Date: Tue, 27 Feb 2018 11:11:25 -0500
Cc:, tls-chairs <>, The IESG <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Tue, 27 Feb 2018 16:11:29 -0000

> On Feb 27, 2018, at 10:47 AM, Willem Toorop <> wrote:
>> If this protocol has no denial of existence, I don't see any reason
>> for anyone to deploy it.  Why publish something that's basically
>> useless?
> Well.. support of the option could be obligatory for new TLS services,
> like DNS over TLS.  With DNS over TLS there is no user interaction
> making third-party PKIX (i.e. a CA store) impractical.

Sure, if restricted to applications in which the extension is mandatory,
the problem goes away.  But much of the appeal of this specification was
I believe that it would finally make it possible to do use DANE between
a browser and web server, and without authenticated DoE, it falls well
short of at least that goal.

> Note that the new initial draft (not WG yet) for encrypting the path
> from the recursive to the authoritative, suggests DANE authentication of
> the authoritative, and references the tls-dnssec-chain-extension draft
> as the initial method -of acquiring the needed DNSSEC data- to try:

This is a very different context from that faced by most other application
clients.  Here the client is a DNS server (iterative resolver) talking to
authoritative servers, and sending the TLSA records over TLS is just an
optimization, the client can retrieve these separately.

> Also, with DANE I like the fact that a DNS domain holder/owner can vouch
> for it's own domain name instead of needing a third party.  And
> although, opposed to DANE over DNSSEC, this extension doesn't add any
> security, it still has that property.

For existing applications, with a deployed base of PKIX (WebPKI) servers,
this extension provides no secure upgrade path.  This problem severely
limits the utility of this extension.  I now think we can and should do

Otherwise, this specification will not be a suitable basis for DANE-based
peer authentication in HTTPS, except for a narrow set of situations in which
DANE is required by some out-of-band external mechanism.

I think it makes sense to add a DANE latch TTL to the server's response,
which communicates to the client that the server commits to continue to
support the extension for some time considerably in excess of the TLSA
record TTL.  The client can cache that commitment for use with future
connections to the server.  With that in place, we get meaningful
applicability to HTTPS as used by general-purpose web browsers.

Or have we given up on ever using DANE for HTTPS in browsers?