On Mon, Feb 12, 2018 at 4:41 PM Eric Rescorla <ekr@rtfm.com> wrote: > On Mon, Feb 12, 2018 at 4:24 PM, Jeffrey Yasskin <jyasskin@google.com> > 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: >> https://fetch.spec.whatwg.org/#concept-request-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. Jeffrey
Received on Tuesday, 13 February 2018 01:02:58 UTC