Re: [TLS] Separate APIs for 0-RTT

[Benjamin Kaduk <[e-mail]>]

+1 (with my vote for MUST).

-Ben

On 06/13/2017 01:57 PM, Andrei Popov wrote:
>
> Regarding RFC language, I think we could be more specific:
>
>  
>
> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data
> if the application has explicitly opted in;
>
> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data
> if the application has explicitly opted in;
>
> 3. When delivering 0-RTT application data to the application, a TLS
> implementation SHOULD/MUST provide a way for the application to
> distinguish it from the rest of the application data.
>
>  
>
> Or some better phrasing that our capable editor can craft😊.
>
>  
>
> Cheers,
>
>  
>
> Andrei
>
>  
>
> *From:*TLS [mailto:[e-mail]] *On Behalf Of *Benjamin Kaduk
> *Sent:* Tuesday, June 13, 2017 11:48 AM
> *To:* Ilari Liusvaara <[e-mail]>; Colm MacCárthaigh
> <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [TLS] Separate APIs for 0-RTT
>
>  
>
> On 06/13/2017 01:35 PM, Ilari Liusvaara wrote:
>
>     On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:
>
>         On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <[e-mail]> <mailto:[e-mail]> wrote:
>
>          
>
>             I have been operating under the impression that at least some application
>
>             profiles for early data will require that certain application protocol
>
>             requests (e.g., something like HTTP POST) must be rejected at the
>
>             application layer as "not appropriate for 0-RTT data", which requires the
>
>             application to know if the request was received over 0-RTT data.
>
>              
>
>          
>
>          
>
>         That's a really good point; you've changed my mind. It's obviously a good
>
>         idea to return a 5XX to a POST over 0-RTT and that would need this.
>
>      
>
>     I think the proper code to send is 400. The request is client error,
>
>     nor server error, so it is 4XX. And there does not seem to be suitable
>
>     4XX code, so it goes to catch-all client error code 400.
>
>      
>
>     For HTTP/2, refusing the stream (sending stream error 7 without sending
>
>     server headers)  is also a good choice, as this should trigger a
>
>     retransmission of the offending request (POST requests failed by
>
>     refusing the stream are retryable).
>
>      
>
>
> At least the http 0-RTT profile that I started writing was going to
> allocate a new 4XX error code for this purpose.  I am under no
> pretense that my version of such a document will resemble anything
> that finally gets published, though.
>
> -Ben
>