RE: Packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I wrote up my previous suggestion to use segmented packet numbers with
clear text nonce in an issue, and I added a comment where I propose a
variation that encrypts the nonce, but this encryption is 16 times faster
than the current packet number encryption scheme. In both cases there is no
duplication of nonce and packet numbers because they are the same modulo
path.

https://github.com/quicwg/base-drafts/issues/1105



On 10 February 2018 at 19.22.50, Praveen Balasubramanian (
[e-mail]) wrote:

>> a packet number **exactly** meets the requirements of an authenticated
encrypted nonce. Not using it for that purpose is being wasteful for
absolutely no good reason.

For better or worse we have chosen to tie the transport very tightly with
TLS. This means extra work will be needed for unencrypted QUIC or QUIC over
IPsec for example. Case in point transport parameters not being in the
transport header but rather in the TLS header. In HTTPS over TCP, TLS will
use its own sequence number for nonce and TCP will have its own sequence
number. This is a clear separation of concerns. From what I can tell, since
QUIC uses its own packet framing and the PN doesn’t repeat we have tried to
optimize this by overloading it with the nonce.



That said nothing prevents an implementation from using the packet number
as the nonce. By separating concerns one can pick whatever one wants for
the nonce, the receiver doesn’t care about the nonce value other than for
decryption i.e. no impact on transport logic. We can use a VLE field or
other methods to reduce the extra space needed for the PN.



>> and then encrypting the nonce

You don’t have to but you can . The only *functional* requirement for the
nonce is non-repeatability. Encryption is only being considered for
ossification and unlinkability concerns. For connections that don’t care
about unlinkability (no migration, no multi path) the overhead is not worth
it. Ossification can be avoided by a random initial value and jumps in
between since this is a form of greasing.



>> Do you have a non-authenticated crypto mechanism we should consider?

I am not a crypto expert. I don’t know what future crypto will look like.
Making the nonce field optional or larger size when needed (but not
variable for given connection) allows the transport protocol to be more
future proof. Forcing the PN to be the nonce makes things more inflexible.
I care much less about the nonce getting ossified compared to the PN.



*From:* Salz, Rich [mailto:[e-mail]]
*Sent:* Friday, February 9, 2018 3:37 PM
*To:* Praveen Balasubramanian <[e-mail]>
*Cc:* [e-mail]
*Subject:* Re: Packet number encryption



> Clear separation of concerns results if we don’t overload the packet
number as the nonce. Connection migration and multi-path are optional
features and we pay no extra compute cost for most connections that are not
impacted by unlnkability. Nonce field becomes optional for crypto that
doesn’t need it and can grow to larger size as needed for bulk transfers to
prevent frequent key rollovers (say in datacenter scenarios).



David already replied pretty definitively, but for those not on his level …



It seems highly unlikely that we will want to use non-authenticated crypto
– ie., AEAD or similar.  TLS 1.3 is all and only authenticated encryption.
The difference in cost is a few extra bytes of encryption, as opposed to
bigger packets for plaintext and then encrypting the nonce, right?  That
difference should be hard to notice.



If we assume it’s all authenticated crypto, and therefore we need a nonce,
then separation of concerns becomes a non-issue. In fact, as David pointed
out, a packet number **exactly** meets the requirements of an authenticated
encrypted nonce. Not using it for that purpose is being wasteful for
absolutely no good reason.



Do you have a non-authenticated crypto mechanism we should consider?