Subject: Re: [quicwg/base-drafts] Complete version negotiation failure (#1917)

From: Igor Lubashev <[email-masked]>
Date: Wed, 07 Nov 2018 02:00:23 -0800

@mikkelfj, trying to mitigate this injection DoS attack is much harder than merely "waiting a bit before failing". If your implementation waits a bit in case of no common version in VN packet, what would it do, if an attacker injects a VN packet with a version you do support (which arrives before a reply from the server that actually supported your initial version)?  What if the attacker races to the server a packet with your 4-tuple, CIDs, and version but different contents, establishing a connection on the server for you, which you would not be able to decrypt? Etc.

I'd rather defer mitigations, if any are possible, to a later version of this draft (or a different draft).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1917#issuecomment-436569932

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 02:33:27 -0800

@igorlord There are definitely many more scenarios better handled in v2 or which are not practical to defend against at all without out of band knowledge such as signatures of some sort.

As to a VN with initial version, the draft already says:

> A client MUST ignore a Version Negotiation packet that lists the client’s chosen version.

However "waiting a little" will give a valid packet a fighting chance against subversive attackers that wish to remain undetected.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1917#issuecomment-436579373

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 07 Nov 2018 03:07:48 -0800

> However "waiting a little" will give a valid packet a fighting chance against subversive attackers that wish to remain undetected.

That's right.  I meant the attack claiming another version you support, not your original version.  Given that browsers are likely to be supporting predictable version sets, picking a different one is not likely to be a challenge.

The other problem with just waiting is that the client is likely better off just failing over to TCP quickly to improve user experience.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1917#issuecomment-436588715

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 04:27:37 -0800

I won't necessarily argue against failover to TCP, but my working assumption is that QUIC is QUIC, even if the most likely implemention is QUIC/HTTP/HQ/H3 with support for TCP. Hence QUIC needs to be able to handle itself the best it can. Specific use cases may recommend fallbacks to TCP, but it won't work in general.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1917#issuecomment-436607100

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 07 Nov 2018 04:38:06 -0800

Right, though HTTP with TCP failover is a very important use case. But even without TCP, there are other options, such as failover to another IP returned by DNS. Of course, if you have exhausted all options, waiting may be the best alternative left. I would delegate guidance on this to a draft akin to Happy Eyeballs for QUIC (Applicability draft?).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1917#issuecomment-436609538