Subject: Re: [TLS] TLS1.3

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Feb 2013 10:48:52 +0000

"Lewis, Nick" <[email-masked]> writes:

>Is this really ok for all cipher suites?

Can't see why it wouldn't be.

>In those cases that the hash is weak e.g. MD5-HMAC maybe the underlying key
>could be exposed?

Problems with MD5 don't affect HMAC-MD5.

>Padding the plain text up to a multiple of the cipher block size (minus the
>hash size) ahead of doing the MAC is a more modest change that may be more
>widely applicable to existing cipher suites - with a "pad-then MAC" client
>hello

That won't help against the current attack.  The only proper fix for the
various attacks that target the encryption is to protect everything with the
MAC, i.e. switch to encrypt-then-MAC.  The definitive reference for this is
Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting
Communications (Or: How Secure is SSL?)".

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 8 Feb 2013 13:50:01 +0100

On Fri, Feb 8, 2013 at 11:48 AM, Peter Gutmann
<[email-masked]> wrote:

> That won't help against the current attack.

This family of attacks relies on the fact that padding isn't
authenticated, i.e, you can play with it without being detected. If
pad is part of the MAC there is no issue.

> The only proper fix for the

Using encrypt-then-MAC to counter the attack is as radical change as
using the GCM or CCM modes. This isn't a small fix, it is an upgrade
which changes the protocol semantics (e.g. MAC is no longer encrypted
- whatever that may mean). Moreover, encrypt-then-MAC isn't a panacea.
There is nothing wrong with MAC-then-encrypt, it is TLS that applied
it incorrectly by keeping the pad unauthenticated. I'd prefer a fix
that keeps the current protocol semantics.

regards,
Nikos

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 8 Feb 2013 13:03:40 +0000

Nikos, all

> using the GCM or CCM modes. 

I agree. It will take work. But it's time for that kind of change.

> This isn't a small fix, it is an upgrade

It fixes every problem I can conceive of. And I've thought about the analysis of TLS's current MAC-pad-encrypt construction long and hard, believe me.

> There is nothing wrong with MAC-then-encrypt, 

I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000 and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good reasons to be suspicious of MAC-then-encrypt from a theoretical perspective. 

And in practice, time and again it's proven to be problematic. And not just in TLS (see for example my paper with Jean Paul Degabriele at ACM-CCS 2010 about MAC-then-encrypt configurations of IPsec. TL;DR: we broke them all).

Cheers

Kenny

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Feb 2013 20:04:04 +0100 (CET)

> Communications (Or: How Secure is SSL?)".

I disagree.  What you're saying is that the countermeasures that
are currently being adopted would not help against the current attack.

I do believe that pad, hash, encrypt would be sufficient (while still being
sensitive about ensuring the same codepath).

Looking at the original Paper from Sergey Vaudenay from 2001:

  http://infoscience.epfl.ch/record/52417/files/IC_TECH_REPORT_200150.pdf

  Section 5.1  SSL/TLS 2nd paragraph  (page 6):

  TLS v1.0 also provides an optional MAC which failed to thwart the attack:
  when the server ¯gures out that the MAC is wrong, it yields the bad_record_mac
  error. However, the message padding is performed after the MAC algorithm, so
  the MAC does not preclude our attack since it cannot be checked before the
  padding in the decryption.

explains that TLS has is susceptible to the timing attack due to
MAC-then-pad, and then describes in

  Section 6.5 CBC-PAD with Integrity Check

  One can propose to add a cryptographic checkable redundancy code
  (crypto-CRC) of the whole padded message (like a hashed value)
  in the plaintext and encrypt

                message|padding|h(message|padding)

  This way, any forged ciphertext will have a negligible probability
  to be accepted as a valid ciphertext. Basically, attackers are no
  longer able to forge valid cipher-texts, so the scheme is virtually
  resistant against chosen ciphertext attacks.

  Obviously it is important to pad before hashing: padding after
  hashing would lead to the a similar attack. The right enciphering
  sequence is thus

                pad, hash, encrypt

  Conversely, the right deciphering sequence consists of decrypting,
  checking the hashed value, then checking the padding value.
  Invalid hashed value must abort the decipherment.

