On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 11 October 2016 at 07:57, Kyle Rose <kr...@krose.org> wrote: >> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin >> that the web is substantially broken without retry logic in the browsers, >> that naturally make application-level replay mitigation a necessity. But I >> don't think (nor do I think he claimed) that the same is true of all >> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be >> okay for browsers in particular given the other constraints under which they >> operate, it is probably not good to bake that into the API for the general >> case. > > The 0-RTT API in NSS allows a server to detect this transition. The > problem that I think David was referring to is that the specific > instant of the transition is lost when the multiple layers of stack > that sit on top of TLS get involved. > > If an HTTP client sends a request that relies on HPACK state that was > established during 0-RTT, is it a 0-RTT request? I'm going to go with > probably not. > > If an HTTP client sends the first octets of a message in 0-RTT but > completes the request after the handshake completes, is it 0-RTT? I > suspect that this again is not a concern. > > I agree that we should make it clear that 0-RTT data needs to be > treated specially. I would like to see someone propose some text > rather than read more vague emails on the subject.
See https://github.com/tlswg/tls13-spec/pull/694. This is for API guidance rather than applications, and definitely needs expansion. I don't think we can say anything about HTTP without more details. -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
