On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote: > > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > > > martin.thom...@gmail.com> > > > > > > I don't think the two situations have the same problems: > > > - "Server 0-RTT" has _recipient_ identity change. > > > - "Dynamic reauth" has _sender_ identity change. > > > > > > You have more concrete examples of things going wrong with "server > > > 0-RTT"? Because I have major problems coming up with troublesome > > > cases. > > > > > > The client also has some 0-RTT data which, in the server 0-RTT case, the > > server reports was accepted and processed. That all is associated with > the > > first identity rather than the second. So I believe we have sender > identity > > change in both cases. > > The 0-RTT being sent under different identity than the application data > does involve sending identity change, but what does it have to do with > "server 0-RTT"? The client could do that (and run into trouble with > badly designed protocols) without "server 0-RTT". > Perhaps I misunderstood you. I read "dynamic reauth" in your message above as the post-handshake auth mechanism. You said that "server 0-RTT" has recipient identity change and "dynamic reauth" has sender identity change. My claim is that "server 0-RTT" also has sender identity change, since that seemed to be the question you were asking. Did you mean something else? Yes, by forbidding CertificateRequest on 0-RTT hit, we are not removing anything post-handshake auth can't do. That's largely my point. It is identical in both how it works in good or bad) and how early each message arrives (see https://www.ietf.org/mail-archive/web/tls/current/msg19159.html for comparison). I hope the more reasonable protocols without legacy burdens will declare that post-handshake auth is forbidden and only allow initial-handshake client auth or none at all, as SPDY and HTTP/2[*] did to renego in TLS 1.2. Yet it's not obvious CertificateRequest on a 0-RTT hit is equivalent to post-handshake auth and should be allowed or forbidden together. Also, although servers can choose never to do this, clients that implement post-handshake auth (like HTTP apparently) can't. This figures into the client API the TLS stack exposes. Despite being in the handshake, this flow should be exposed via post-handshake auth's API. This is weird, but handshake-negotiated properties otherwise have nice assumptions like being constant throughout the connection, should the client's stream depend on it. Consider ALPN. If a server wishes to pick a different ALPN value from the 0-RTT-predicted one, it must reject 0-RTT because that data's wrong anyway. I think the same should be true of in-handshake client auth. Since there is zero benefit to a using this handshake flow over already existing alternative (this handshake flow is not an optimization), I don't see how it can be worth this (or any) complexity. David [*] Sadly, HTTP's legacy burdens caught up to us. Although I see draft-thomson-http2-client-certs-01 has picked up again, so maybe HTTP/2 won't use post-handshake auth? Doesn't matter; new multiplexed protocol without such legacy would best forbid post-handshake auth.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
