On 06/22/2017 09:10 PM, Timothy Jackson wrote: > +1 and a preference for MUST, just so people understand the importance. > > Since we're agreed that 0-RTT data and 1-RTT data have (almost) the > same security properties once the handshake completes, it seems to me, > unless I've missed something, that a lot of protocols will accept > 0-RTT but withhold the response until after the handshake completes. I > expect this massively simplifies the analysis the for the app developers. > > Clientdata = readData() > Reply = CreateReply(client data); //time intensive operation (e.g. > Database, CDN cache lookup) > > While(!clientFinished()) > Wait(); //do nothing until 1-RTT finished > > Send(reply) > > This has the benefit of allowing slow lookups/processing to happen > against 0-RTT, while delaying the "risky actions" until after 1-RTT. > If I'm not mistaken, it would also make timing
This is still the server taking action on 0-RTT data before the handshake completes, using resources on potentially spoofed input. Caution is needed to not utilize excessive server resources in such cases. -Ben > attacks harder since any cache misses would be at least partly masked > by the time required for the 1-RTT handshake. > > Dual streams seems to just add complexity here. What I really care > about as a developer is whether I can fully trust the 0-RTT data, > which is determined by whether the handshake is finished.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
