Subject: [quicwg/base-drafts] Remove amplification throttle if the server receives Initial that echoes its high entropy SCID. (#3834)

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 17:35:45 -0700

Suppose you have a large SH, for instance due to PQ crypto, in which
case it will have to span multiple packets. If it exceeds three
packets, then it will not be able to fit into a single flight. Ideally
this would look something like this:

```
C                                   S
Initial (CH) ----------------------->
<---------------------- Initial (SH1)
<---------------------- Initial (SH2)
<---------------------- Initial (SH3)
Initial (ACK) ---------------------->
<---------------------- Initial (SH4)
<---------------------- Initial (SH5)
<---------------------- Initial (SH6)
<---------------------- Initial (SH7)
<---------------------- Initial (SH8)
<---------------------- Initial (SH9)

```

However, as I read the text, the server is actually only permitted to
send three packets in response to the ACK. The good news is that
because the client is required to send fully padded packets, so you at
least get to send 3600 octets or so per RT, but if the SH is >7K this
is pretty annoying.

I believe that there is a straightforward compatible change that would
allow relaxing this restriction: if the server uses a reasonably long
SCID, then when the client responds with an initial with DCID set to
that SCID (which it is supposed to do anyway by my reading of S 7.2),
then it is implicitly a proof of reachability, and the server could
ignore the amplification limit.

-- 
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/3834

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 17:45:04 -0700

This would be conditional on the server choosing a connection ID that has enough entropy (we seem to have decided that 64 bits is the benchmark).  @huitema has made the same comment on occasion.

-- 
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/3834#issuecomment-655213670

---

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 18:18:16 -0700

On Tue, Jul 7, 2020 at 5:44 PM Martin Thomson <[email-masked]>
wrote:

> This would be conditional on the server choosing a connection ID that has
> enough entropy (we seem to have decided that 64 bits is the benchmark).
> @huitema <https://github.com/huitema> has made the same comment on
> occasion.
>
Yes, agreed.

-- 
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/3834#issuecomment-655222919

---

From: Marten Seemann <[email-masked]>
Date: Tue, 07 Jul 2020 18:26:32 -0700

> This would be conditional on the server choosing a connection ID that has enough entropy (we seem to have decided that 64 bits is the benchmark). @huitema has made the same comment on occasion.

How would a client know how what algorithm the server used to generate the connection ID?

As this seems to be a design issue anyway, here's another proposal: The server could send a token in the Initial packet, and the client would then use this token on subsequent Initial packets (replacing the token it might have used on the packet containing the ClientHello). This way, we'd be using a field that's intended to carry a high-entropy value, and not rely on a field that the server might not even have control over.

-- 
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/3834#issuecomment-655225333

---

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 18:33:27 -0700

> How would a client know how what algorithm the server used to generate the
The client doesn't need to know, because it's the server's amplification
limit that is at hand. And right now, the handshake would complete if the
client doesn't do anything, it's just not optimal.

As this seems to be a design issue anyway, here's another proposal: The
> server could send a token in the Initial packet, and the client would then
> use this token on subsequent Initial packets (replacing the token it might
> have used on the packet containing the ClientHello). This way, we'd be
> using a field that's intended to carry a high-entropy value, and not rely
> on a field that the server might not even have control over.
>
I agree that this would work, but it seems like a significantly more
invasive change, especially given the somewhat edge-casey nature of the
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/3834#issuecomment-655227174

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 18:35:57 -0700

We could also allow PATH_CHALLENGE in Initial packets, but that too has more disruptive effects on the design.

Of course, this is almost something that implementations could do without permission.  But if we want that, then it is better to capture it.

-- 
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/3834#issuecomment-655227861

---

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 18:37:54 -0700

On Tue, Jul 7, 2020 at 6:35 PM Martin Thomson <[email-masked]>
wrote:

> Of course, this is almost something that implementations could do without
> permission. But if we want that, then it is better to capture it.
>
Yah, that was my thinking.

-- 
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/3834#issuecomment-655228439

---

From: Marten Seemann <[email-masked]>
Date: Tue, 07 Jul 2020 18:41:58 -0700

> We could also allow PATH_CHALLENGE in Initial packets, but that too has more disruptive effects on the design.

That's probably easier than using the Token field. The only change required for this would be to allow those two frames in Initial packets.

-- 
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/3834#issuecomment-655229616

---

From: Christian Huitema <[email-masked]>
Date: Tue, 07 Jul 2020 18:48:23 -0700

I agree that the change makes sense. The picoquic server already does that: if the client responds with the proper CID, then the connection is validated. The protocol police has not caught me yet, and that makes sense because the specifics of amplification response are pretty much a server implementation choice -- and yes, sticking a path challenge in the server's Initial packet would be another valid choice. The main problem is not on the server side, but rather on the client side. 

The last interop issue I saw came when a client was coalescing an Initial ACK with an Handshake ACK. The exchange went something like:

* For DCID `db872c93777b337a` I'm sending you an Initial ACK + Handshake but picoquic is rejecting it as too short (error code 408). My reading of the spec is this is legal, as it's a coalesced packet
* Answer: The text log says that the Initial packet #1 was accepted, but after that you are sending an initial packet that is just 95 bytes long, and then an handshake packet.
* ... discussion showing that the coalesced datagram was just 95 bytes long, when the spec says that all initial packets should be padded to 1200 bytes.

So basically the question is, should clients be authorized to NOT pad an Initial packet to 1200 bytes if the DCID of the Initial packet is set to the SCID received by the server? I would love to say that, but I am concerned about making disruptive changes during WGLC. And so my reluctant advice is to not do anything about this issue now. Developers of servers can make their own decisions, using either long CID or path challenges.

-- 
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/3834#issuecomment-655231430

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 19:02:44 -0700

Yes, the Initial padding was discussed, and I think that as it depends on the client making an assessment of the entropy present in the connection ID, it is a non-starter.

-- 
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/3834#issuecomment-655235566

---

From: Christian Huitema <[email-masked]>
Date: Tue, 07 Jul 2020 19:11:19 -0700

The server could also inject entropy by selecting a large sequence number for the Initial packet. In theory nothing would break if the server picked a random 61 bit number for the first Initial packet instead of zero. If the client acks that and repeats the proper CID, then the server can legitimately assume that the client's address is validated.

-- 
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/3834#issuecomment-655238040

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 19:18:00 -0700

You can only get 32 bits of entropy in the packet number, and you might limit your ability to send more packets if you picked a number that is too large, but yeah, there are options.

-- 
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/3834#issuecomment-655240017

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Jul 2020 10:18:41 -0700

Is there a reason we would want to prohibit PATH_CHALLENGE/PATH_RESPONSE in Initial packets?  That seems like a straightforward way to use existing mechanisms, if we want to take this design change.

-- 
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/3834#issuecomment-656250479

---

From: ianswett <[email-masked]>
Date: Fri, 10 Jul 2020 12:03:40 -0700

I'm a bit surprised we're having this conversation at this stage in the process, but I'll throw my 2 cents in.

I'm not particularly opposed to allowing PATH_CHALLENGE/PATH_RESPONSE, but it seems more invasive than explicitly saying something like "Servers MAY treat the receipt of a server generated connection ID with at least 64 bits of entropy as address validation."

-- 
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/3834#issuecomment-656836825

---

From: ekr <[email-masked]>
Date: Fri, 10 Jul 2020 12:21:10 -0700

This is my take as well. What's the disadvantage of the text Ian proposes

-- 
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/3834#issuecomment-656849116

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Jul 2020 12:42:33 -0700

I like Ian's proposal and I dislike the idea of allowing the Path Challenge in Initial packets. I think allowing Path Challenge would just make things more complicated, while providing very little advantage over the Retry process. We might have debated that longer 2 years ago, but now is not the time -- better leave the spec as is.

-- 
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/3834#issuecomment-656857305

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 12 Jul 2020 18:51:49 -0700

Ian's suggestion seems fine. It's an addition to the spec, and I'm not really hearing any strong dissensions.

-- 
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/3834#issuecomment-657317461

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 Jul 2020 15:26:29 -0700

This is sounding like a design change, is that accurate?

-- 
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/3834#issuecomment-658443832

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 19:21:08 -0700

Yes, this is a design change being proposed. 

-- 
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/3834#issuecomment-658506420

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jul 2020 05:29:21 -0700

Is there a proposed resolution here?

-- 
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/3834#issuecomment-660997012

---

From: ianswett <[email-masked]>
Date: Mon, 20 Jul 2020 07:38:43 -0700

@larseggert there is now.

-- 
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/3834#issuecomment-661080685

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jul 2020 23:47:12 -0700

Thanks, @ianswett. Do folks agree with the proposed resolution?

-- 
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/3834#issuecomment-661668790

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 21 Jul 2020 11:55:40 -0700

@larseggert -- the PR needs some work, but I've only heard agreement on the resolution itself.

-- 
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/3834#issuecomment-662045415

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 21 Jul 2020 12:40:45 -0700

@larseggert : I think this is `proposal-ready` as well.

-- 
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/3834#issuecomment-662067290

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 Jul 2020 00:17:59 -0700

> Yes, the Initial padding was discussed, and I think that as it depends on the client making an assessment of the entropy present in the connection ID, it is a non-starter.

I see this concern, but consider a use case where it is expensive to send a large initial packet but the client has an a-priory key to generate trusted initial CIDs. In that case the client knows that entropy is sufficient and the server can validate the DCID. This can be done, for example, and deployment dependent, by using a blake-2b hash.

For battery powered low-power radio devices, sending large initials can be prohibitive.

-- 
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/3834#issuecomment-662287250

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2020 21:32:48 -0700

In most cases, the only reason a client will need to send another large Initial is if there is loss.  In low-power conditions, coalescing of Initial and Handshake by the server can be used, at which point the client never has to send an Initial again.  Unless there is loss, the client in this case only ever sends one 1200 byte packet.  (And it probably never ever has to receive a packet that big ever again, assuming that the server doesn't decide to drop a 10k certificate on it.)

-- 
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/3834#issuecomment-662813457

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 Jul 2020 22:51:05 -0700

I can see that you might want to forego an a-priory key and pay 1200 bytes once to get a 0-RTT token.
But the 1200 initial bytes still holds for 0-RTT, no?

A low power device will frequently go to sleep, and might exceed to the idle timeout of the server (although the server might want to reconsider its timeout in that case).

I could also see a client generating its own 0-RTT token based on a-priory keys and this way get around the 1200 bytes if 0-RTT permitted that.

-- 
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/3834#issuecomment-662830421

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2020 23:06:47 -0700

QUIC still requires that the datagram be 1200 bytes, but most of that 1200 can be 0-RTT payload (after you include a token, session ticket, TLS key share, transport parameters, etc..).

A new protocol specialized to this can define a different minimum packet size.  That can be QUIC-compatible if it wants to be.  For such a constrained deployment, that might be a good choice.

-- 
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/3834#issuecomment-662834358

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Jul 2020 06:17:11 -0700

Closed #3834 via #3924.

-- 
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/3834#event-3598998309