Re: Packet number encryption

[Kazuho Oku <[e-mail]>]

2018-02-02 21:24 GMT+09:00 Mirja Kühlewind <[e-mail]>:
> Please see below.
>
>> Am 02.02.2018 um 01:56 schrieb Kazuho Oku <[e-mail]>:
>>
>> 2018-01-31 19:00 GMT+09:00 Eggert, Lars <[e-mail]>:
>>> On 2018-1-31, at 10:52, Gorry Fairhurst <[e-mail]> wrote:
>>>> +1 - Simply: This *is* complicated and seems to add little.
>>>
>>> So as an implementor (chair hat off), this adds very little to the overall complexity of the protocol.
>>
>> +1
>>
>> The algorithm defined in the PR is easy to implement.
>
> I didn’t say that it is too complex (I actually explicitly said in my original mail  it is not very complex) but it adds additional complexity to a protocol that is already complex and doesn’t provide much benefit from my point of view but can be an additional source for errors.

Regarding CID migration, I would argue that the current draft is
already complex due to the use of HKDF based on a derived key to
calculate the gap. But it still has issues (please refer to
https://github.com/quicwg/base-drafts/issues/1034).

Switching to packet number encryption resolves those issues. You no
longer need to do special calculation of the packet number upon CID
migration.

Having a consistent logic to handle packet numbers is IMO a better
choice than requiring complex operations in a corner case.

> After all it must also be possible to implement QUIC if you just read the final specs and have not participated in the wg design discussion or can easy ask a clarifying question on the list.
>
>>
>> When using OpenSSL what you need to do is:
>
> If you don’t want to use OpenSSL or are in an environment where you can use such a library, it is definitely more complex than this.

I agree that the mileage may vary depending on the crypto library you use.

However, I would also argue that it would be fairly natural to assume
that you have access to the underlying cipher of an AEAD cipher that
you would be using (e.g. AES-ECB (or AES-CTR) for AES-GCM, Chacha20
for Chacha20-Poly1305). Then, it is easy to construct the proposed
logic, though you might need to write code specific to each cipher.

>
>>
>> * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a
>> CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key
>> passed as the argument.
>>
>> * for each packet, call EVP_EncryptInit_ex to set the IV to the 16
>> bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain
>> the encrypted packet number
>>
>> Decryption is exactly the same as encryption, since it is CTR mode.
>>
>> To me it seems that using packet number encryption actually simplifies
>> the implementation, since we no longer need to care about randomizing
>> the initial packet number or implement special measures to avoid
>> linkability when switching to a new CID.
>
> Choosing a random number is definitely less complex than encrypting something. It might simply your current code because you are using a library that implements the complexity already. And special measures when switch to a new path are needed anyway for the CID.

I agree that calculating a random number is not a big deal. Regarding
the amount of the special measures in relation to CID migration,
please refer to my comment above.

>
> Mirja
>
>
>
>
>>
>>> Lars
>>
>>
>>
>> --
>> Kazuho Oku
>



-- 
Kazuho Oku