[TLS] TLS CBC ciphersuites fix

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 14 April 2013 09:29 UTC

Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <516A76EE.1030501@gnutls.org>
Date: Sun, 14 Apr 2013 11:29:18 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [TLS] TLS CBC ciphersuites fix
Precedence: list

Hello,
 I don't know if the issues in CBC ciphersuites topic was discussed in
the previous WG meeting (couldn't find the minutes), and I don't know if
there is already a selected solution, but here is a summary of the 3
proposed (in the list) fixes to the CBC issue so far, as well as my
thoughts on each one (note that I co-authored II).

===================
I. http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01
Specifies ciphersuites using CBC to be used with the TLS 1.2
AEAD construction. It utilizes the encrypt-then-MAC construction.

* Pros:
1. Provides ciphersuites that can be used to replace the existing
existing CBC ciphersuites.

* Cons:
1. The new ciphersuites only work in implementations supporting TLS 1.2
2. It adds 5 new ciphersuites using AEAD and various HMAC-SHA variants.
Cannot be used to replace all known CBC ciphersuites.


II. http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00
Modifies all ciphersuites to use a new padding mechanism that does
not have the shortcomings of CBC padding. That is, padded data are
part of the plaintext.

* Pros:
1. Fixes the known issues in all the existing CBC ciphersuites.
2. May be used from SSL 3.0
3. May protect from key-recovery in a weak MAC construction
4. It adds the ability of variable padding to all TLS ciphersuites

* Cons:
1. May not protect from a MAC that has data-dependent timing
2. Modifies all TLS ciphersuites, even those not affected by the attack.


III. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-01
Negotiates an encrypt-then-MAC mode for all TLS ciphersuites.

* Pros:
1. Fixes the known issues in all the existing CBC ciphersuites.
2. May be used from SSL 3.0 (though the text mentions TLS 1.0 only)
3. May protect from a MAC that has data-dependent timing

* Cons:
1. Modifies all TLS ciphersuites (except the AEAD), even those not
affected by the attack.
2. May not protect from key-recovery in a weak MAC construction
===================

Please feel free to add an pros or cons I missed.

I find solution (I) inadequate to replace the CBC ciphersuites in any
practical scenarios. That is because that solution only works for TLS
1.2 implementations leaving all the older ones vulnerable.

What I like most in solution (II) is the variable padding to any TLS
ciphersuite which can be used as a traffic analysis countermeasure. The
other thing I like is that it fixes the issue at hand by doing minimal
changes by preserving the original construction used in TLS
(MAC-then-encrypt).

Solution (III) what I like most is that it fixes the issue at hand and
potentially any other timing issues that may arise from a MAC that has
data-dependencies. What I don't like is the radical change, i.e., a
switch to another encryption mode which leaves the MAC unencrypted.
Maybe it should be combined with a deprecation of HMAC-MD5, and possibly
a truncation of the MAC to deter key recovery (remember that the TLS
handshake MAC is already truncated to 96-bits exactly for that reason).

Any other thoughts on those issues? Is the WG actually adopting a fix to
that issue, or should implementors work it out outside the WG?

regards,
Nikos

[TLS] TLS CBC ciphersuites fix Nikos Mavrogiannopoulos
[TLS] Informal minutes from Orlando Paul Hoffman
Re: [TLS] Informal minutes from Orlando Russ Housley
Re: [TLS] Informal minutes from Orlando Paul Hoffman