+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 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. Cheers, Tim -- Tim Jackson Senior Product Security Architect, MobileIron Inc. ________________________________ From: "Martin Thomson" <martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> Date: Thursday, June 15, 2017 at 5:16:29 PM To: "David Benjamin" <david...@chromium.org<mailto:david...@chromium.org>> Cc: "tls@ietf.org" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] Separate APIs for 0-RTT On 15 June 2017 at 08:23, David Benjamin <david...@chromium.org> wrote: > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a > way for the application to determine if the client Finished has been > processed. I'm going to throw my support behind this distinction. Though I would phrase this more simply as "the handshake is complete". _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
