ACK rules and packet protection

[martinthomson]

If we consider cleartext << 0-RTT << 1-RTT, then we might be able to establish a clear rule regarding acknowledgments.

The desired rule is that an ACK MUST be sent with the same or higher protection.

However: This rule would mean that a server is required to ACK 0-RTT data with 1-RTT keys. That's tricky, because loss or delay of the server's first flight also delays the server's ACKs of 0-RTT data (the server can't use 0-RTT keys).

[martinthomson]

Question: should we prohibit the server from sending a cleartext ACK. The ServerHello (or any part of the server's handshake flight, or a HelloRetryRequest) is sufficient for implicit acknowledgment of a ClientHello. Then we could ensure that clients at least don't have to worry about unauthenticated ACKs.

[ianswett]

We can prohibit a server from sending a cleartext ACK. The benefit of a cleartext ACK is an initial RTT sample on the client side in cases when the ClientHello was retransmitted. As such, I'm slightly against this restriction at this point, unless you think prohibiting it has a value I'm not aware of.

I agree that an ack must be sent with the same or higher protection than the most protected packet it is acknowledging.

[martinthomson]

OK, let me try to sketch out the proposed plan:

So the server can ACK the initial packet, replays of the initial packet, and maybe second attempts at the initial packet, but nothing else in the clear.

Unlike authenticated ACKs, a cleartext ACK can be spoofed, so we need a plan:

1. ignore a packet that acks more than cleartext packets;
2. if the packet acks more, just pretend that it only acked the cleartext packets; or
3. treat a packet that acks more as a fatal error.

I don't know whether we can do option 3. It could open us up to denial of service attacks. That leads me to think that we go with option 1 here.

0-RTT packets can't be acknowledged by the server until the handshake is complete (1-RTT keys). That means that loss of the ClientHello delays acknowledgments of 0-RTT. Moreover, it means that loss of any of the server messages also delays those acknowledgments (the client can't decrypt the ACKs in that case). Here we can (and should) require that the acks are correct; if a packet that hasn't been sent is acknowledged, we should blow up.

The interesting one is how the client acknowledges the server's first flight. Even though the client might have 0-RTT keys, the client won't know if 0-RTT has been accepted or not. If the server has rejected 0-RTT, then using 0-RTT keys to protect an ACK will make the ACK unreadable to the server.

For that reason, the client needs to acknowledge the server's first flight of messages in the clear also. That's going to follow the same rules as the server acknowledging the client messages. That makes the arrangement symmetrical given that those packets are unprotected from the QUIC perspective anyway. So the client then follows exactly the same rules as the server. Acknowledge cleartext with cleartext, even 0-RTT keys are available.

[ianswett]

The above description sounds correct to me, and I do think we want to do option 1 of the 3. Option 3 is attractive at first, but as you note, creates yet another way to tear down a connection.

[ddragana]

If packet with client hello gets lost and a 0RTT packet arrives. Acking the 0RTT packet will at the same time nack ClientHello packet and could trigger a retransmission at the client (at this point there is no rtt measurement so time based retransmissions can be tricky to time). This is option 2 - the ack packet acks 0RTT packets but nackt a CH packet. I know that 0RTT packets without a ClientHello are tricky, so I am not sure that we should use option 2 (but still I am writing this comment).

[ianswett]

You can't ack a packet until you can decrypt it, because otherwise you don't know it's valid(ie: it could be corrupted, undecryptable, etc).

[martinthomson]

Yes, it would be great if you could ack the 0-RTT packet, but you aren't able to distinguish it from net-noise.

[ddragana]

This is a small down side of having encryption strongly connected with transport.

[martinthomson]

If this is the worst we end up having to wear (not being able to immediately ACK 0-RTT), then everything is peachy.