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

Benjamin Kaduk <kaduk@mit.edu> Mon, 05 November 2018 13:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DD88112D4E8 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 05:02:12 -0800 (PST)
X-Quarantine-ID: <BYosbhszP0s7>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BYosbhszP0s7 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 05:02:06 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C701298C5 for <tls@ietf.org>; Mon, 5 Nov 2018 05:02:05 -0800 (PST)
X-AuditID: 12074425-6f7ff70000004566-7c-5be03f4a8d85
Received: from mailhub-auth-1.mit.edu ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CF.CD.17766.B4F30EB5; Mon, 5 Nov 2018 08:02:03 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU []) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA5D21Ke000932 for <tls@ietf.org>; Mon, 5 Nov 2018 08:02:01 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA5D1voU029910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Mon, 5 Nov 2018 08:02:00 -0500
Date: Mon, 05 Nov 2018 07:01:57 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: tls@ietf.org
Message-ID: <20181105130157.GF54966@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUixCmqrOtt/yDa4PweWYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8Xv1d/aCGXIVJ29pNjC2S3QxcnJICJhI9L9uYu5i5OIQEljD JDH7+F0WCOcwo0Rvwxso5z2TxLV5t5hAWlgEVCSuLO5gBLHZgOyG7stA7RwcIgICEs0vxUDC wgJBEmc3n2IGsXmBNtx58YwFwhaUODnzCZjNLKAlcePfSyaQVmYBaYnl/zhAwqICyhJ7+w6x T2DknYWkYxaSjlkIHQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpWujlZpbopaaUbmIEhRG7 i+oOxjl/vQ4xCnAwKvHwFobcjxZiTSwrrsw9xCjJwaQkynvU9EG0EF9SfkplRmJxRnxRaU5q 8SFGCQ5mJRFeJTagHG9KYmVValE+TEqag0VJnHdSy+JoIYH0xJLU7NTUgtQimKwMB4eSBO9M O6BGwaLU9NSKtMycEoQ0EwcnyHAeoOEHQGp4iwsSc4sz0yHypxh1Obad6ZzBLMSSl5+XKiXO qw1SJABSlFGaBzcHFP8S2ftrXjGKA70lzGsFUsUDTB1wk14BLWECWnJPFmxJSSJCSqqBcdKN 4+VbQpeePa6ps7VlMY+gENvWS+59vwtlFsaXF15PZrw+6+C6iXEzGnTLCuepuKQ52ZRsbxXP W7yxQSr7ZOa0O7liyYvO3dO7XjD7lLjnWTOrzf/WrnobvZWFaVX92SuZCkd/9+n07xW7G3lA N7EqmHvum/2zfnYsTQ/18xbvfC5q/FbhoxJLcUaioRZzUXEiACutcx/aAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IU7g7vvTo-QzDmB4U8fF5LDoI3U>
Subject: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 13:02:13 -0000

Hi all,

I do not know whether Wednesday's discussions will end up in a place where
these thoughts will be useful, but in the spirit of having discussions on
the list, I decided to write up some thoughts I've been pondering for a
while.  Hopefully the written form will be more clear than if I had to try
to express them in the mic line, and perhaps they will even inspire
thoughts from other people as well.

That said, I recognize that I am posting this pretty late and the one day
between now and then is already packed with meeting sessions, so I do not
expect to have a complete discussion on the list before the Wednesday
session.  (As always, happy to be proven wrong.)  So...

Once we start talking about pinning of any sort, we move from this
extension just being "transport some DNS records" into conveying some
sort of additional semantics.

It seems that we have not really had a structured discussion about what
semantics and information flows we might or might not want to convey in
this extension (in one or both directions!), and I'm reluctant to consider
adding such semantics without such a discussion.

If we accept the premise that the intention of DANE as relevant in this
space is to allow the server to convey to the client the server's
preferences for how the client should authenticate the server, we may also
want to consider the case where a server operator wants to eventually get
to a DANE-only state where it can ignore the web PKI.  (There may not be
many or any servers that actually end up wanting to do this, but it's not
unreasonable to consider the possibility.)  In order for a server to do
that, the server needs to know that all clients are not only willing to do
DANE, but able to get the records they need, whether via this extension or
otherwise!  Without such information, the server risks breaking clients
with the transition, and not knowing what population of clients have been

Doing some brainstorming on what the client might be able to tell the
server in this space, I can come up with things like:

(1) the client is willing to use DANE to authenticate the server
(2) the client already has the DANE records it needs to do (1)
(3) the client needs the server to give it the DANE records to do (1)
(4) the client requires the server to be DANE authenticated
(5) the client already has the DANE records it needs to do (4)
(6) the client needs the server to give it the DANE records to do (4)
(7) the client is willing to commit to one or more of the above for some
    time period

Similarly, the server may want to indicate things like:

(a) the server wants to be authenticated via DANE (yes, this is just the
    contents of the DNS)
(b) the server can provide DANE/DoE records in a TLS extension
(c) the server will commit to (a) for some time
(d) the server will commit to (b) for some time

Some of these might be always a consequence of or very strongly implied by
the presence of some information (e.g, sending the extension probably
implies (1), and having TLSA records at all probably implies (a)).  My
understanding is that the pinning proponents want a field in the server
response that conveys (d).  Note that this does not necessarily imply (a)
or (c), at least not with the same timer!

I deliberately am not trying to come to a conclusion in this message, as I
am not confident that I have even come up with all the potential semantics
worth thinking about, and I think that any motion in this space should only
be taken with WG consensus.

I would love to hear others' thoughts on what I am missing from the above
lists, reasoning for/against including protocol elements to indicate
the listed semantics, and whether/which existing protocol elements already
convey which of the enumerated semantics.