Re: [TLS] padding bug

Eric Rescorla <ekr@rtfm.com> Mon, 09 September 2013 13:05 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 43EE521E8192 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 06:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 SSHMzC3swkT4 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 06:04:56 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8816821E81BB for <tls@ietf.org>; Mon, 9 Sep 2013 06:01:43 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id ii20so135797qab.13 for <tls@ietf.org>; Mon, 09 Sep 2013 06:01:42 -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=MwDW+ROmCDPajDOMjLIu+jTGI3r2GsPnhAA4CjGR69M=; b=JIh6OAC3m0ntC2hRqSOxdGozlIJeRya/JxLBdu7Glyfl1/7UMJ85pSOL6mC9d2PO1l InMEAywCQ1o7DLXGOkaUU5IVVWgHVYnPK3E6MnQ8kUQcJREw5QgJ4QxWaLfiWLdJwlCl Dbkx9aopT46KQmJHXZEwVAv4QtuCCG5+Ru7KZm1rMX81wce86xwyJ6867gP0/RogiAZ9 HNVvTWVvVZMNq0jX3imYbG2U7QEeyCS3oX0wuKTGYXy28weyZuygUjcw1HpW0OL9XkQE enbvufNoIMFqhKbaVTbA0nZ/Sw8551dFFb89J0Ojpk6tMgT8z8CKXrSCY39m5FQP3Ya2 +zug==
X-Gm-Message-State: ALoCoQmT8jCAX2h0rfggLcTdl8c5+3R3qEgTgUvSL1vYoV25k2HaLzLPQ+GxV7GzJ2m4/uzNPrvt
X-Received: by 10.49.130.233 with SMTP id oh9mr24733677qeb.10.1378731702901; Mon, 09 Sep 2013 06:01:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Mon, 9 Sep 2013 06:01:02 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CABrd9SSbv1owOq9RK-OY2YqfUHavpebYCdKUVd6MGSff_MiiWg@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 9 Sep 2013 06:01:02 -0700
Message-ID: <CABcZeBPcvB2i2Xo7ceiybgLUw8KgJz=aJaNWEfTekFY1RdYC7w@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=047d7bb03fa664707104e5f2fda2
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 13:05:08 -0000

Ben,

Generally, we're not doing advance code point assignments for documents
that haven't been accepted by the TLS WG.

Of course, this naturally raises the question of whether this document will
be accepted by the TLS WG. 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 (especially in view of the increased adoption
of existing
mechanisms such as GCM). If someone (Peter? You?) wants agenda time
to argue for this particular approach instead of others, we're happy to
have the
discussion in YVR. This of course also applies to proponents of other
approaches.

Best,
-Ekr

[As Chair]



On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie <benl@google.com> wrote:

>
>
>
> On 8 September 2013 14:47, Dr Stephen Henson <lists@drh-consultancy.co.uk>wrote;wrote:
>
>> On 08/09/2013 13:07, Dr Stephen Henson wrote:
>> > On 08/09/2013 03:59, Peter Saint-Andre wrote:
>> >> [old thread alert!]
>> >>
>> >>
>> >>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>> >>
>> >>> Was any consensus achieved as to the best approach?
>> >>
>> >
>> > I can add a data point to this. I spent an afternoon implementing this
>> (i.e.
>> > the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy
>> to do
>> > and interoped fine with the test servers.
>> >
>> > I'll make it available as an experimental feature in OpenSSL master
>> branch.
>> >
>>
>> Well I've added this and spotted a problem. The draft extension value
>> (0x10)
>> clashes with the draft value used in the ALPN specification.
>>
>
> Given that the ALPN draft apparently has an allocated number, can we get
> one allocated to this I-D?
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>