Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 12 October 2016 07:11 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82C12946F for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 00:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_DgK9PEqed6 for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 00:11:07 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id A5194129421 for <TLS@ietf.org>; Wed, 12 Oct 2016 00:11:07 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 45550F98C; Wed, 12 Oct 2016 03:11:06 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 14B09200CC; Wed, 12 Oct 2016 00:10:58 -0700 (PDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Nick Sullivan <nicholas.sullivan@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "tls@ietf.org" <TLS@ietf.org>
In-Reply-To: <CAOjisRxMAyzEVG_0THV9q6R9EHtPNKk94OB+pOzH_Q3kyi-ZQg@mail.gmail.com>
References: <CAOjisRznhk-Fww=EnRg7zXO-zaHWyNgi0g+reRBj+y3ZOhwMhw@mail.gmail.com> <d267aa85-56fc-b7b0-dc1f-3373f3b0c563@gmx.net> <CAOjisRxMAyzEVG_0THV9q6R9EHtPNKk94OB+pOzH_Q3kyi-ZQg@mail.gmail.com>
Date: Wed, 12 Oct 2016 03:10:54 -0400
Message-ID: <87fuo2vy81.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Otqdcc860OGbnvnm2yGY1ZthHVM>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 12 Oct 2016 07:11:09 -0000
On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > The major thing that this proposal achieves is that it makes post-handshake > auth an optional part of the implementation. Instead of this, I would also > be in favor of a simpler change that modifies the text to say that > post-handshake CertificateRequest messages are fatal by default and only > permitted if the application permits their use in a given context (say if > the application is HTTP 1.1, only directly after requests). > > Embedded implementations may choose to simply fail on unexpected > CertificateRequests, and that way not have to implement any code around > post-handshake finished messages or updating the transcript when one > arrives. > > This default wording should also apply to other types of post-handshake > messages, though NST and KU could be exceptions that should always be > supported and non-fatal. I don't see the advantage of putting this on the wire during the intial handshake. In the HTTP case, either (a) the requested resource wants a new authentication or (b) it does not. If it does not want new authentication (b), no CertificateRequest message will be forthcoming. If it does want new authentication, then either (a.1) it requires it (meaning the HTTP request will fail if the client can't offer a good cert), or (a.2) it just hopes to send a different response based on some new authentication. in (a.1), the request will simply fail when the client can't send a client cert. So the the client needs to know how to at least reject it gracefully. This is the case even when the client fully implements client auth anyway, since it might not have a client cert available. I don't think it's too much to ask that implementations be able to reject a post-handshake CertificateRequest gracefully, even if they have no intention of ever implementing a proper Client Certificate response. Changes to the wire format here only seems to give a small advantage to the server in one corner case for HTTP (a.2, when the client has no implementation of post-handshake client certs): the server can confidently send the certRequest, knowing that the client will know how to deal with it. But now clients will also need to decide whether they should indicate "i do post-handshake client auth" even if they have no likely client certs available at the time of session establishment, and to keep track of how they signaled over the lifetime of the session (how does this interact with session resumption?). I don't think that's a complexity win overall. If we make it clear that TLS 1.3 clients MUST at least know how to gracefully reject a post-handshake Certificate Request, i think that leaves the ecosystem as a whole with less complexity, and reduces the fiddliness of the wire format. --dkg
- [TLS] Making post-handshake messages optional in … Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… David Benjamin
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… David Benjamin
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… Eric Rescorla
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Benjamin Kaduk
- Re: [TLS] Making post-handshake messages optional… Martin Thomson
- Re: [TLS] Making post-handshake messages optional… Tom Ritter
- Re: [TLS] Making post-handshake messages optional… Hannes Tschofenig
- Re: [TLS] Making post-handshake messages optional… Eric Rescorla
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Andrei Popov
- Re: [TLS] Making post-handshake messages optional… Mike Bishop
- Re: [TLS] Making post-handshake messages optional… Daniel Kahn Gillmor
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… Hannes Tschofenig
- Re: [TLS] Making post-handshake messages optional… David Benjamin