Hi Eric, Thanks for the response!
> From: Eric Rescorla <e...@rtfm.com> > Sent: Friday, July 26, 2019 4:19 PM > To: Pascal Van Leeuwen <pvanleeu...@verimatrix.com> > Cc: draft-ietf-tls-dtl...@ietf.org > 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:pvanleeu...@verimatrix.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
