Subject: Questions about Version Negotiation Concerning Possible Handshake Interruption

From: Lingmo Zhu <[email-masked]>
Date: Fri, 9 Feb 2018 17:34:29 +0800

Hi

I'm new to QUIC and not sure if that could be considered but for Version 
Negotiation with the same connection ID as Initial packet, client should 
choose an acceptable version from the list. What if spoofing from 
something like router happens? Should mitigations be considered, such as 
adding a delay for validated Version Negotiation handling so that 
following handshake packets could be received later and that fake 
Version Negotiation could be ignored?

Such concerning is just come out from DNS hijacking which is partially 
similar, though for QUIC it would only interrupt the handshake. I'm not 
sure but it might be used by downgrade attack in the future. Of course 
I'm new to this field so my opinion would be wrong.

Thanks.

Lingmo Zhu

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Feb 2018 05:10:25 -0500

> What if spoofing from
something like router happens?

There are integrity checks in place to protect against false packets:
https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#version-validation

A false version negotiation packet could also just confuse and interrupt an
existing handshake, but this can also happen in other ways including
handling of retry packets. The general consensus seems to be that you
cannot really prevent on path attacks that wants to disrupt a handshake. I
believe more could be done to prevent off-path attacks, but the spec
changes frequently in this area. For example, if a stateless retry packet
does not reflect the clients connection ID, a third party could send a
retry packet which might not be accepted but could still cause a lot of
confusion, and it would be an off path attack to the extend the receivers
port and address can be guessed.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Feb 2018 21:11:08 +1100

Any spoofed version negotiation packet will be detected once the
handshake completes: the server is required to include its list of
supported versions in the TLS handshake.  See the link Mikkel provided
for details.

On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <[email-masked]> wrote:
> choose an acceptable version from the list. What if spoofing from something
> like router happens? Should mitigations be considered, such as adding a
> delay for validated Version Negotiation handling so that following handshake
> packets could be received later and that fake Version Negotiation could be
> ignored?
>
> similar, though for QUIC it would only interrupt the handshake. I'm not sure
> but it might be used by downgrade attack in the future. Of course I'm new to
> this field so my opinion would be wrong.
>
> Thanks.
>
> Lingmo Zhu
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Feb 2018 05:22:51 -0500

A possible attack scenario:

A server cluster accepts version X and version Y, and sends {X, Y} in VNEG
message if it sees any other requested version.
Except: the cluster also accepts version X_old to deal with hard to upgrade
baby alarms. It never announces X_old in VNEG but it will accept it if
proposed by the client.

Middleware now tries to inject X_old in version negotiation to convince the
client to use that version in instead of version X the client would
normally use. If VNEG wins the handshake race, X_old is now triggered.

But the cluster knows that it would never have proposed X_old so if the
client does verify properly, the handshake should fail.

What I’m not sure about is if the current logic actually supports a case
were X_old is accepted if volunteered, but never when negotiated.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 9 February 2018 at 11.11.13, Martin Thomson ([email-masked])
wrote:

> choose an acceptable version from the list. What if spoofing from
something
> similar, though for QUIC it would only interrupt the handshake. I'm not
sure

---

From: Lingmo Zhu <[email-masked]>
Date: Fri, 9 Feb 2018 19:19:45 +0800

Thank you for the clarification. I admit that downgrade attack could be 
hard to imagine. In fact what I really concerned is some scenario like:

The client accepts version set X and the server cluster accepts some 
versions in X, so handshake should go well. But middle box tries to send 
VNEG with a version list excluding X. If VNEG wins, handshake could be 
aborted.

In that scenario, HTTP could fall back to TCP and be interrupted simply 
by RST. TBH I just hope QUIC could not be easily interrupted. I'm not 
sure if such corner case should be considered.

