Subject: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Sep 2013 08:52:58 -0700

Peter,

After reviewing this document I have a few comments/questions:

- Because this draft relies on extensions, it seems not to resist
  active attack when clients do insecure version fallback
  (see for instance:
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
  The existing attacks appear to principally be active attacks on the
browser
  environment, which is where fallback tends to happen.

- Maybe I am misreading the draft, but I'm unclear on how you get
   the TLSCompressed.length for the MAC computation in Section 3.
   Does this have the same issue as was raised for McGrew's CBC AEAD
   draft?

Am I missing something here?

Thanks,
-Ekr

---

From: "Christian Kahlo" <[email-masked]>
Date: Fri, 20 Sep 2013 18:10:56 +0200

Hi Eric,

just as side note. The Germen Federal Office for Information Security also
had a look

on this. See BSI TR-03116-4.

<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Technisch
eRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile>
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Technische
Richtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile

I'm sorry, there is no english translation yet. But it will be translated
later.

On page 8, chapter 2.3, "Weitere Vorgaben" / "More specifications", 4th
bullet.

It reads that Encrypt-then-Mac should be preferred instead of
Mac-then-Encrypt.

The reasons are rather simple: GCM is not yet available everywhere. One

example are Java/JDK environments without additional crypto providers used

with many application servers.

Even some other standards bodies like ISO, CEN, BSI, etc. agreed on
CBC-modes

(with or without EtM) as a lowest common factor with TLS.

So CBC WILL(!) exist regardless what you're specifying here. ;-)

There also at least implementations in our Federal project, OpenSSL, Bouncy

Castle and as I heard CyaSSL, too.

The discussion isn't about AEAD or not, the discussion is about a protocol
design

flaw lasting now for more than FOURTEEN YEARS.

Just compare it to ISO7816-4 secure messaging. EtM has been there from the

beginning.

Cheers,

Christian

-- 

Christian Kahlo, Research Manager IT-Security,  <http://www.ageto.de/>
http://www.ageto.de

[email-masked], Tel. +49-3641-3678-305, Fax +49-3641-3678-101

AGETO Innovation GmbH, Winzerlaer Straße 2, D-07745 Jena

Geschäftsführung: P. Israel, S. Sauer, S. Scheppe HR: Amtsgericht Jena, HRB
210399

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Eric
Rescorla
Gesendet: Freitag, 20. September 2013 17:53
An: [email-masked]
Betreff: [TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt

Peter,

  (see for instance:

   draft?

Thanks,

-Ekr

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 22 Sep 2013 19:34:34 +0100

On 20/09/2013 17:10, Christian Kahlo wrote:
> 
> Even some other standards bodies like ISO, CEN, BSI, etc. agreed on CBC-modes
> 

This has some interesting parallels with FIPS 140-2. Currently the only approved
symmetric algorithms for FIPS 140-2 and TLS are AES-GCM, AES-CBC and DES3-CBC.
If you can't deploy TLS 1.2 you're then stuck with CBC.

Getting new algorithms approved by a standards body wont happen overnight and
might not happen at all. Algorithms tests and implementation guidance,
discussion periods etc will be needed all of which takes time.

On top of that adding new algorithms to an existing module requires retesting,
typically on every platform affected. That is expensive and laborious but wont
dent larger corporations budgets much. What will hurt more is that getting a new
validation done might take 9 months to a year after submission (more in some
cases) to get final approval.

What that means in practice is that when ciphersuites using new algorithms are
approved for TLS expect a delay of 1-2 years before they can be deployed with
FIPS 140-2 and they may not even get approved at all.

By contrast Peter's ETM spec, as it doesn't need any new algorithms, could be
deployed as soon as it is approved.

I'm not saying that we don't approve new algorithms and ciphers suites. I'm
saying we need ETM as well.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Bill Frantz <[email-masked]>
Date: Sun, 22 Sep 2013 15:09:54 -0700

> saying we need ETM as well.

I would also like to see Peter's ETM spec move forward.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, CA 95032

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Sep 2013 09:03:18 +0200

> If you can't deploy TLS 1.2 you're then stuck with CBC.
[...]
> spec, as it doesn't need any new algorithms, could be

What we need is a solution for the issue with the unauthenticated
padding in the CBC ciphersuites. ETM is not the only way to solve the
issue, and even if it is used, it would be highly recommendable to
follow the existing good practices. TLS isn't the first protocol to use
this mode, thus there isn't a need to innovate.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Sep 2013 15:53:21 +0200

On 09/23/2013 02:50 PM, Christian Kahlo wrote:

> maybe you want to read http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
> and http://www.iacr.org/archive/crypto2001/21390309.pdf.
> Both mentioned within this thread:
> http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-
> encrypt-then-mac

Have you actually read the papers you mention? For example have you seen
theorem 2 of the second paper? The issue is with the unauthenticated
padding used in TLS not AtE. There are only philosophical advantages of
EtA over AtE when the latter is implemented properly (i.e., as not in
TLS). Today we have more clues on the issues of AtE than it was at the
time TLS was designed.

> Please tell us which protocols are still using Mac-then-Encrypt today
> without running into any security trouble (esp. chosen ciphertext
> attacks). MtE is considered as a design fail by many researchers.

TLS with stream ciphers. It is authenticate-pad-then-Encrypt that has
issues, please check the literature more carefully.

> As we discussed earlier AEAD might be a solution, but AEAD is not the
> only one. I would encourage everbody to also have a look into
> ISO7816-4 secure messaging. That's the way most electronic ID cards,
> electronic purse cards, credit cards, small HSMs, etc. do communicate.
> And now think about that there's a reason for that it's an EtM-
> scheme.
> Sorry, your attitude "there isn't a need to innovate" sounds
> somewhat unfamiliar with cryptographic primitives to me.

Please read my mail again. The innovate refers to how the current EtA
proposal by Peter ignores all best practices in implementing EtA in
protocols. Existing EtA protocols like IPSec truncate the HMAC to avoid
revealing the whole internal state of the hash algorithm. The
Preneel-van-Oorschot paper referenced previously in the thread gives a
detailed treatment of the issues (admittedly HMAC was designed to
discourage these attacks, but being conservative is a good design practice).

regards,
Nikos

---

From: "Christian Kahlo" <[email-masked]>
Date: Mon, 23 Sep 2013 14:50:07 +0200

Nikos,

Cheers,
Christian

---

From: "Christian Kahlo" <[email-masked]>
Date: Mon, 23 Sep 2013 18:11:25 +0200

Hi Nikos,

> > http://crypto.stackexchange.com/questions/202/should-we-mac-then-
> > encrypt-or-encrypt-then-mac
> Have you actually read the papers you mention? For example have you

Phew, years ago probably. I just looked them up.

> seen theorem 2 of the second paper? The issue is with the

Yes.

> unauthenticated padding used in TLS not AtE. There are only

And that's why it shouldn't be used this way. :-)

> philosophical advantages of EtA over AtE when the latter is implemented
> properly (i.e., as not in TLS). Today we have more clues on the issues
> of AtE than it was at the time TLS was designed.

That's absolutely right of course. MtE is in SSL/TLS at least since
1996-03-04.

> issues, please check the literature more carefully.

I've read it. Actually, what we're doing with EtM is Pad-then-Encrypt-
then-Mac.
Regarding stream ciphers: yes, but keep in mind people like to mix it
up with RC4 and you've to say you mean i.e. AES in CTR mode or similar.

> > Sorry, your attitude "there isn't a need to innovate" sounds somewhat
> > unfamiliar with cryptographic primitives to me.
> 

Done that.

> proposal by Peter ignores all best practices in implementing EtA in

OK, got it. To me it read like "no need to innovate" as in "no need to
change".

> protocols. Existing EtA protocols like IPSec truncate the HMAC to avoid

You've got RFC 6066 truncated_hmac if you want it to do this way.
Peters approach to keep things as much as simple as possible seems
OK to me.

> revealing the whole internal state of the hash algorithm. The Preneel-
> van-Oorschot paper referenced previously in the thread gives a detailed
> treatment of the issues (admittedly HMAC was designed to discourage
> these attacks, but being conservative is a good design practice).

We've had a lot of discussions about this. Strictly speaking if a non-
truncated HMac reveals (too much) information of the internal state of
the hash algorithm something totally went wrong with the hash function.

As a result of this BSI TR-03116-4 chapter 2.3, 1st bullet states
"do not use truncated_hmac". I'm sorry again for the lack of an english
translation at the moment. The Federal Office for Information Security
will probably provide one later.

In THEORY a truncated_hmac offers an option for attacks as only a
fraction of the original HMac has to match.

Best regards,
Christian

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 24 Sep 2013 12:47:19 -0400

> the hash algorithm something totally went wrong with the hash function.

There are two issues. One is how much info the non-truncated MAC reveals. Another one is that it enables key guessing with just one valid message+MAC pair.

> will probably provide one later.

I wonder what their reasoning is.

> In THEORY a truncated_hmac offers an option for attacks as only a fraction of the original HMac has to match.

Certainly.  It reduces the collision-creating space from square root of full MAC size to square root of truncated MAC size. For the benefit of requiring 2^(# of truncated bits) valid MACs to successfully forge a MAC. 

With modern MACs and keys either attack should not be practical. Still, I personally prefer to truncate, though not necessarily all the way down to 96 bits.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Sep 2013 13:11:00 -0700

Peter,

Do you think you could address the questions I asked below?

Thanks,
-Ekr