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

[Alfredo Pironti <[e-mail]>]

On Sat, Nov 30, 2013 at 7:02 PM, Watson Ladd <[e-mail]> wrote:
> On Sat, Nov 30, 2013 at 9:58 AM, Alfredo Pironti <[e-mail]> wrote:
>> Hi Kenny,
>>
>>> But, at the risk of repeating myself, I very much prefer the simplicity
>>> and robustness of an Encrypt-then-MAC construction.
>>
>> I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
>> the only two cipher modes I'd like to see in TLS 1.3.
> You do realize EtM is an AEAD if properly designed?

I do. I was just speaking in TLS1.2 terminology, which does make a
distinction, even though all schemes are supposed to deliver
Authenticated Encryption with Additional Data anyway. If I just said
that I only wanted AEAD, somebody else would have shoot at me instead
by saying that GCM is too inefficient.

>>
>> In practice however, we witness the disastrous experience in widely
>> deploying any change which is not a small patch to TLS1.0. So I'm
>> afraid that to get something deployed in reasonable times we may have
>> to get content with such a patch, like pad-MAC-Encrypt, that makes
>> more robust (if not provably secure) what we already have.
> How is pad-MAC-Encrypt less of a change then Encrypt then MAC?

It is easier enough in that 2 implementations already implement pad-MtE
(GnuTLS and miTLS), and my personal experience in implementing the
patch says it's a small change.

But we need even more factual feedback, and I hope we get more people
to try to implement it elsewhere.

> We still can't kill RC4, which is a *configuration change*.
> Patches aren't getting deployed even if painless, so arguing about the
> ease of deployment is a red herring.
>>
>> Alfredo
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin