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

[Juho Vähä-Herttua <[e-mail]>]

> On 29.11.2013, at 18.20, [e-mail] (Martin Rex) wrote:
> 
> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
> strongly opposed to moving the HMAC into the clear, and into particular
> I am strongly opposed to put the HMAC into the clear for the
> GenericStreamCipher PDU.

You have been quite clear about that, and I've got the impression that you are the only but very vocal opponent of encrypt-then-mac on this list. Although in GenericStreamCipher it offers no benefit, I still haven't seen a convincing argument about why encrypt-then-mac should not be used.

I'm sure you have good reasons for this opposition, so could you please explain them in one or two sentences. This excluding the "encrypting the HMAC makes it safer" argument, which might be true but as I understand is not well proven.

> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

This might be the only way to solve this problem, but I must point out that SCSVs seem to be a solution for everything now. Browsers allow a version downgrade attack? Let's add an SCSV. The CBC handling is broken? Let's add an SCSV. How many SCSV hacks can we add?

Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hacks, but I'm worried it wouldn't be adopted fast enough. Especially since CBC+HMAC AEAD ciphers that would be easiest to patch are impossible in TLS because of the way AEAD is implemented.

So I prefer fixing CBC first (with encrypt-then-mac unless otherwise proven) and then allowing AEAD in all versions to let people prepare for GCM in whatever version they use instead of trying to force TLS 1.2 upgrade with GCM, it clearly isn't working.


Juho