There are a couple of scenarios we need to keep in mind: 1. Existing HTTP/1.1 exchanges over upgraded TLS clients. If we need a brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 1.3, that’s fine.
2. Client authentication in HTTP/2. Slightly longer RFC for this (but possibly the same one) that says post-handshake client auth is allowed for HTTP/2, then describing how to use the context (and new HTTP/2 frames, if needed) to bind the PHA exchange to one or more streams. 3. Secondary server authentication in HTTP/2. This approach still doesn’t give a clean way to do this, unless we use exporters and roll our own. That has proven to be a little hazardous to everyone’s peace of mind, but remains something we can refine in the future. What concerns me more, though, is the prospect that a lot of TLS implementations would simply omit support. Obviously, it’s not used in most HTTP sessions, and you may be an implementation whose niche doesn’t require supporting it – but since the application profile allows it, you still need to know how to decline if asked. If it’s allowed in HTTP, which I assume is a supported workload for most implementations, then it’s allowed in your application profile and therefore prohibiting it by default doesn’t seem like it buys you much. Having a simple way to disclaim support, either at connection time or upon receiving a challenge, seems like it provides more simplicity for the implementations that want to omit it. From: Andrei Popov Sent: Tuesday, October 11, 2016 11:09 AM To: Eric Rescorla <e...@rtfm.com>; Hannes Tschofenig <hannes.tschofe...@gmx.net>; Mike Bishop <michael.bis...@microsoft.com> Cc: tls@ietf.org Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) + Mike who has additional concerns with this. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Tuesday, October 11, 2016 10:22 AM To: Hannes Tschofenig <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) I think it would be simpler (and deal with most cases) to only allow this for specific application profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC). Here is a PR for this: https://github.com/tlswg/tls13-spec/pull/680 Andrei, would this cause you any problem? My impression was that this use case was only about HTTP/H2. Thanks, -Ekr On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote: Hi Nick, given my discussion with Martin in this thread https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like your idea of making the post-handshake messages optional since it allows me to develop a TLS 1.3 client that is smaller in code size. Ciao Hannes On 10/08/2016 03:03 AM, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is > an attempt to make the story more explicit by adding a new > post_handshake extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable > are not needed. Some types of connections/implementations don't need to > support key updates (some unidirectional connections), session tickets > (pure PSK implementations) and post-handshake client auth (most > browsers). These are all currently SHOULDs in the spec and they don't > need to be. > > In order to simplify the logic around dealing with post-handshake > messages, this proposal makes support for each of these modes explicit > via a new handshake extension. This change also makes the path to > introducing other types of post-handshake messages in future drafts more > explicit. > > PR: > https://github.com/tlswg/tls13-spec/pull/676 > > Nick > > > _______________________________________________ > TLS mailing list > TLS@ietf.org<mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