On 2018/02/09 18:22, Mikkel Fahnøe Jørgensen wrote:
> A server cluster accepts version X and version Y, and sends {X, Y} in 
> VNEG message if it sees any other requested version.
> Except: the cluster also accepts version X_old to deal with hard to 
> upgrade baby alarms. It never announces X_old in VNEG but it will 
> accept it if proposed by the client.
>
> Middleware now tries to inject X_old in version negotiation to 
> convince the client to use that version in instead of version X the 
> client would normally use. If VNEG wins the handshake race, X_old is 
> now triggered.
>
> But the cluster knows that it would never have proposed X_old so if 
> the client does verify properly, the handshake should fail.
>
> What I’m not sure about is if the current logic actually supports a 
> case were X_old is accepted if volunteered, but never when negotiated.
>
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 9 February 2018 at 11.11.13, Martin Thomson 
> ([email-masked] <mailto:[email-masked]>) wrote:
>
>> On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> > Hi
>> >

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Feb 2018 06:23:10 -0500

For the TCP fallback case, this is higher level protocol specific. For
HTTP/QUIC v1 I believe there is a requirement to not fall back to anything
there is a requirement to below TLS 1.3.

But it is a valid concern.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 9 February 2018 at 12.19.50, Lingmo Zhu ([email-masked]) wrote:

In that scenario, HTTP could fall back to TCP and be interrupted simply by
RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure if
such corner case should be considered.

Kind Regards,
Mikkel Fahnøe Jørgensen

something
sure

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 9 Feb 2018 20:31:28 +0900

2018-02-09 20:19 GMT+09:00 Lingmo Zhu <[email-masked]>:
> Thank you for the clarification. I admit that downgrade attack could be hard
> to imagine. In fact what I really concerned is some scenario like:
>

I think that this is a valid concern.

QUIC is tolerant to on-path attackers trying to reset the connection,
once the handshake succeeds. We should spend reasonable effort to
achieve tolerance during the handshake as well.

Regarding how to fix the issue, I think the mitigation that Lingmo
suggested in his first post makes sense (i.e. client waits for some
time even after receiving a VERSION_NEGOTIATION packet).

OTOH, I think that we have room for improving version negotiation. In
TLS, client offers multiple versions and server selects one;
therefore, the handshake finishes in minimal round-trips, which is
good for performance and also gives less chance for on-path attacks to
succeed. In QUIC, the server sends a list of versions and let the
client send another unprotected packet. This is both waste of time and
also is more prone to attacks, due to spending an extra round without
protection.

I think we should change the negotiation scheme so that the server can
select the version to use. The hard part of making such change would
be the fact that we need to decouple the TLS version and the QUIC
version, though.

> client to use that version in instead of version X the client would normally
> use. If VNEG wins the handshake race, X_old is now triggered.
>

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Feb 2018 06:56:51 -0500

A realistic on-path attack involves a government body that taps optic fiber
at an internet distribution node. The original intention behind the
construct may be to trigger an alarm whenever the string “dirty bomb”
appears in a protocol RFC 821 message (such as this one), and subsequently
for logging purposes to monitor traffic directed towards bulk fertiliser
suppliers. It is not possible to drop packets both due to the mechanical
construct, due to legislation, and because it might be too obvious.
However, having a datacenter with optic fibre near said access point gives
excellent insights into early handshakes including IP, port, connection ID,
and possible even a profile of the PRNG being used at some endpoint.

This makes it very simple to spoof and inject packets into handshake with a
good chance of winning any race. More difficult, but possible, it could
also observe packets and inject packets closer to the endpoint, for example
using long distance point to point radio communication to race the ordinary
packet stream.

Any argument about friendly gov is void because the internet travels across
multiple regions that each with near certainty have taps as those described
above making it a prime target in cyber warfare.

The question is then to what extend such a position can be utilised to
interfere with the handshake and what the outcome of such interference
would be, rather than a discussion of how plausible such an attack is,
because it is probably a 99% given if feasible.

---

From: Lingmo Zhu <[email-masked]>
Date: Sat, 10 Feb 2018 09:06:38 +0800

