Subject: Re: [ietf-tls] Re: an attack against SSH2 protocol

From: Bodo Moeller <[email-masked]>
Date: Wed, 13 Feb 2002 15:27:34 +0100

On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote:

[...]
> Thus, future revisions of TLS should also take this into account.
> That is, either transmit a fresh (unpredictable) IV with each msg,
> or implcitly compute this IV in an *unpredictable* way, for example by
> applying a  prf to the msg counter. 

What about using the MAC as a prefix instead of postfix to the
plaintext?  If the MAC is secure, it certainly will be unpredictable,
so the encrypted MAC (which is the effective IV for the actual data)
will be unpredictable as well.

>> Another problem with CBC as used in SSL/TLS was pointed out by Serge
>> Vaudenay, see <URL:http://www.openssl.org/~bodo/tls-cbc.txt>.  That
>> one can easily be avoided by implementations.  To avoid the new attack
>> without changing the protocol definition, implementations would have
>> to send an empty fragment before application data to ensure IV
>> randomization.

> This is a nice attack (do you know of a publicly available paper on this
> that I can cite?), and indeed easier to fix than the others.  

It's now a technical report:

     Serge Vaudenay
     CBC Padding: Security Flaws in SSL, IPSEC, WTLS, ...
     DSC Technical Report 200150, EPFL, 2001. 

     <URL:http://lasecwww.epfl.ch/query.msql?ref=Vau01>

> The analytical model in my paper (for the case of
> authenticate-then-encrypt with CBC) makes the assumption that decryption
> and mac verification are performed as an atomic operation with a single
> "ciphertext invalidity" bit learned by the attacker regardless of the
> reason for failure. This points out to yet another advantage of the
> encrypt-then-mac approach, namely, there you first check the MAC and if
> not valid you do NOT decrypt (in particular, you provide no info to the
> other side or the atacker about the result of decryption). No need for
> assumptions on the atomicity of combined operations.

I agree, this is a nice property.

> I wonder if any one cares in ssl/tls community about all these 
> basic crypto-security design issues;

I certainly do --

>                                      any plans for future protocol
> versions?

so I was going to ask this myself.

> PS: since Wei Dai mentioned the case of SSH in this context, the bad news
> there is that even using CBC and fixing the problem of predictable IV
> leaves the protocol open to the attacks on authenticate-and-mac
> showed in my paper (e.g. the attack in appendix C)

Previously I had only mentioned the CRYPTO 2001 version of the paper
(which does not have an Appendix C).  Here's a pointer to the full
paper:

     Hugo Krawczyk
     The order of encryption and authentication for protecting
       communications (Or: how secure is SSL?)
     Cryptology ePrint Archive: Report 2001/045

     <URL:http://eprint.iacr.org/2001/045/>

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: Wei Dai <[email-masked]>
Date: Thu, 14 Feb 2002 11:11:17 -0800

> applying a  prf to the msg counter. 

I'll note that using CTR mode is more efficient than either of these
suggestions. It doesn't require unpredictable IVs.

> showed in my paper (e.g. the attack in appendix C)

Good point. If we want to fix SSH by using a per-packet unpredictable IV,
the IV would have to be added to the list of MAC inputs. I think that
would prevent the attack in appendix C.

I'm not very familiar with how IETF working groups work, so what's the
next step here?

---

From: Stephen Sprunk <[email-masked]>
Date: Thu, 14 Feb 2002 16:08:39 -0600

> suggestions. It doesn't require unpredictable IVs.
...
> would prevent the attack in appendix C.

So is the correct approach to fix the CBC implementation, or to switch
to a mode that is less prone to misuse?

> I'm not very familiar with how IETF working groups work, so what's the

Someone writes an internet-draft (ie. RFC format) describing the
change.

S

-- 
Stephen Sprunk          "So long as they don't get violent, I want to
CCIE #3723         let everyone say what they wish, for I myself have
K5SSS        always said exactly what pleased me."  --Albert Einstein