Re: Getting to consensus on packet number encryption

[Christian Huitema <[e-mail]>]

On 4/16/2018 11:15 PM, Kazuho Oku wrote:
> Hi Christian,
>
> Thank you for writing the wonderful summary.
>
> Reading it, I think that I now see two issues with the alternative
> approaches that use a weaker cipher (i..e. alternative PN encryption,
> 64bit encrypted PN).
>
> > We can argue that the algorithm does not have to be as robust as
> AES.. The main requirement is to prevent real time analysis of
> sequence numbers by middle-boxes. This is achieved as long as the
> encryption key cannot be retrieved in a short time by the
> middle-boxes. If they could do that, we would be once again on the
> path to ossification. XOR and simple obfuscation probably don't meet
> that goal, but IPCrypt probably does, and a more robust algorithm
> certainly would.
>
> As you state, it is true that preventing real time analysis is
> important. But are we sure that we do not need to consider offline
> attacks? I would be interested in arguing about the other requirement
> than ossification: privacy.
>
> A pervasive monitor might collect CIDs and encrypted PNs that were
> being used, and then use the encrypted PNs as a source to correlate
> CIDs to reconstruct a QUIC connection. Are we sure that a weak cipher
> does not leak such trace?

Yes, you are right. The argument about tolerating weak algorithms only
applies if we have another solution to prevent linkability, such as
different sequence numbers and encryption keys for each Connection ID.
So it comes with a high cost in term of software complexity.


>
> Considering that, I think that the alternative approaches should have
> per-CID PN encryption keys, even though I am not sure if there are no
> other privacy-related issues.
Yes.
>
> The other issue is about crypto agility. #1179 has agility in sense
> that the corresponding CTR mode is used for encrypting the PN. OTOH,
> the two alternatives using a simple cipher are not agile. So we might
> need to define two types of simpler ciphers for PN encryption, if
> consider that privacy issues (like the one above) might arise in the
> future.
Yes.  I updated the Wiki page to reflect your comments.

-- Christian Huitema