Re: [TLS] padding bug

Dr Stephen Henson <lists@drh-consultancy.co.uk> Mon, 09 September 2013 14:58 UTC

Return-Path: <lists@drh-consultancy.co.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4311E8232 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moAj0t7grJgM for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:58:07 -0700 (PDT)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A521F999D for <tls@ietf.org>; Mon, 9 Sep 2013 07:49:59 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:40062 helo=[192.168.7.9]) by relay02.mail.eu.clara.net (relay.clara.net [213.253.3.42]:10465) with esmtpa (authdaemon_plain:drh) id 1VJ2mb-0007EC-7i (return-path <lists@drh-consultancy.co.uk>); Mon, 09 Sep 2013 14:49:41 +0000
Message-ID: <522DE004.6060204@drh-consultancy.co.uk>
Date: Mon, 09 Sep 2013 15:49:40 +0100
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <AAE0766F5AF36B46BAB7E0EFB927320630E4A54175@GBTWK10E001.Technology.local> <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> <CABrd9SSbv1owOq9RK-OY2YqfUHavpebYCdKUVd6MGSff_MiiWg@mail.gmail.com> <CABcZeBPcvB2i2Xo7ceiybgLUw8KgJz=aJaNWEfTekFY1RdYC7w@mail.gmail.com> <CABrd9SSHzfFH03euDh1yP2AOxa7vQP2ds5EFyPrP-=BqJ7BOMA@mail.gmail.com>
In-Reply-To: <CABrd9SSHzfFH03euDh1yP2AOxa7vQP2ds5EFyPrP-=BqJ7BOMA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2013 14:58:19 -0000

On 09/09/2013 14:31, Ben Laurie wrote:
> 
> 2. If fixes the problem for all versions of TLS and SSLv3.
> 

That to me is a very strong point in its favour. There have been weaknesses
affecting just about every ciphersuite with the exception of GCM mode, which
needs TLS 1.2. I'd love it if everyone moved to TLS 1.2 in the near future but
realistically that isn't going to happen. All manner of interop headaches
arrived with broken implementations when TLS 1.2 support was added to OpenSSL
and we still get frequent reports. Even with TLS 1.2 I'm uneasy about there
being only one symmetric cipher mode left.

I can add a few additional points in favour of this draft.

The signalling approach taken is similar to the one adopted with the secure
renegotiation (RFC5746), with the exception that extension intolerant servers
will choke. If we really care about those another signalling ciphersuite could
always be added.

I particularly liked the ease with which this could be implemented in OpenSSL
(Peter had similar experiences with Cryptlib). It took me just a few hours and
would've been less if some unfamiliar code hadn't been added recently:
ironically to address the "Lucky 13" attack.

It required no new APIs and it should work seamlessly with existing
applications. That's very important for a library if you have a large existing
code base.

One negative point relates to cryptographic hardware or software optimisations
(where you have an efficient or atomic way to handle record decryption) but I
think this will apply to other solutions too. Anything that needs to address
"Lucky 13" may have already hit this anyway.

On the particular point of addressing "Lucky 13" that attack was a real headache
for FIPS 140 compliance. Reimplementing algorithms at a low level to be constant
time will typically require revalidation with considerable expense and delays. A
partial (but far from perfect) mitigation was chosen as a compromise. If this
draft was adopted that would not be a problem any more as the existing validated
algorithm implementations could be used.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.