IMHO we can see that such interference is pretty easy to be used and it 
could leading to aborted QUIC connection and probably a fallback to any 
old approach for higher level protocol. Even virus targeting home 
routers could do that, without gov involved. For what outcome, I think 
it's pretty simple: forcing higher level protocol fallback to other 
transport protocol. Since QUIC has been designed much more secure than 
older protocols, it could be hard to do some eavesdropping or hijacking. 
But if fallback happens, it would be another story. Considering DNS over 
QUIC, a virus-infected home router could interfere with QUIC handshake 
cause fallback to TLS, then RST may cause fallback to clear text, which 
is easy to be hijacked and leads client to some phishing site.

On 2018/02/09 19:56, Mikkel Fahnøe Jørgensen wrote:
> A realistic on-path attack involves a government body that taps optic 
> fiber at an internet distribution node. The original intention behind 
> the construct may be to trigger an alarm whenever the string “dirty 
> bomb” appears in a protocol RFC 821 message (such as this one), and 
> subsequently for logging purposes to monitor traffic directed towards 
> bulk fertiliser suppliers. It is not possible to drop packets both due 
> to the mechanical construct, due to legislation, and because it might 
> be too obvious. However, having a datacenter with optic fibre near 
> said access point gives excellent insights into early handshakes 
> including IP, port, connection ID, and possible even a profile of the 
> PRNG being used at some endpoint.
>
> This makes it very simple to spoof and inject packets into handshake 
> with a good chance of winning any race. More difficult, but possible, 
> it could also observe packets and inject packets closer to the 
> endpoint, for example using long distance point to point radio 
> communication to race the ordinary packet stream.
>
> Any argument about friendly gov is void because the internet travels 
> across multiple regions that each with near certainty have taps as 
> those described above making it a prime target in cyber warfare.
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 9 Feb 2018 20:24:42 -1000

On 2/9/2018 3:06 PM, Lingmo Zhu wrote:
>
> IMHO we can see that such interference is pretty easy to be used and
> it could leading to aborted QUIC connection and probably a fallback to
> any old approach for higher level protocol. Even virus targeting home
> older protocols, it could be hard to do some eavesdropping or
> hijacking. But if fallback happens, it would be another story.
> Considering DNS over QUIC, a virus-infected home router could
> interfere with QUIC handshake cause fallback to TLS, then RST may
> cause fallback to clear text, which is easy to be hijacked and leads
> client to some phishing site.
>

In theory, it should be possible to protect against "man on the side"
attacks. Do some kind of speculative execution on the first packet that
you receive, but also keep the context available for some time in case a
"better" packet comes later. With that approach, the attacker could not
just inject a "packet of death"; they will also need to suppress the
correct response from the actual server. That's an interesting idea.
Have you tried some experiments?

-- Christian Huitema

---

From: <[email-masked]>
Date: Sat, 10 Feb 2018 09:34:45 +0100

> Have you tried some experiments?

Alternatively, what about a "no fallback" mode for sensitive applications like DNS ?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Feb 2018 19:56:42 +1100

> Alternatively, what about a "no fallback" mode for sensitive applications

If versioning were strictly linear, you could do as we do for TLS and
remember that server X supported version Y and ignore any version
negotiation from X that claimed to support only Y-1.  That's not
necessarily an ideal outcome, but you can do that.

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 10 Feb 2018 18:00:07 +0900

> Alternatively, what about a "no fallback" mode for sensitive applications

I agree that providing such an option would narrow the attack window.
The other option is to let the client propose multiple versions and
the server select one, as proposed in my previous mail.

But even if we do that, there's still the chance of an attacker
injecting a Handshake packet that contains a corrupt ServerHello
message. In such case, the client would fail to complete the handshake
with the server.

To evade such attacks, a client is required to create a backup of its
TLS context before handling the Handshake packet that might have been
sent from an attacker, so that it could restore the context one the
TLS handshake ends up in an error.

However, I am not sure if any of the TLS stacks provide such a feature
(personally I would be interested in adding one in picotls, though).

> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

-- 
Kazuho Oku

---

From: <[email-masked]>
Date: Sat, 10 Feb 2018 10:10:11 +0100

> message. In such case, the client would fail to complete the handshake

