On Fri, Jan 29, 2016 at 07:55:53PM +0000, David Benjamin wrote: > On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > 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?
No, it doesn't: The server auth block comes before the data sent, and this block authenticates the sender (which is the server). > 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). Also, there are some subtle attacks on TLS that only fail on client Finished, so client auth block is needed. > 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. That actually also depends on what kind of data is sent in 0-RTT. Some protocols might be unsafe in general case, but have restricted subset that is safe in 0-RTT. E.g. protocol banners (e.g. HTTP/2 prelude/SETTINGS) are in general safe. HTTP/2 also has other stuff that could be sent (e.g. preflights or any requests with user privilege). Or protocol could say that anything in 0-RTT is permanently locked to authority it was sent with (including possibly anonymous authority). IIRC, 0-RTT data is explicitly distinct from normal data. > 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. IIRC, there is no indication of assumed ALPN for 0-RTT... Also, 0-RTT data is also separate on client side. So in-handshake 1RTT auth is quite different for client than post-handshake auth. Also, I think there should be a way for client to request Certificate- Request, even without valid configuration. This is needed for M2M applications (and some interactive protocols as well). > [*] 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. Well, considering that they have no choice with TLS 1.2, I presume they will also go that way with TLS 1.3. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
