Re: Alternative ways to keeps ODCID on the server

[Eric Rescorla <[e-mail]>]

I also agree with dropping the MAY. This seems like a pretty clear case for
connection failure.

On Tue, Jan 28, 2020 at 3:58 PM Kazuho Oku <[e-mail]> wrote:

>
>
> 2020年1月28日(火) 15:45 Christian Huitema <[e-mail]>:
>
>> But then, the client that responded to a retry will fail the connection
>> if the ODCID parameter is not there. There are two alternative in the bad
>> token scenario: good faith client with an obsolete new token, or client
>> that received a bad faith retry. In the first case, there is no harm
>> completing the connection. In the second case, the client will drop it so
>> there is only a modest issue of temporary resource allocation.
>>
>
> While I agree that the two scenarios being described here are the
> possibilities, I now tend to agree that the MAY can be dropped. Previously,
> I missed the fact that ODCID has to be carried as a TP (as correctly
> pointed out by Marten and Dmitri).
>
> Regarding attack scenarios, I'd argue that it would be awkward for an
> attacker to only send a spoofed packet to the server-side, when a malicious
> middlebox can also send a packet to the client. I'd also argue that there
> are many other ways of spoofing a client-sent Initial packet, and that
> having a defense just for retry tokens does not change the picture.
>
> Therefore, I think dropping the MAY is fine. I think a server can continue
> to ignore the retry token when it assumes that it was spoofed, but my take
> is that it's not worth writing it down.
>
>> On 1/27/2020 8:35 PM, Marten Seemann wrote:
>>
>> The client knows if it used a NEW_TOKEN token. More specifically, the
>> client knows if it received and responded to a Retry packet.
>>
>> On Tue, Jan 28, 2020 at 11:21 AM Christian Huitema <[e-mail]>
>> wrote:
>>
>>>
>>> On 1/27/2020 7:11 PM, Marten Seemann wrote:
>>>
>>> > That's actually what I implemented. If the token can be verified,
>>> accept
>>> > the connection, treat it as validated. If it cannot be verified, check
>>> > whether the token is necessary, e.g., would any incoming connection
>>> > trigger retry. If it is necessary, drop the connection; if not
>>> > necessary, continue as if no token was there.
>>>
>>> Doesn't that defeat the purpose of the original_connection_id transport
>>> parameter? We introduced it to prevent middleboxes from performing a Retry.
>>> With this logic, a middlebox could perform a Retry, and then corrupt the
>>> token on the second Initial to trick the server into accepting the
>>> connection.
>>> Furthermore, client implementation will check for the
>>> original_connection_id TP, and fail the connection if this TP is missing.
>>>
>>> The spec also has language that I'd interpret as forbidding this:
>>> If the server sends a Retry packet, it MUST include the Destination
>>> Connection ID field from the client's first Initial packet in the transport
>>> parameter.
>>>
>>> How do you reconcile that requirement with the "NEW TOKEN" mechanism? If
>>> the Initial packet carries a NEW TOKEN, it will be accepted and there won't
>>> be any ODCID transport parameter.
>>>
>>> -- Christian Huitema
>>>
>>
>
> --
> Kazuho Oku
>