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

["Christian Kahlo" <[e-mail]>]

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

[e-mail], Tel. [phone], Fax [phone]

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: [e-mail] [mailto:[e-mail]] Im Auftrag von Eric
Rescorla
Gesendet: Freitag, 20. September 2013 17:53
An: [e-mail]
Betreff: [TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt

 

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