Subject: Re: [quicwg/base-drafts] Can a server use a Handshake packet for ACK of the last client Handshake packet (#829)

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Mar 2018 14:12:46 +0000 (UTC)

Per editors' meeting:  Not only can a server do this, it MUST.  Packets encrypted with the handshake key MUST be acknowledged only in packets encrypted with the handshake key.  Packets encrypted with 0-RTT or 1-RTT keys MUST be acknowledged only in a packet encrypted with the 1-RTT key.  (There might be alternative solutions, and those would be welcome.)

The reason for this is a man-on-the-side attack in which an attacker injects a cleartext packet with the same packet number as a forthcoming 1-RTT packet, causing disagreement between the peers about whether subsequent packets were actually received.  This causes data loss after the handshake is complete by leaving a hole in the received data stream.

-- 
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/829#issuecomment-373034810

---

From: Nick Banks <[email-masked]>
Date: Wed, 14 Mar 2018 07:28:38 -0700

That is not what the spec currently says:
```
8.15.3.  ACK Frames and Packet Protection

   ACK frames that acknowledge protected packets MUST be carried in a
   packet that has an equivalent or greater level of packet protection.
```
Personally, I believe ACK'ing the client finished in either handshake or 1-RTT encrypted packet should be allowed; though if I were to have to pick one, I'd prefer to go with the 1-RTT encrypted.

-- 
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/829#issuecomment-373040717

---

From: Christian Huitema <[email-masked]>
Date: Wed, 14 Mar 2018 18:33:37 +0000 (UTC)

If we want a defense against the clear text injection attack, then we need a better behavior. Because if the source has sent an 1RTT packet, and receives a clear text ACK of the same packet number, that's a protocol error and the connection will be closed. So much for DOS resistance.

-- 
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/829#issuecomment-373129593