Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

[Wan-Teh Chang <[e-mail]>]

I am a programmer working on the NSS crypto libraries. Here are my
thoughts on this issue.

1. Since TLS 1.0 is widely deployed, we don't need to fix this issue
for SSL 3.0. This will avoid the need to add another SCSV.

2. I prefer a TLS extension that changes how CBC block ciphers work,
rather than adding new AEAD ciphers based on CBC-HMAC. (We already
have too many cipher suites.) In addition, CBC block ciphers should
work in this new way by default in TLS 1.3.

An argument for adding new AEAD ciphers based on CBC-HMAC is that it
simplifies testing. The extension-based solution essentially forks
every TLS version and increases the number of combinations that need
to be tested.

3. I took a look at the TLS/SSL implementation in NSS. I believe that
the EtA and pad-MAC-Encrypt proposals should require similar amount of
change to the NSS source code.

Ignoring the details of padding, It boils down to reordering the
operations this way:
    MAC-pad-Encrypt => pad-MAC-Encrypt
vs. reordering the operations this way:
    MAC-pad-Encrypt => pad-Encrypt-MAC

So the assertion that pad-MAC-Encrypt requires a smaller patch doesn't
seem to be true for NSS. Caveat: it's possible that the arguments
passed to the three operations need more adjustments when the
operations are reordered in one way. I didn't look into that.

4. The TLS/SSL implementation in NSS performs the padding itself
rather than letting the underlying encryption function do the padding.
This means the pad-MAC-Encrypt proposal won't make things more
difficult for NSS in this aspect.

Wan-Teh Chang