RE: Packet number encryption

[Praveen Balasubramanian <[e-mail]>]

>> 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?