Making the code use the same CPU cycles would definitely _much_ easier
with TLS doing pad-MAC-encrypt, then with the original MAC-pad-encrypt.

I'm actually slightly puzzled why this change was not made in TLSv1.1
along with backwards-incompatible change of the GenericBlockCipher PDU
that added an explicit IV.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Feb 2013 23:51:07 +0100

> 
> I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000
> and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good
> reasons to be suspicious of MAC-then-encrypt from a theoretical
> perspective.

It could be, and I cannot offer any insight on whether these theoretical
weaknesses, have any practical effect.

However, the switch from MAC-then-Encrypt to Encrypt-then-MAC mode of
operation is a radical move that does not affect only the CBC ciphers
(e.g. RC4-SHA1 is also MAC-then-Encrypt).

> And in practice, time and again it's proven to be problematic. And

> not just in TLS (see for example my paper with Jean Paul Degabriele
> at ACM-CCS 2010 about MAC-then-encrypt configurations of IPsec.
> TL;DR: we broke them all).

I understand, and such attacks can indeed occur if there are encrypted
data that are left unauthenticated by the MAC (e.g., as the pad is in
TLS now). My sentence referred to a MAC-then-encrypt operation that
encrypts and authenticates all data (including any pads).

regards,
Nikos

---

From: [email-masked] (Martin Rex)
Date: Sat, 9 Feb 2013 02:29:07 +0100 (CET)

> pad is part of the MAC there is no issue.

I agree with Nikos.

The problem of TLS is that it does not authenticate the entire
decryption output (i.e. uses MAC-pad-encrypt rather than pad-MAC-encrypt).

> > Communications (Or: How Secure is SSL?)".

To me, Hugo's "proof" that AtE would have a "general weakness"
is misleading (and slightly bordering on lame).

He proofs a security problem *ONLY* for a MAC-extend-encrypt scheme,
and only under the condition of the availablility of a decryption oracle
that will blissfully answer a huge amount of chosen ciphertext attacks.

Potentially not realizing that the existing MAC-pad-encrypt approach
in SSL/TLS is one incarnation of the dangerous MAC-extend-encrypt schemes,
Hugo's paper incorrectly asserts this (last paragraph on page 3):

  The security of AtE with specific encryption modes.

  This paper does not bring just bad news. We also show that the
  authenticate-then-encrypt method is secure under two very common
  forms of encryption: CBC mode (with an underlying secure block cipher)
  and stream ciphers (that xor the data with a random or pseudorandom pad).
  We provide a (near optimal) quantified security analysis of these
  methods. While these positive results do not resolve the
  "generic weakness" of the authenticate-then-encrypt method
  (and of SSL), they do show that the common implementations currently
  in use do result in a secure channels protocol.

CBC-padding is simply an incarnation of "extend" in MAC-extend-encrypt.

And the addition of unauthenticated-but-encrypted information may allow
breaking the confidentiality of the cipher, given sufficient responses
from the decryption oracle, frobbing the ciphertext block covering the
unauthenticated part and getting the de-padding function to oracle
about characteristics of the resulting plaintext block.

> that keeps the current protocol semantics.

Personally, I also feel somewhat uncomfortable with a "radical" change
to encrypt-then-MAC rather than the simply using the obvious
pad-MAC-encrypt, as originally suggested by Serge Vaudenay.

When the encryption scheme that is used is bijective, then it will not
matter (to the confidentiality of the encryption) whether AtE or EtA
is used, as long as authentication covers the exact same information
in both cases, i.e. *ALL* of it, padding included.

However, in the EtA scheme, we would have a naked keyed hash.  And would
an attack on the keyed hash become somehow feasible, that attack might be
easier on a naked keyed hash than on an encrypted keyed hash.

-Martin