Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

Viktor Dukhovni <> Tue, 06 November 2018 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79BFA130EE9 for <>; Mon, 5 Nov 2018 21:02:18 -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 1Ay0MUia3CX3 for <>; Mon, 5 Nov 2018 21:02:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60293130E95 for <>; Mon, 5 Nov 2018 21:02:16 -0800 (PST)
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 85C8F6B955 for <>; Tue, 6 Nov 2018 00:02:15 -0500 (EST)
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: <>
Date: Tue, 06 Nov 2018 00:02:14 -0500
Content-Transfer-Encoding: 7bit
Reply-To: "<>" <>
Message-Id: <>
References: <> <> <> <> <>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
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: Tue, 06 Nov 2018 05:02:25 -0000

> On Nov 5, 2018, at 10:27 PM, Benjamin Kaduk <> wrote:
> This seems to suggest that we may need more precise text in the
> document about what it is (and is not) trying to do.  The slides Sean
> posted for the Wednesday session note that fairly early in the timeline
> we thought:
>    Primarily aimed at making
>    DANE practical for HTTPS,
>    where last-mile considerations
>    on the client end are a
>    significant part of the adoption
>    barrier.
> Paul, are you proposing that this would only be PKIX-{EE,CA} to the
> exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

I think that deciding which DANE usage are most appropriate for
browsers is up to the folks who think deeply about Web browsers
and Web servers, and I would not presume to tell them which model
they should find more attractive.  My expectation would be that
they would be more comfortable with PKIX-{EE,TA}, because that
gives both the strongest security guarantee and preserves
certificate transparency as an option.

In SMTP, I got consensus for just specifying DANE-{EE,TA}, but
for HTTP I can well imagine a different outcome.  The key reason
for the divergence is that SMTP security depends critically on
the integrity of MX records, so if you DNS is compromised PKI
does not help much.

HTTP does not use MX, SRV or similar indirection, so the analysis
comes out differently.

This draft will not define a single approach for all applications,
that's up to the various application area specialists to figure out.