Yes, but this weakens the threat from outright intrusion to mere DOS, right ?

If so, note that the attacker may always follow its packet-of-death with a 
flood, making the receiver-side UDP socket overflow and eventually drop the 
legitimate server's response. In this case, not even a TLS context backup will 
be able to recover. Agreed, that's a heavier sword for a thicker shield, but 
that's doable ;)

---

From: Lingmo Zhu <[email-masked]>
Date: Sat, 10 Feb 2018 18:30:22 +0800

> Have you tried some experiments?

No experiments yet but I'd love to. Though my current work is not so
related to this field so maybe I'm not professional enough.

> (personally I would be interested in adding one in picotls, though).

IMHO even though we want no fallback for service like DNS, in reality
that could not be possible for several years due to deploying progress
and its critical position (if no fallback, no name resolving would be
available if QUIC & TLS connection failed if my understanding is
correct).

To be cleared, spoofing clear text VERSION NEGOTIATION packet is cheap
from my POV so it could be misused easily. I'm not sure but injecting
corrupt ServerHello message could be sort of expensive thanks to
encryption so I didn't consider that far. So if we still decide to use
current version negotiation mechanism, considering only the attack
approach using VERSION NEGOTIATION and we hold different contexts for
a short period, there would be several cases:

* fake VERSION NEGOTIATION with no acceptable versions was sent to the
   client but the server could accept the QUIC version INITIAL packet
   used, it could be mitigated by simply wait for a short period. Retry
   might be applied considering packet lost.
* sever actually could not accept any version that the client supported,
   client would abort the QUIC connection after several retries and that
   should be expected.
* fake VERSION NEGOTIATION with no acceptable versions was sent to the
   client and the server also rejected the QUIC version with a VERSION
   NEGOTIATION with acceptable versions, client could try an acceptable
   version and process the handshake.
* fake VERSION NEGOTIATION with acceptable versions was sent to the
   client and the server could accept the QUIC version INITIAL packet
   used, things could be tricky. At least two contexts should be hold
   by the client. If the new version selected by client is not acceptable
   to server, that could be a better scenario since the original context
   would simply become the finally negotiated one. But if the new version
   is also acceptable by server, I'm not sure what would happen.
* fake VERSION NEGOTIATION with acceptable versions was sent to the
   client but the server rejected the QUIC version with a VERSION
   NEGOTIATION with acceptable versions, things would be really complex.
   But the downgrade attack mentioned by Mikkel should be tolerant by
   current verifying mechanism. I'm not sure if we should consider this
   case.

So as a summary, holding original context for a short period should be
enough for mitigating the interruption caused by VERSION NEGOTIATION
according to the first three cases. But for the remaining misuse cases,
it might need further consideration if they should.

Lingmo Zhu

---

From: Lingmo Zhu <[email-masked]>
Date: Sun, 18 Feb 2018 23:48:21 +0800

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".

The attack utilizing fake Version Negotiation is too cheap and easy to
be performed (due to no encryption exists) and would be harmful (even
stopping the establishment of connections) so should be mitigated. The
attack that means to make the client abort QUIC connection could be
easily performed with small footprint but also could be mitigated by
simply ignoring those unacceptable Version Negotiation packets in my
rough experiment (if could be called so). Some possible approaches might
be considered:

* A timer could be set after Initial packet sent (might be combined with
one used for re-transmit) for waiting ServerHello. If a Version
Negotiation is received but totally unacceptable, just ignore it. If the
received Version Negotiation is acceptable, it could be considered after
the timeout instead of handled immediately. If a fake packet with
ServerHello received, it should be rejected by TLS so not considered
here.

* When a Version Negotiation is received, instead of handling it within
the same connection, handle it as another connection and remain the
original connection context. If then the ServerHello packet is received,
the new connection context could be dropped and the original connection
would be used following up. This approach might be more difficult to be
implemented than the previous one.

