Separate APIs for 0-RTT

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Separate APIs for 0-RTT

Eric Rescorla-3
The current text says:

   0-RTT data has very different security properties from data
   transmitted after a completed handshake: it can be replayed.
   Implementations SHOULD provide different functions for reading and
   writing 0-RTT data and data transmitted after the handshake, and
   SHOULD NOT automatically resend 0-RTT data if it is rejected by the
   server.

I think the second piece of guidance (about automatic re-send) is still good but it seems like implementations are mostly converging on a single API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have a single API and OpenSSL's use of two APIs is an outlier. I don't think it's helpful to have a SHOULD that a lot of people violate, especially when this also indicates we don't have consensus on this SHOULD.

I propose we remove this recommendation in favor of one which simply says that implementations should need applications to opt-in to 0-RTT. That would allow implementations to have either API.

-Ekr






_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Ilari Liusvaara-2
On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:

> The current text says:
>
>    0-RTT data has very different security properties from data
>    transmitted after a completed handshake: it can be replayed.
>    Implementations SHOULD provide different functions for reading and
>    writing 0-RTT data and data transmitted after the handshake, and
>    SHOULD NOT automatically resend 0-RTT data if it is rejected by the
>    server.
>
> I think the second piece of guidance (about automatic re-send) is still
> good but it seems like implementations are mostly converging on a single
> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
> a single API and OpenSSL's use of two APIs is an outlier. I don't think
> it's helpful to have a SHOULD that a lot of people violate, especially when
> this also indicates we don't have consensus on this SHOULD.
>
> I propose we remove this recommendation in favor of one which simply says
> that implementations should need applications to opt-in to 0-RTT. That
> would allow implementations to have either API.

I think it is VERY bad idea for TLS client library to do 0-RTT without
application explicitly opting in to that (e.g., via setting a special
setting, or using API call sequences that didn't work at all for
n-RTT).

Consider for example that:

- The application starts by sending a POST request.
- The application starts by sending a GET to confidential URL.

Both cases lead to things possibly going very badly wrong if TLS
library silently does 0-RTT. And both are kind of requests that might
be written before TLS connection is fuly up.

And if ALPN is included, there is always a possibility that the
initial guess on protocol was wrong, and the data can't just be
autoretransmitted, but TLS stack has to ask the application to
roll back the state.


The server side does not have as obvious failure modes if 0-RTT is
enabled without application knowledge, but that does not mean such
failure modes are not out there.



-Ilari

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Eric Rescorla-3


On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara <[hidden email]> wrote:
On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:
> The current text says:
>
>    0-RTT data has very different security properties from data
>    transmitted after a completed handshake: it can be replayed.
>    Implementations SHOULD provide different functions for reading and
>    writing 0-RTT data and data transmitted after the handshake, and
>    SHOULD NOT automatically resend 0-RTT data if it is rejected by the
>    server.
>
> I think the second piece of guidance (about automatic re-send) is still
> good but it seems like implementations are mostly converging on a single
> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
> a single API and OpenSSL's use of two APIs is an outlier. I don't think
> it's helpful to have a SHOULD that a lot of people violate, especially when
> this also indicates we don't have consensus on this SHOULD.
>
> I propose we remove this recommendation in favor of one which simply says
> that implementations should need applications to opt-in to 0-RTT. That
> would allow implementations to have either API.

I think it is VERY bad idea for TLS client library to do 0-RTT without
application explicitly opting in to that (e.g., via setting a special
setting, or using API call sequences that didn't work at all for
n-RTT).

I agree with this. I am suggesting that a setting rather than a separate API is a
reasonable approach.

-Ekr
 

Consider for example that:

- The application starts by sending a POST request.
- The application starts by sending a GET to confidential URL.

Both cases lead to things possibly going very badly wrong if TLS
library silently does 0-RTT. And both are kind of requests that might
be written before TLS connection is fuly up.

And if ALPN is included, there is always a possibility that the
initial guess on protocol was wrong, and the data can't just be
autoretransmitted, but TLS stack has to ask the application to
roll back the state.


