Re: [TLS] draft-ietf-tls-dtls13 - sequence number encryption

[Pascal Van Leeuwen <[e-mail]>]

Hi Eric,

Thanks for the response!

> From: Eric Rescorla <[e-mail]> 
> Sent: Friday, July 26, 2019 4:19 PM
> To: Pascal Van Leeuwen <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-ietf-tls-dtls13 - sequence number encryption
>
> Hi Pascal,
>
> Thanks for your note. I would encourage you to send it to the TLS WG (this alias just goes to the authors). With that said, some comments below
>
I guess I clicked the wrong emai button - sorry about that. I added the WG email to the cc list.

>> On Fri, Jul 26, 2019 at 1:53 AM Pascal Van Leeuwen <mailto:[e-mail]> wrote:
>> In draft 29, sequence number encryption was added. Now I can't find any rationale for 
>> doing so in the draft (tampering with it was already detectable as it's authenticated), 
>> and I don't know of any other protocol encrypting the sequence number, but the way 
>> that that's currently specified makes HW implementation very difficult and costly, 
>> so some proper cost-benefit analysis would be appropriate IMHO.
>>
>> The current specification calls for encrypting the sequence number by XOR-in it with
>> the output of encrypting part of the ciphertext. From a hardware perspective, this 
>> means either taking the output of your encryption pipeline and feeding it back into
>>  the input (killing performance!) -or- adding another full encryption pipeline behind
>> the already existing one, which is very costly (and not useful for anything else).
>
> Yeah, we're aware of that. It's kind of unfortunate, but we didn't really have another option.
>
Sounds like that, from the rest of the response. Although I still wonder why this is so 
important. The RFC does not say much about the why at the moment.

>> I would propose the following options to be considered (in the order from most
>> desirable to least desirable, from a HW implementation point of view):
>>
>> 1) Making the sequence number encryption optional, to be negotiated, to
>> allow trading off between performance/cost and the added security which
>> is also not provided by any existing alternatives either
>>
> This was discussed and rejected, but it's certainly somethign you could raise again
>
Would that help? I suppose it was rejected for a good reason ...

>> or
>>
>> 2) Encrypt the sequence number as part of the normal data stream
>> (Or am I missing some security implications for doing it that way? I guess 
>> it would add some known and/or easy to guess plaintext but the encryption
>> algorithm used (AES or Chacha20) should be strong enough to resist that.
>> I understand you don't want to decrypt the full packet before you do the 
>> anti-replay check, but that can still be done even if you do it this way by
>> just doing the sequence number check after decrypting sufficient data
>> to access it, but before decrypting the rest of the payload)
>>
> I don't believe that this will work, because the sequence number is used to
> generate the AEAD nonce, so you will not be able to decrypt.
>
Ah yes, for TLS 1.3 the IV is now implicit and taken from the sequence number.
I didn't realise that for a second, my bad . I guess that's a good reason and having 
the nonce encrypted complicates the HW design even further, unfortunately :-(

>> 3) Use some other alternative way to obtain the sequence number 
>> encryption keystream that doesn't depend on the ciphertext output,
>> e.g. by encrypting the/some nonce with some other secret key.
>>
> We were unable to find a way to do this that didn't have a lot of data expansion.
>
Using input that's NOT the input or output to the main cipher would already help a lot ...
but with the nonce itself out of the picture there's indeed not a whole lot you can use
without having to add it to the encapsulated packet. Not having any bright ideas at
the moment.

> Incidentally, QUIC has exactly the same design, so you may want to raise this
> issue there as well.
>
Ok, good to know,  although we don't do anything with QUIC at the moment.

>
> -Ekr
>
>> or
>>
>> 4) At the very least, don't make the sequence number encryption depend
>> on the main ciphersuite but e.g. always make it use AES-ECB. Or ...
>> make it seperately negotiatable so you can at least always select AES-ECB.
>> Why? Because then at least that 2nd encryption engine only needs a 
>> single algorithm instead of 2 (or more), saving precious chip area ...

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
http://www.insidesecure.com