Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt

On 06/26/2017 12:44 PM, Martin Thomson wrote:
> Thanks for your thoughts Ben,
>
> On 26 June 2017 at 08:32, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>> I do think that it's worth mentioning on this list the
>> qualitative distinction between tens of replays and billions of replays that
>> was made on the TLS list.
> https://github.com/martinthomson/http-replay/pull/17
>
> (You also mentioned things like cookies and whether we might have
> other guidance for how clients might restrict what they send.  We
> currently focus on request methods, and take the extremely
> conservative position of recommending only "safe" methods.)

Hmm, "extremely conservative" seems a bit subjective; from where I sit
the current position is more "middle-of-the-road" and "extremely
conservative" would be along the lines of "you get 1 GET, no cookies,
sent atomically".  Not that I am arguing for the draft to become more
lenient, of course!

>
>> In section 2, I'm not sure that we need to mention the TLS-native
>> strateg(ies) (item 4).
> I think that it's important to mention, if only because a lot of the
> other defenses rely on that point you made earlier about reducing the
> potential billions down to something more manageable.  It's especially
> relevant when you are worrying about leakage through side-channels.

Well, I hope that TLS ends up mandating something that is not the
potential billions, in which case it's less of an issue here. Of course,
if TLS does not make such a mandate, we could still do so here ...

>> There is also some potential subtlety in item (3),
>> relating to whether the server decides to respond with 4NN (Too Early) in a
>> deterministic fashion *across all servers that might handle the request*
>> based solely on the contents of the request (which is a very safe strategy)
>> or also includes information about the rate of incoming requests/etc. in the
>> decision (which could lead to some successful replays).
> That might be too subtle in the sense that it relies on someone making
> a non-obvious decision about how to handle replays.  Hopefully we have
> provided enough information for those people to make the right
> decision, because I can't think of any easy way to first introduce the
> notion of treating requests differently across a different server
> instances and then the consequences of that choice.
>

How would you feel about adding an additional sentence, something like
"Even if a given server responds with 4NN (Too Early), replay of that
request may still be possible if a different server (or the same server
at a different time) makes a different risk assessment and is willing to
process the request."?

>> I think you have some good text about the server being able to accept or
>> reject the risk of replay for a given request, and the client being able to
>> decide on risk when creating requests.
>>
>> However, I'm not sure this claim is accurate:
>>
>>    [...] In general, if a request does not have state-
>>    changing side effects on a resource, the consequences of replay are
>>    not significant.
>>
>> with respect to the feasibility of side-channel attacks on the preparation
>> of the response.  (And the hopefully obvious note that affecting/determining
>> whether or not a resource is in a particular cache is a side effect.)
> I think that it is accurate, though as you correctly observe, what
> people think of as state-changing side-effects is sometimes far more
> limited in scope.  That's dangerous.  I'm proposing a tweak to the
> language, but thinking about whether there needs to be more exposition
> on this point.
>
> https://github.com/martinthomson/http-replay/pull/18

I'll take a look there, thanks.

>
>> Also, what might
>> cause a client to abandon those requests?  Should we give
>> examples/reasoning?
> This is totally generic, and so specific reasons for abandoning are
> hard to scope properly.

Agreed.  Do you want to mention ", whether specifically due to the
rejection or early data or otherwise" to make the genericity super-clear?

>> (Token binding is one thing that comes to mind, as the
>> requests would need to be regenerated with the proper bindings;
> Ahh, 0-RTT token binding is a horror.  This is why generally the
> "start over" thing is important.  I think that the best way to

Yes.  I don't have any suggested text right now that would emphasize
this more, but there may be room for improvement in this area.

> implement token binding is to decorate requests as they get written to
> the socket, so that the header field is not (incorrectly) attached to
> the thing that is retried.

In an async world, I have to agree.  (Though this topic is really more a
matter for tokbind than httpbis.)

>> asking for clarity on having the decision to abandon the request be
>> specifically due to the early data rejection vs. just the client is not
>> interested in the response anymore
> This ambiguity was intentional from my perspective.  On the one hand,
> I don't think that rejection of early data is good grounds for
> deciding to abandon a request and the "close the tab" example is a
> better basis for abandoning a request.  But I also recognize that
> retrying does create that one-time replay exposure and I didn't want
> to expressly prohibit deciding to abandon requests if early data is
> rejected.

I guess this mostly answers my above question.

>
>> There is also some small
>> potential for reader confusion in that retries can (but perhaps should not)
>> be initiated by the TLS stack on 0-RTT negotiation failure, and also by the
>> HTTP stack on 4NN (Too Early), but only one of those will come into effect
>> for any given request.
> TLS already covers this adequately:

You mean people actually read the references? ;)
(I agree that it's probably fine to leave this text as-is.)

-Ben