Re: Working Group Last Call for Using Early Data in HTTP

On Mon, Feb 12, 2018 at 4:41 PM Eric Rescorla <> wrote:

> On Mon, Feb 12, 2018 at 4:24 PM, Jeffrey Yasskin <>
> wrote:
>> I apologize for sending this so long after the WGLC deadline, but I
>> noticed that draft-ietf-httpbis-replay-02, "Using Early Data in HTTP",
>> doesn't mention the risks of sending non-PFS early data.
>> Even in requests that pose no replay risks, the client might include
>> confidential data like cookies, or the fact of requesting a particular path
>> might be private. If an expired key is discovered by an attacker, my
>> understanding is that they could decrypt this information if it's sent in
>> early data. Is that right?
>> If so, do clients need to restrict their early-data requests to ones not
>> containing confidential information? (I think, for browsers, that would be
>> requests with an "omit" credentials mode:
>> Should
>> private-browsing modes avoid early-data entirely? Should all browsing modes
>> restrict it to cases where they have evidence that the request data isn't
>> private?
> The FS properties of TLS 1.3 Early Data are basically the same as those of
> TLS 1.2 resumption, and to the best of my knowledge, no client avoids
> sending credentials when in resumption mode, so I don't think that this is
> an appropriate way to handle it.

The comparison to TLS 1.2 resumption makes sense. Thanks.


Received on Tuesday, 13 February 2018 01:02:58 UTC