On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote: > > > On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <bka...@akamai.com > <mailto:bka...@akamai.com>> 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
