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".

TLS mailing list

Reply via email to