The approaches above are both covered by the statement to be proposed 
but not exhaustive. This should be a handling for client side so server
side would have no modification. Due to different implementations of
different clients, it could not be ensure that those approaches are
simple enough to be applied but those malicious Version Negotiation
packets should be properly handled. Also, the scenario where fake
Version Negotiation packets are triggered by each outgoing QUIC
(Initial) packet should also be considered.

For why those Version Negotiation attack would be utilized by malware, I
think they could pretend as server side problem then attract less
attention. If simply dropping packet or faking ICMP host unreachable are
utilized, it would be considered as an issue on route configuration so
more likely a client-side problem thus more attention.

Lingmo Zhu

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 18 Feb 2018 08:10:58 -0800

I was very close to proposing dropping the version negotation packet in
favor of having the client offering multiple versions in the initial
ClientHello. It would also save a roundtrip if negotiating.

However, I realized that it would probably tie the version negotiation to
the TLS handshake which is not a very good idea.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 18 February 2018 at 16.48.27, Lingmo Zhu ([email-masked]) wrote:

Hi all

Lingmo Zhu

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Feb 2018 09:25:44 -0800

> 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

---

From: Lingmo Zhu <[email-masked]>
Date: Mon, 19 Feb 2018 10:10:40 +0800

On 2018/02/19 1:25, Eric Rescorla wrote:
> 
> 
> On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <[email-masked] 

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.

Lingmo Zhu

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Feb 2018 18:55:45 -0800

On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <[email-masked]> wrote:

>> On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>     Hi all
>>
> 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

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 19 Feb 2018 03:41:18 +0000

> 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 <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Sunday, February 18, 2018 6:55:45 PM
To: Lingmo Zhu
Cc: [email-masked]; Christian Huitema; Mikkel Fahnøe Jørgensen; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi all

-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

---

From: Lingmo Zhu <[email-masked]>
Date: Mon, 19 Feb 2018 12:34:56 +0800

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 
> 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 <[email-masked]> on behalf of Eric Rescorla 
> <[email-masked]>
> *Sent:* Sunday, February 18, 2018 6:55:45 PM
> *To:* Lingmo Zhu
> *Cc:* [email-masked]; Christian Huitema; Mikkel Fahnøe 
> Jørgensen; [email-masked]; Martin Thomson; Kazuho Oku
> *Subject:* Re: Malicious Version Negotiation Handling (Was: Questions 
> about Version Negotiation Concerning Possible Handshake Interruption)
> 
> 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>              Hi all
> 
>     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.
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Feb 2018 20:41:36 -0800

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 <[email-masked]> wrote:

> 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
>
>> 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.
>>
>> 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 <[email-masked]> on behalf of Eric Rescorla <
>> [email-masked]>
>> On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <[email-masked] <mailto:

---

From: Christian Huitema <[email-masked]>
Date: Sun, 18 Feb 2018 20:49:24 -0800

On 2/18/2018 8:41 PM, Eric Rescorla wrote:

> 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.

Changing the protocol, probably not. But Lingmo's suggestion is one of
the several steps that we could take against hardening against a man on
the side attack. And it is a very simple one: if you receive a VN that
does not contain any acceptable option, just ignore it. If this was
legit, the connection will actually break after a short timer. If it was
not, the next received message will be a Server Hello, and the
connection will progress. Sounds like a reasonable trade-off.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Feb 2018 20:54:18 -0800

> connection will progress. Sounds like a reasonable trade-off.

I think it's fine if people do this. I don't think it's worth requiring in
the spec given the existence of other trivial man-on-the-side attacks.

-Ekr

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 19 Feb 2018 13:26:37 +0000

For clients that have a tcp fallback, this kind of an attack mitigation would need to be done together with some happy eyeballs race. Otherwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack happening. So if this kind of an artificial delay in VN is mentioned, starting the fallback would need to be mentioned as well. All this seems like it could belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs anywhere at all, but not the transport draft.

-----Original Message-----
From: Eric Rescorla [[email-masked]]
Received: Sunday, 18 Feb 2018, 11:55PM
To: Christian Huitema [[email-masked]]
CC: IETF QUIC WG [[email-masked]]
Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)

