IETF Logo Mail Archive

Re: [TLS] padding bug

Eric Rescorla <ekr@rtfm.com> Fri, 20 September 2013 15:53 UTC

Return-Path: <ekr@rtfm.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 7C7A321F9AE2 for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 08:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Y7+Cn13cmuGO for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 08:53:34 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 303EA21F9AFE for <tls@ietf.org>; Fri, 20 Sep 2013 08:53:31 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id j7so553501qaq.2 for <tls@ietf.org>; Fri, 20 Sep 2013 08:53:30 -0700 (PDT)
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=nYlieQuvtMKrFXsaCS+vLclQAoL99XvNXq525FIGgiE=; b=AaGUnV4YhWdH5ElpsPhVWUMte800pg7OAVD14A49WUBicV+8BK9KCFkpvKPyiR8Ctg Bv5m7vR/R+Cul66wC0Aa+nteJXyY7DAMkHtKk03sRJMmTHriIMjoFLHjPFz0jptuzA/f +COvYqCZqWVQARFQ0ZVvGEH8nnPDAWuebHYGZ22OtQZ27QDCBjybhtEMnURHBQ62Accf khrLeejF0bcF3O5c/Y5MXGkcBHdVjbORcejZ4Ux4Wn8hAnaoSNdPZEMfNFIypLBTpFmr v6bfPBVLtT72S1P+9jo1ymq4wmXwvI6tRya/kwIvJnHYrikKPxD+NbyPSvGl9ek28f56 j3Bw==
X-Gm-Message-State: ALoCoQmayFab9YSwHuAJ4XS+PXJ4oO9OKQ2x8/1aOt1kapiadOq+Pgdj5C+fbeYR7iPYMkaeUMhU
X-Received: by 10.49.3.194 with SMTP id e2mr11711741qee.21.1379692410605; Fri, 20 Sep 2013 08:53:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Fri, 20 Sep 2013 08:52:50 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 20 Sep 2013 08:52:50 -0700
Message-ID: <CABcZeBPTiLM6-6OL8ASo6NJvGkYxc0Mn9CM51e1x0j2Em4tvig@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="047d7bb0473408a2d104e6d2ac3e"
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: Fri, 20 Sep 2013 15:53:53 -0000

On Fri, Sep 20, 2013 at 6:29 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>wrote:

> Eric Rescorla <ekr@rtfm.com> writes:
>
> >Of course, this naturally raises the question of whether this document
> will
> >be accepted by the TLS WG.
>
> It seems to be accepted by everyone except the WG chairs, who point to:
>
> >However, as I think recent discussion indicates, there are a number of
> >proposed approaches and there isn't really consensus to adopt this
> particular
> >one
>
> Can you provide concrete examples of this lack of consensus?


These messages from Nikos look negative to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09809.html
http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

This looks like "meh" to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

Privately, I've also heard objections to attempting to prolong the
life of CBC as a primitive. Perhaps those who expressed this
would speak up on the list?


 It's already
> present in deployed implementations (as I mentioned a while back, the
> response
> of one SSL library developer was "this should have been done ten years
> ago").
> So lets reverse this, if the WG chairs think that there are viable
> alternative
> approaches could they please point to *currently active RFC drafts* (not an
> expired six-month-old text but a current draft) with authors willing to
> actively champion their approaches on the list?
>

We have drafts for AEAD w/ CBC:
http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01

And I have heard a variety of suggestions for pushing AEAD down into
TLS 1.2 (there's no technical problem here). If we were to do that, the
draft would presumably be trivial and then we could simply directly
adopt the McGrew draft.

If we were to abandon CBC entirely we would mostly want some
new stream ciphers. E.g.,

http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02

So, certainly if we wanted to to adopt a "triage and selectively replace"
strategy, we have the drafts to do it. In addition, we do have a

Pad then encrypt then MAC draft that is recent.
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01

That is not to say that the WG could not also adopt your draft, but as I
said
above, it's not the only alternative.

We think this would benefit from F2F discussion and I would invite you or
someone else in favor of this draft (or another approach) to present in
November in Vancouver. If there is WG consensus for this, we can adopt
it then.

Best,
-Ekr

P.S. I am about to go mostly offline through Monday night. Apologies in
advance for slow/non-response.

v2.23.0 | Report a Bug | By Email