On 05/08/2017 11:45 PM, Ilari Liusvaara wrote: > On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote: >> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote: >> >>> - That automatic wait on 0-RTT failure seems just the kind of feature >>> that gets disabled. Furthermore, 10 second idle on connection is >>> going to trigger quite a bit of connection timeouts. >> I could believe that people would accept buffering data until the 1-RTT >> handshake finishes (combined with rate limiting on the number of >> connections with accepted 0-RTT data); I don't think people would accept >> "wait the full clock skew allowance", though. > Did I misread the thread-starter proposal for waiting the allowance?
No, I think you read it correctly (and I agree with you). I have a more detailed reply to the original message in a compose window, but it will not be done tonight. > I think the early data provisioning already has 0-RTT buffer size, for > the case the server buffers the 0-RTT data (this buffering obviously > destroys the utility, but if it doesn't occur on every connection...) > >>> - There seems to be no consideration how this interacts with 0-RTT >>> exporters (probably applications that accept 0-RTT will then use >>> 0-RTT exporters for the entiere connection, and those exporters have >>> seriously weaker properties). >>> >> Yeah, the 0-RTT exporter feels like a footgun waiting to be used. > Unfortunately, looks like some are planning to use it, in ways > seriously broken unless the server does full replay-caching. > :( :( :( Clearly we should make sure their documents prominently note the requirement for strong replay protection, but is there more we can do? -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