On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

I think it's fine if people do this. I don't think it's worth requiring in the spec given the existence of other trivial man-on-the-side attacks.

-Ekr

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Feb 2018 10:31:07 -0800

On 2/19/2018 5:26 AM, Lubashev, Igor wrote:

> For clients that have a tcp fallback, this kind of an attack
> mitigation would need to be done together with some happy eyeballs
> race. Otherwise, waiting for a timeout on VN has a real performance
> cost to the user in case there is no attack happening. So if this kind
> of an artificial delay in VN is mentioned, starting the fallback would
> need to be mentioned as well. All this seems like it could belong to
> an optimization/applicability/happy-eyeballs-for-QUIC draft, if it
> belongs anywhere at all, but not the transport draft.

That's reasonable. Several people have expressed concerns about
man-on-the-side attacks. We have heard various proposals for hardening
the initial handshake. The typical concern is an adversary "that taps
optic fiber at an internet distribution node", to use Mikkel's words,
although we may also be concerned by an on-link attacker in an Ethernet
or Wi-Fi network. The adversary gets a copy of packets, parses them, and
finds a pattern that triggers an attack. The adversary then sends a
forged packet to one end of the connection or another, with a goal of
causing either a connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending
a forged version negotiation packet. I think that's a valid concern, but
only one of many. We should be equally concerned with forged stateless
reset packets, or forged handshake packets: anything that happens before
protection is negotiated can be forged.  I would support writing a draft
that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 19 Feb 2018 10:42:10 -0800

Two factor hasn't been mentioned at all - and at first sight it might seem
a bit off.

However, considering the availability of both auth apps and Fido HW
authentication devices, this could be built into the early handshake as an
option.

On 19 February 2018 at 19.32.46, Christian Huitema ([email-masked])
wrote:

For clients that have a tcp fallback, this kind of an attack mitigation
would need to be done together with some happy eyeballs race. Otherwise,
waiting for a timeout on VN has a real performance cost to the user in case
there is no attack happening. So if this kind of an artificial delay in VN
is mentioned, starting the fallback would need to be mentioned as well. All
this seems like it could belong to an
optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs
anywhere at all, but not the transport draft.

That's reasonable. Several people have expressed concerns about
man-on-the-side attacks. We have heard various proposals for hardening the
initial handshake. The typical concern is an adversary "that taps optic
fiber at an internet distribution node", to use Mikkel's words, although we
may also be concerned by an on-link attacker in an Ethernet or Wi-Fi
network. The adversary gets a copy of packets, parses them, and finds a
pattern that triggers an attack. The adversary then sends a forged packet
to one end of the connection or another, with a goal of causing either a
connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending a
forged version negotiation packet. I think that's a valid concern, but only
one of many. We should be equally concerned with forged stateless reset
packets, or forged handshake packets: anything that happens before
protection is negotiated can be forged.  I would support writing a draft
that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Feb 2018 06:53:20 -0500

Replying with no hats ...

On Mon, Feb 19, 2018 at 8:26 AM, Lubashev, Igor <[email-masked]> wrote:

> there is no attack happening.
>

I don't understand this. Is your thinking that the attacker would send a
forged VN packet AND drop the server's response?

If so, that does make sense, but if that's not part of the scenario, I
don't know why the client wouldn't drop the forged "no acceptable version
numbers" packet and accept the server's packet, at roughly the same point
in time where there would have accepted the server's packet if there was no
attack.

Are we talking about the same thing?

(To be clear, I don't have an opinion about what the working group decides,
but I do want to understand what's being discussed)

Thanks,

Spencer

> So if this kind of an artificial delay in VN is mentioned, starting the
> fallback would need to be mentioned as well. All this seems like it could
> belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if
> it belongs anywhere at all, but not the transport draft.
>
>
> *From:* Eric Rescorla [[email-masked]]
> *Received:* Sunday, 18 Feb 2018, 11:55PM
> *To:* Christian Huitema [[email-masked]]
> *CC:* IETF QUIC WG [[email-masked]]