[quicwg/base-drafts] per-CID PN space? (#1317)

[Kazuho Oku <[e-mail]>]

It seems to me that any PNE scheme without an accompanying checksum is fragile to side-channel attacks [\[1\]](https://github.com/quicwg/base-drafts/pull/1079#issuecomment-383438404), assuming that an receiver might drop a packet that contains a PN that it has already seen without decrypting the payload [\[2\]](https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382459179). However I am not sure if we want to accept the overhead of including the checksum of PN in every packet.

Leak of PN is a privacy issue because we share a single PN space among multiple CIDs.

Considering that, it might be a good idea to consider if we can have different PN space for each CID.

As an example, I think that the making following changes to the drafts would be sufficient to have per-CID PN space.

* maximum value of the Sequence field in the NEW_CONNECTION_ID frame (hereafter referred to as _CID sequence number_) will be set to UINT32_MAX. Note that CID sequence number is never reused.
* CID sequence number of the first CID will be changed from -1 to 0
* every ACK frame will have a CID sequence number field. The field carries the sequence number of the CID to which the acked packets belong
* AEAD nonce will be the concatenation of the CID sequence number and the per-CID packet number, which will be 94-bits long. Per RFC 5116, we can reasonably assume that every AEAD scheme will be capable of handing a nonce of that size.

The pros of the approach are:
* PN leak is no longer a privacy concern. It becomes purely an ossification issue that can be resolved separately.
* RTT can be measured separately for each CID

The primary concern will be that the implementations will be required to record PNs and send ACKs for each CID rather than for the entire connection. If that is a deal-blocker, we can consider retaining the current ACK format by changing the proposed approach so that the concatenation of CID sequence number and the per-CID PN would fit into 62-bits (e.g., 16-bit CID sequence number and 46-bit PN).

On the sender side, we can continue living with just one loss recovery / congestion control device per connection. This is because in QUIC v1 a sender never sends retransmittable frames through under multiple CIDs at the same time.

[1] https://github.com/quicwg/base-drafts/pull/1079#issuecomment-383438404
[2] https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382459179

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