Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

What that reference shows is that for authenticate-then-encrypt mode to be
secure with cbc and otp encryption (or stream cipher), you must apply the
MAC to the plaintext after any encoding (including padding) and, in the
case of cbc, in full blocks (and, of course, with unpredictable IVs).
Unfortunately, TLS did not do it this way for cbc and that's why all these
attacks were possible. The example in the paper, while artificial, explains
well why authenticate-then-encrypt with unauthenticated encoding can go
wrong. So the math in the paper is correct - the conclusion that TLS does
it right is wrong. It doesn't.

Hugo

On Tue, Sep 16, 2014 at 6:26 PM, Bodo Möller <bodomoeller@gmail.com> wrote:

> Ryan Carboni <ryacko@gmail.com>:
>
>
>> If you're upgrading specifications, why not switch to SHA-3, which is
>> constant time (AFAIK)?
>>
>
> Part of the problem is that in TLS MAC-then-Encrypt, the position of the
> MAC tag depends on the amount of padding -- so *nothing* is constant-time
> without considerable effort.
>
> (It's funny that one of the references provided in the new RFC shows how
> MAC-then-Encrypt in TLS is supposedly secure, when the RFC came to be
> because actually it isn't.)
>
> Bodo
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>