Re: Removing packet number gaps

[Martin Thomson <[e-mail]>]

On Tue, Jan 2, 2018 at 3:11 PM, Christian Huitema <[e-mail]> wrote:
>> On Jan 1, 2018, at 7:38 PM, Martin Thomson <[e-mail]> wrote:
>>
>>> On Tue, Jan 2, 2018 at 1:13 PM, Christian Huitema <[e-mail]> wrote:
>>> For clarification: are you proposing to make the encryption key and IV dependent on the connection ID, or just the packet number mask?
>>
>> Both.  As you argue in your draft, this makes some things easier, and
>> it fits more naturally if the key, IV, and mask all have similar
>> derivations.
>
> Yes, it seems natural. But there is at least one downside: both peers need the master secret available when creating or receiving a new connection ID. In the current design, the master secret can be erased once encryption keys have been initialized.

You need the packet protection secret around if you ever want to do a
key update.

> OTOH, with that design we can get rid of the key phase mechanism. To refresh the key, just start using a new connection ID.

True, but that would remove the post-compromise security that we get
from the current design.

>>> Also, are you proposing applying the mask before encoding the packet header on 1, 2, 4 or 8 bytes, or after that?
>>
>> After.  We'd have to be careful to get the bit alignment right, of course.
>
> You don't actually need to be careful with the XOR solution. Just XOR four bytes after completing the payload encryption, and XOR then again before decrypting the payload.

You have to get the right part of the 4 (or 5) bytes or it will fail.
That means a htonl() call, but that's easy.  Though I note that if we
do as Igor suggests, then we get that number just once per connection
ID (with  a call to ntohl() at that point) and add before encoding and
you don't have to worry about the truncation bit.

> By the way, can we get 5 bytes instead of just 4? With the 5th byte, we could grease the lower bits of the first byte, greasing the packet type.

Sure.  I didn't want to burden everyone with this, but it's an obvious
extension.