The server side does not have as obvious failure modes if 0-RTT is
enabled without application knowledge, but that does not mean such
failure modes are not out there.



-Ilari


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Salz, Rich
In reply to this post by Eric Rescorla-3

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Eric Rescorla-3
On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <[hidden email]> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.


I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.


I was intending to use wording that was neutral between the two options without any claims about popularity.

Thanks,
-Ekr


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Steven Valdez
Confirming that BoringSSL is using a single API for early/regular data, since we ran into issues/complications with our implementation of dual APIs with our use cases.

On Tue, Jun 13, 2017 at 8:28 AM Eric Rescorla <[hidden email]> wrote:
On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <[hidden email]> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.


I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.


I was intending to use wording that was neutral between the two options without any claims about popularity.

Thanks,
-Ekr

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Andrei Popov
In reply to this post by Eric Rescorla-3

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

 

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?

 

This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…

 

Cheers,

 

Andrei

 

From: TLS [mailto:[hidden email]] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich <[hidden email]>
Cc: [hidden email]
Subject: Re: [TLS] Separate APIs for 0-RTT

 

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <[hidden email]> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.

 

I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.

 

I was intending to use wording that was neutral between the two options without any claims about popularity.

 

Thanks,

-Ekr

 


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Eric Rescorla-3
This would be fine with me.

-Ekr


On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov <[hidden email]> wrote:

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

 

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?

 

This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…

 

Cheers,

 

Andrei

 

From: TLS [mailto:[hidden email]] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich <[hidden email]>
Cc: [hidden email]
Subject: Re: [TLS] Separate APIs for 0-RTT

 

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <[hidden email]> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.

 

I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.

 

I was intending to use wording that was neutral between the two options without any claims about popularity.

 

Thanks,

-Ekr

 



_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Loganaden Velvindron
In reply to this post by Ilari Liusvaara-2
On Tue, Jun 13, 2017 at 2:54 PM, Ilari Liusvaara
<[hidden email]> wrote:

> On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:
>> The current text says:
>>
>>    0-RTT data has very different security properties from data
>>    transmitted after a completed handshake: it can be replayed.
>>    Implementations SHOULD provide different functions for reading and
>>    writing 0-RTT data and data transmitted after the handshake, and
>>    SHOULD NOT automatically resend 0-RTT data if it is rejected by the
>>    server.
>>
>> I think the second piece of guidance (about automatic re-send) is still
>> good but it seems like implementations are mostly converging on a single
>> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
>> a single API and OpenSSL's use of two APIs is an outlier. I don't think
>> it's helpful to have a SHOULD that a lot of people violate, especially when
>> this also indicates we don't have consensus on this SHOULD.
>>
>> I propose we remove this recommendation in favor of one which simply says
>> that implementations should need applications to opt-in to 0-RTT. That
>> would allow implementations to have either API.
>
> I think it is VERY bad idea for TLS client library to do 0-RTT without
> application explicitly opting in to that (e.g., via setting a special
> setting, or using API call sequences that didn't work at all for
> n-RTT).
>

I also agree here.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Benjamin Beurdouche
In reply to this post by Andrei Popov
Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of
“MUST" only enable 0-RTT application data upon explicit opt-in by the application...
My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future
and that being extra careful here is important… :)

Best,
Benjamin

On Jun 13, 2017, at 6:12 PM, Andrei Popov <[hidden email]> wrote:

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.
 
WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?
 
This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…
 
Cheers,
 
Andrei

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Andrei Popov
  • My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future
  • and that being extra careful here is important… :)

 

I agree with this assessment. A MUST would certainly work for me. There are two reasons I suggested SHOULD:

  1. A MUST would be non-enforceable (a TLS client or server can’t enforce the use of a particular API by the peer).
  2. There’s lack of consensus on the topic of 0RTT and I’m trying to suggest a compromise😊.

 

Cheers,

 

Andrei

 

