Re: Review of draft-thomson-http-replay-latest

2017-08-04 14:53 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> On Thu, Aug 3, 2017 at 8:50 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> This second model is actually what we arrived at, but likely failed to
>> articulate well.
>>
>> However, I think that you need to at least recognize the first model
>> to be entirely safe.
>
>
> I do recognize this.
>
>>
>> As I noted in #28 above, even if the handshake
>> completes, it doesn't mean that the once-early data is entirely safe.
>
>
> I am not sure I can read that from #28, I seem to read it as the opposite?
> I might be confused here.
>
> I am not sure I understand in which sense it's not safe.

(Stated below is my understanding and it could be wrong, but)

Consider the case a server uses strike register to protect against
0-RTT replay attacks. If a server misidentifies a request sent using
0-RTT data to be confirmed by ClientFinished, there is a chance that
such protection would fail.

Rereading the draft, could it be the case that the fact that the use
of strike-register is never discussed in the document even though
other methods (e.g., unconditionally send 4NN, buffer the 0-RTT data
until ClientFinished) are being mentioned is causing confusion?

>
>>
>> This goes back to the need for consistent handling.
>
>
> Could you elaborate on the concept of consistent handling?  I've read #27,
> and I still can't quite understand what problem you are trying to solve.
>
>> In practice, this won't do anything other than change the name.
>> Keeping the focus on mechanics makes this somewhat more concrete, I
>> think.
>
>
> Agreed.



-- 
Kazuho Oku

Received on Friday, 4 August 2017 06:08:05 UTC