Re: [TLS] padding bug

Adam Langley <agl@google.com> Mon, 09 September 2013 14:51 UTC

Return-Path: <agl@google.com>
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 DBD7021E81F0 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 UG1otHaZtCq2 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:51:26 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2F21F9EE5 for <tls@ietf.org>; Mon, 9 Sep 2013 07:43:06 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id uz19so5915859obc.21 for <tls@ietf.org>; Mon, 09 Sep 2013 07:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ycdnbbDiBennDhCV0bjNTn4+tHLLn7h9QzEuKZiNn4I=; b=SscmBZWz6MiLQNJpWOvVjveWd98f3zZEi8lY4J6OAD7T1ZePwHdx4vrF0f1VymESTy yrxf2EaXYm6O+hiRfldoXYUHaVowbKvnQL+DSAJxmoWYmMNOi/x72OuO22JUfjz3zXxo XeShaeG7mtyA953ZZQ9bZ1BuxuBo+IID+j8u4IxLsNuRkoqoXU4JM/Z6yiyxOW06lvYa lqFLH1XJJZezWLtslloUfdk/CoybRZuFXYzaD2E5QITreN0kv6sgu/oj3b1kEOKrbzem jXbgRUcUFIANjtdAmoDyLzf3WmYQ11+AgRQCTCF3K56DvwTtjLArm3PqsUPeTjpqg57o AhBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ycdnbbDiBennDhCV0bjNTn4+tHLLn7h9QzEuKZiNn4I=; b=Y4jmevr5BA2RHvl9D3lVSDbgFEk4IRnPedLfVPpcf2gFJ6CDwATZldiC6d6J4osvx9 XfFNiZqidoW/6Vw1ShR5EDu87ZmdbMRClF3lLGY9YanBvJXhbp7HIey0FS9e6mKAaDOm quwshhNXTsEBKHniau+LXCOe8Gyx3PJzASm9dnYq9eGURVZ54G5TY6aex4oWTSHMzZw3 305Hxbrdph1ZchNhxKqQLG68FldlYEm2jfgtbISjzy4GR2ZpTQxe+HIjl2JP6b8nbg8o wkuzbXoUJSavc+oLO6u8Cl6apISW1ZsB7ZISIccdoZQxs+mxIKie5maAZURmiXKSxSz0 GhrQ==
X-Gm-Message-State: ALoCoQnr6X6mXqliictwhFRmbb7lJ+WInSynSh6aJ+J49eRCVxKjhs58GL1JrgcfcCes+CqxFsZNm2Tzj9uP9KudN115y6vn82gTZ1SsUejlMRRG/OfdHzEnXl1C/kDzkem3yxDUVoL0NuQlx8R+ZhWj/ubgAR/qJqUYGBPMSQCOsU8KmLeveep8RiCqeonItUa55F0c32gD
X-Received: by 10.60.133.233 with SMTP id pf9mr1395598oeb.46.1378737786524; Mon, 09 Sep 2013 07:43:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.111.66 with HTTP; Mon, 9 Sep 2013 07:42:46 -0700 (PDT)
In-Reply-To: <CABrd9SSHzfFH03euDh1yP2AOxa7vQP2ds5EFyPrP-=BqJ7BOMA@mail.gmail.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>
From: Adam Langley <agl@google.com>
Date: Mon, 9 Sep 2013 10:42:46 -0400
Message-ID: <CAL9PXLwXNVusi6n_QwDmLpFL+AtVE41LL0bCOU28BSKWnEMayA@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: text/plain; charset=UTF-8
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:51:34 -0000

On Mon, Sep 9, 2013 at 9:31 AM, Ben Laurie <benl@google.com> wrote:
> 1. Nothing in this I-D prevents the adoption of other approaches.
>
> 2. If fixes the problem for all versions of TLS and SSLv3.

The cost of making any change to TLS is mostly equal to any other,
since the bulk of the cost is in deployment. Using an extension to
negotiate encrypt-then-MAC is a simple change, but it still leaves us
with CBC mode. On the other hand, AES-GCM left the station some years
ago and has a clear head start.

AES-GCM does, currently, depend on TLS 1.2, which is proving to be a
pain to deploy on the public Internet as a client, but we'll get there
soon.

I don't believe that this change solves the problem for SSLv3 as SSLv3
doesn't have extensions and so cannot negotiate it. Once AES-GCM is
running I'm hoping to simply define those ciphersuites all the way
down the versions in order to solve version downgrade issues.

Having an alternative to AES-GCM is certainly valuable, but I don't
want it to be AES-CBC. I think the prior discussion around
Salsa20/Chacha20 and a polynomial MAC is the most promising direction
for that.

I've no objection to this ID, but nor am I esp excited by it.


Cheers

AGL