From: Benjamin Beurdouche [mailto:[hidden email]]
Sent: Tuesday, June 13, 2017 9:50 AM
To: Eric Rescorla <[hidden email]>
Cc: Rich Salz <[hidden email]>; ML IETF TLS <[hidden email]>; Andrei Popov <[hidden email]>
Subject: Re: [TLS] Separate APIs for 0-RTT

 

Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of

“MUST" only enable 0-RTT application data upon explicit opt-in by the application...

My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future

and that being extra careful here is important… :)

 

Best,

Benjamin

 

On Jun 13, 2017, at 6:12 PM, Andrei Popov <[hidden email]> wrote:

 

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

 

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?

 

This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…

 

Cheers,

 

Andrei


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Benjamin Kaduk-2
In reply to this post by Eric Rescorla-3
That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.

-Ben

On 06/13/2017 11:29 AM, Eric Rescorla wrote:
This would be fine with me.

-Ekr


On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov <[hidden email]> wrote:

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

 

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?

 

This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…

 

Cheers,

 

Andrei

 

From: TLS [mailto:[hidden email]] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich <[hidden email]>
Cc: [hidden email]
Subject: Re: [TLS] Separate APIs for 0-RTT

 

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <[hidden email]> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.

 

I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.

 

I was intending to use wording that was neutral between the two options without any claims about popularity.

 

Thanks,

-Ekr

 




_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Ilari Liusvaara-2
In reply to this post by Andrei Popov
On Tue, Jun 13, 2017 at 05:10:39PM +0000, Andrei Popov wrote:
>   *   My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future
>   *   and that being extra careful here is important… :)
>
> I agree with this assessment. A MUST would certainly work for me. There are two reasons I suggested SHOULD:
>
>   1.  A MUST would be non-enforceable (a TLS client or server can’t enforce the use of a particular API by the peer).

I would say what the endpoint _itself_ does is more relevant than what
the _peer_ does. I gave some examples of things going badly wrong if
the application does not opt-in, especially at client side.

And on server side, the requirement to only accept "safe" things for
0-RTT can't be done without opt-in.

>   2.  There’s lack of consensus on the topic of 0RTT and I’m trying to suggest a compromise😊.

Not in all aspects of it.


-Ilari

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Colm MacCárthaigh-2
In reply to this post by Benjamin Kaduk-2


On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <[hidden email]> wrote:
That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.


For s2n, I'm leaning towards recommending the opposite; signaling on the client side, if opt-in 0-RTT fails, but no signaling on the server side (though still opt-in). My reasoning is based on experience with that "X-" server-side header trick; it misleads people into what's going on in a way that leads to brokenness. The application people think they only have to de-dupe the 0-RTT sections, but that's not true. 

--
Colm

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Benjamin Kaduk-2
On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote:


On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <[hidden email]> wrote:
That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.


For s2n, I'm leaning towards recommending the opposite; signaling on the client side, if opt-in 0-RTT fails, but no signaling on the server side (though still opt-in). My reasoning is based on experience with that "X-" server-side header trick; it misleads people into what's going on in a way that leads to brokenness. The application people think they only have to de-dupe the 0-RTT sections, but that's not true. 


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.

-Ben

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Colm MacCárthaigh-2

On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <[hidden email]> 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. 

--
Colm

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Ilari Liusvaara-2
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 <[hidden email]> 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).


-Ilari

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Benjamin Kaduk-2
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 [hidden email] 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

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Andrei Popov

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:[hidden email]] On Behalf Of Benjamin Kaduk
Sent: Tuesday, June 13, 2017 11:48 AM
To: Ilari Liusvaara <[hidden email]>; Colm MacCárthaigh <[hidden email]>
Cc: [hidden email]
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 [hidden email] 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


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Separate APIs for 0-RTT

Benjamin Kaduk-2
+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 [[hidden email]] On Behalf Of Benjamin Kaduk
Sent: Tuesday, June 13, 2017 11:48 AM
To: Ilari Liusvaara [hidden email]; Colm MacCárthaigh [hidden email]
Cc: [hidden email]
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 [hidden email] 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



_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
12