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

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 12:34:03 -0800

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.

-- 
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-272275618

---

From: ianswett <[email-masked]>
Date: Mon, 30 Jan 2017 12:31:31 -0800

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.

-- 
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-276181428

---

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 31 Jan 2017 02:00:42 -0800

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

-- 
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-276321942

---

From: ianswett <[email-masked]>
Date: Tue, 31 Jan 2017 06:58:46 -0800

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

-- 
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-276385893

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 15:37:16 -0800

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

-- 
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-276528977

---

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 31 Jan 2017 22:54:23 -0800

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

-- 
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-276586188