Subject: [quicwg/base-drafts] ACK rules and packet protection (#34)

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Nov 2016 21:49:44 -0800

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

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Nov 2016 21:00:44 -0800

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.

-- 
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/34#issuecomment-263476839

---

From: ianswett <[email-masked]>
Date: Tue, 29 Nov 2016 06:37:25 -0800

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.

-- 
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/34#issuecomment-263586592