Re: Getting to consensus on packet number encryption

[Mirja Kühlewind <[e-mail]>]

Hi Ted,

based on what you say here, I’d like to further pick on an important point

> Am 04.04.2018 um 20:06 schrieb Ted Hardie <[e-mail]>:
> 
> My emphasis is slightly different:  how much does this choice constrain the working group's later choices?  From my take, making the choice to encrypt the packet number in v1 has the lesser set of constraints, because it is possible for later versions to add a path-visible signal of sequence numbers if we see a reason to do so.  That set of sequence numbers might not be the same as those being used for protocol state mechanics by the endpoints, but that's okay as they wouldn't be serving the same purpose.  

Currently the PN is used for a least two different purposes: 1) congestion control/retransmissions and as 2) input for the decryption. For the first purpose, the PN would not need to be in the wire image and could just be part of the encrypted payload. I guess the main reason that we use the same bits for both purposed is to save bits...

While you say, we can still add an unencrypted PN for a third purpose (measurements), it is also possible to add any time later (in a new version or with extension frames) a separate PN for 1 to the fully encrypted part of the packet that is independent of the exposed packet number (in case that gets ossified and does not address the needs of the quic transport machinery anymore). 

So even if the exposed PN gets ossified, I think we still have ways to handle that. However, the question is, do we want to burn the bits and complexity now, or later when we might (or might not) figure out that it is needed?

Mirja