Subject: Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)

From: MikkelFJ <[email-masked]>
Date: Tue, 01 Oct 2019 00:28:29 -0700

I don't really care much how Retry is protected, whether it is a checksum at the end or the Initial format, but aside from Version Negotiation, it is the only packet without self-contained integrity checks. That is a pain when forwarding packets, for example over a bluetooth or USB serial gateway. Now you have to add a packet version specific framing layer and since packets can be coalesced, that makes it all the more fun.

-- 
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/3014#issuecomment-536907223

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2019 13:23:28 -0700

Even if we do nothing here, we need to note that UDP checksums are a good idea (cite RFC 8085, Section 3.4).  And we need to point out that a bad Retry token will result in the server dropping the packet.  Also, corruption of Retry could make it hard to distinguish between Retry tokens and NEW_TOKEN tokens unless the discriminator the server uses is in the clear (in which case, the distinction is erased, but that seems unlikely, or maybe you can create markers with a Hamming distance >1 so that bit flips are less likely to erase that signal.

Advice for clients would be to make a new connection if an Initial with a token times out.  What is likely to happen for HTTP - at least in the near term - is that clients will fall back to TCP.

@ianswett suggests that we could allow a server to generate a CONNECTION_CLOSE in response to an Initial with a token that is probably an invalid Retry token.  This would allow the server to signal to the client that the connection is busted.  However, this won't work if we make the proposed change to retain the Initial keys after Retry (#2823), because the server won't be able to get the original keys.

-- 
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/3014#issuecomment-542388445

---

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Oct 2019 13:36:29 -0700

> @ianswett suggests that we could allow a server to generate a CONNECTION_CLOSE in response to an Initial with a token that is probably an invalid Retry token. This would allow the server to signal to the client that the connection is busted.

This also becomes an attack vector, since an attacker could inject such a CONNECTION_CLOSE.

-- 
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/3014#issuecomment-542393406

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2019 15:46:35 -0700

That sort of injection is already possible.

-- 
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/3014#issuecomment-542436352

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Oct 2019 10:16:53 -0700

How is the bit flip error different from an attacker spoofing a Retry packet with made up values?

-- 
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/3014#issuecomment-542803213

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Oct 2019 10:45:50 -0700

Discussed in Cupertino. Agreement in the room for MANDATORY use of AES-GCM with zero key and zero nonce to protect the Retry token. The entire packet would be AAD. @DavidSchinazi's addition of potentially eliding DCID to be thought through by assignee of issue.

-- 
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/3014#issuecomment-542814933

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Oct 2019 16:17:06 -0700

Created PR #3120 to try to address this.

-- 
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/3014#issuecomment-543403622