Re: Packet number encryption

[Ian Swett <[e-mail]>]

Thanks for writing this up Martin.  I'm definitely supportive of something
like this, and I'd like to see it land in time we can try to interop with
it in London.

My intuition favors simplicity over crypto agility in this case, since
we're already forcing implementations to support AES-GCM for the handshake
packets, but I'm happy with whatever the group prefers.

On Mon, Jan 29, 2018 at 8:59 PM, Martin Thomson <[e-mail]>
wrote:

> Here's a PR:
>
> https://github.com/quicwg/base-drafts/pull/1079
>
> In short, this builds on Kazuho's excellent suggestion to use ECB-mode
> to protect the packet number.  It does this only slightly differently,
> using suggestions from ekr and others to allow for cryptographic
> agility and use of primitives that match the negotiated AEAD.
>
> In short, it takes some of the ciphertext of the packet payload, and
> uses that to encipher the packet number.  My intuition is that this is
> pretty solid, but I want to check if the working group is happy that
> this is generally OK before seeking cryptographic review.
>
> For instance, the requirement for side-channel resistance is already
> controversial: https://github.com/quicwg/base-drafts/pull/1079/files#
> r164588705
>
> For the record, I doubt that this can be proven to be secure without
> both breaking new ground and adding some constraints to the AEADs that
> we use.  And that's before we get into actual breaks on the technique
> that I'm too thick-headed to think of.  In any case, we're relying on
> this to protect against linkability, so I'd like to ensure that we're
> not completely crazy in doing so.
>
> In case people were wondering, and because it already came up: I
> intend to separately propose a change to the short header packet that
> would remove the type field and move the packet number length under
> encryption.  See my response to Ian's question on the PR for an
> explanation of how this will likely work.
>
>