Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)

[Eric Rescorla <[e-mail]>]

I don't think increasing the on-path attacker's marginal difficulty from
not requiring any crypto to requiring simple crypto in order to mount a DoS
attack is worth changing the protocol for.

-Ekr


On Sun, Feb 18, 2018 at 8:34 PM, Lingmo Zhu <[e-mail]> wrote:

> Thank you for your comments and explanations. IMHO VN packet handling is
> part of QUIC transport which is independent with any specific TLS version,
> though attacks targeting TLS handshake could get similar result.
>
> I understand that we could never win against on-path attackers. But I just
> wonder if we should consider about that or how far we could.
>
> Lingmo Zhu
>
> On 2018/02/19 11:41, Subodh Iyengar wrote:
>
>>
>>  > It's an attack that generates VN packets with no acceptable version,
>> on path. Of course such an attacker can generate other messages to
>> interfere QUIC but utilizing VN packets needs no knowledge other than CID
>> and no encryption, or only CID needs to be changed from a template. If
>> other cleartext packet with wrong or no AEAD encryption described for the
>> TLS handshake would be just ignored, those other messages should at least
>> be encrypted, which costs much more and more complex to be implemented.
>>
>> I agree with ekr, a TLS alert is similar and does not require knowledge
>> of any state, knowledge of the cid gives you the ability to craft a packet
>> that will be accepted by the client (even Handshake packets).
>>
>>
>> Subodh
>>
>> ------------------------------------------------------------------------
>> *From:* QUIC <[e-mail]> on behalf of Eric Rescorla <
>> [e-mail]>
>> *Sent:* Sunday, February 18, 2018 6:55:45 PM
>> *To:* Lingmo Zhu
>> *Cc:* [e-mail]; Christian Huitema; Mikkel Fahnøe
>> Jørgensen; [e-mail]; Martin Thomson; Kazuho Oku
>> *Subject:* Re: Malicious Version Negotiation Handling (Was: Questions
>> about Version Negotiation Concerning Possible Handshake Interruption)
>>
>>
>> On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>
>>
>>     On 2018/02/19 1:25, Eric Rescorla wrote:
>>
>>
>>
>>         On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <[e-mail]
>>         <mailto:[e-mail]> <mailto:[e-mail]
>>
>>         <mailto:[e-mail]>>> wrote:
>>
>>              Hi all
>>
>>              After some discussion with Kazuho and thanks to his help, I
>>         want to
>>              propose that for Version Negotiation handling, "a client
>>         MAY wait for a
>>              handshake packet after receiving a Version Negotiation
>> packet".
>>
>>
>>         Can you describe the precise attack you are concerned about? The
>>         VN packet
>>         contains the client's randomly chosen CID, so only an on-path
>>         attacker can
>>         forge a VN, but such an attacker can also generate a bogus
>>         ServerHello or
>>         other messages that would cause the QUIC negotiation to fail.
>>
>>         -Ekr
>>
>>
>>
>>     It's an attack that generates VN packets with no acceptable version,
>>     on path. Of course such an attacker can generate other messages to
>>     interfere QUIC but utilizing VN packets needs no knowledge other
>>     than CID and no encryption, or only CID needs to be changed from a
>>     template. If other cleartext packet with wrong or no AEAD encryption
>>     described for the TLS handshake would be just ignored, those other
>>     messages should at least be encrypted, which costs much more and
>>     more complex to be implemented.
>>
>>
>> Thanks for the explanation. I don't consider this a significant
>> difference in attacker capabilities.
>>
>> -Ekr
>>
>>
>>
>>     Lingmo Zhu
>>
>>
>>