Re: [TLS] Separate APIs for 0-RTT

[Benjamin Kaduk <[e-mail]>]

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.