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

[Nikos Mavrogiannopoulos <[e-mail]>]

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

>>> I'm not saying that we don't approve new algorithms and ciphers
>> suites. I'm
>>> saying we need ETM as well.
>>
>> 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.
> 
> 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