Subject: [ietf-tls] Re: A design weakness of SSL/TLS (fwd)

From: James Morris <[email-masked]>
Date: Fri, 15 Jun 2001 09:50:13 +1000 (EST)

Niels asked me to forward this to the list, as his mail bounced from the
server.

---------- Forwarded message ----------
Date: Thu, 14 Jun 2001 21:43:13 +0200
From: Niels Ferguson <[email-masked]>
To: James Morris <[email-masked]>,
     IETF Transport Layer Security WG <[email-masked]>
Cc: Hugo Krawczyk <[email-masked]>, [email-masked],
     [email-masked]
Subject: Re: [ietf-tls] Re: A design weakness of SSL/TLS

At 23:08 14/06/01 +1000, James Morris wrote:
>On Thu, 14 Jun 2001, Bodo Moeller wrote:
>
>> Hugo Krawczyk <[email-masked]>:
>>
>> > In a paper to be presented in the upcoming CRYPTO'2001 conference (and
>> > available at http://eprint.iacr.org/2001/045/)  I show that
>> > the ORDER of encryption and authentication as applied to the transmitted
>> > data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security
>> > guarantee than expected.  Somewhat surprisingly, it turns out that
>> > there are very strong ciphers (e.g. providing Shannon's perfect secrecy)
>> > that in combination with any secure MAC (even one with unconditional
>> > security) make SSL/TLS vulnerable to attack.
>>
>> Is this really that surprising?  Note that Mihir Bellare's and
>> Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption:
>> Relations among notions and analysis of the generic composition
>> paradigm" already shows that Encrypt-then-MAC is sound while
>> MAC-then-Encrypt and MAC-and-Encrypt have problems.
>>
>
>It's interesting that Ferguson and Schneier's paper "A Cryptographic
>Evaluation of IPSec" criticises IPsec's Encrypt-then-MAC for violating
>the Horton Principle (authenticate what was meant, not what was said), and
>refers to SSL's authentication of plaintext as the correct method.

I just got a copy of this from James Morris. I'm not on the TLS list so I
don't know the context in which this discussion is taking place. I do have
some comments.

The "Horton Principle" was formulated after encountering problems in real
systems. In our years of consulting we had the opportunity to analyse many
fielded systems, including many proprietary ones. We broke the
authentication property of several systems because the authentication would
not extend to the contextual information used to interpret the
authenticated data. In an encrypt-then-authenticate system the receiver
first checks the authentication and then decrypts the (authenticated)
ciphertext. If the receiver is using a different decryption key than the
original sender intended to be used, then the received plaintext will be
incorrect even though the message was authenticated.

This is one of the problems that we found in IPsec. A (re)negotiated ESP
connection inside a manually keyed AH connection does not provide
authentication. This is of course a contrived configuration, but it is
something allowed by the standard, and presumably allowed by many IPsec
implementations.

The basic "Horton Principle" rule is to authenticate what is meant, not was
is said. The easiest way to do this is to authenticate-then-encrypt. (The
authentication should also include all other system data that is used in
assigning meaning to the message, but that is not relevant in this
discussion.)  Alternatively you can encrypt-then-authenticate as long as
you include the decryption key in the authentication. Many systems don't do
this, and rely on the fact that the authentication and encryption keys are
tied together through the key negotiation protocol. This is a valid
approach, but we have seen enough key negotiation protocols that do not
have this property. I have never seen it specified as a requirement for the
negotiation protocol. Adding such hidden requirements to other modules of
the system is a bad idea.

I scanned through Hugo Krawczyk's paper (http://eprint.iacr.org/2001/045/)
to look at the (claimed) problem with authenticate-then-encrypt. The
encryption scheme that leads to a weakness in authenticate-then-encrypt
satisfies the IND-CPA property. In the definition of the IND-CPA property
the attacker is limited using an encryption oracle, but has no access to a
decryption oracle. As an engineer I find the IND-CPA definition useless
because it has no relation to the real world. In real life there is almost
always a party that performs the decryption, and we must assume that the
attacker has access to a decryption oracle of some form. (In many systems
the recipient will respond with a recognisable error code when the
decrypted message makes no sense. The attacker can use this to gather
information: send a bogus ciphertext to the receiver and check for the
error code.)

The 'attack' on authenticate-then-encrypt uses an encryption scheme that is
not secure when the attacker has a decryption oracle of the type mentioned
above. The paper explicitly mentions that even without any authentication,
the encryption scheme is not secure when used to encrypt messages. The
authenticate-then-encrypt scheme proposed is insecure because the
encryption scheme is insecure. This has _nothing_ to do with the
authenticate-then-encrypt construction. The encryption scheme is weak. The
fact that the encryption scheme is IND-CPA is a criticism of the IND-CPA
definition, not an indication of a problem with the
authenticate-then-encrypt construction.

If we want to we can also define an authentication scheme and an encryption
scheme under which authenticate-then-encrypt is secure but
encrypt-then-authenticate is weak. I don't think this tells us anything
about the relative merit of authenticate-then-encrypt and
encrypt-then-authenticate.

Cheers!

Niels

==============================================================
Niels Ferguson, [email-masked], phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]