Re: [TLS] padding bug

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 09 September 2013 14:17 UTC

Return-Path: <yaronf.ietf@gmail.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 D399F11E81B2 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Tj2puf7DTJ3p for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:16:58 -0700 (PDT)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C719821F9AC1 for <tls@ietf.org>; Mon, 9 Sep 2013 07:10:56 -0700 (PDT)
Received: by mail-bk0-f46.google.com with SMTP id 6so2304444bkj.19 for <tls@ietf.org>; Mon, 09 Sep 2013 07:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kVpGsS4R8rqIrzftBblEZpxZ1tAIigktvuFxMxyKKVk=; b=uvMx0oM8EB9tWEy+YplI8idagYeyYW0wuI2gFqdKsHBe+cSdRE3qQLfNkg81utaGO5 nZYD8FOQakbpcl5tx1GnG5gwkTW5cH2VJ3kbfBuMI3gMEYk8CKggkkwsxaLEW41OC01O HK6QkZ4XUGiz9bEpNwj8wmVtrKfr51ntEgy/nsJtQSgmEdiuXf1caqsynKXn6Kmajw8J 7+EfzQtHqPuyHQLumUFncZEj9xfkfk2wFoSlOFMPVzAfqlDqBVRqxdP1VfCx9SUOzCer iIpiK4wSAMQveehIep7it0fmibognGdn5i0E7IrKzX+ZFMx18g6EFBLf9SGU+zTeBMYq vBgw==
X-Received: by 10.204.76.203 with SMTP id d11mr14750358bkk.3.1378735855901; Mon, 09 Sep 2013 07:10:55 -0700 (PDT)
Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id 14sm3249045bkl.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 07:10:55 -0700 (PDT)
Message-ID: <522DD6ED.7000000@gmail.com>
Date: Mon, 09 Sep 2013 17:10:53 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.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>
In-Reply-To: <CABcZeBPcvB2i2Xo7ceiybgLUw8KgJz=aJaNWEfTekFY1RdYC7w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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:17:07 -0000

Hi Eric,

I don't see draft-sheffer-tls-bcp as competing with this approach. I see 
the BCP as an interim solution that allows users to improves their 
security posture today, while the WG works on TLS 1.3 and/or on 
extensions that enable us to go back to a wide selection of available 
ciphersuites.

Thanks,
	Yaron

On 09/09/2013 04:01 PM, Eric Rescorla wrote:
> 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
> <mailto:benl@google.com>> wrote:
>
>
>
>
>     On 8 September 2013 14:47, Dr Stephen Henson
>     <lists@drh-consultancy.co.uk <mailto:lists@drh-consultancy.co.uk>>
>     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 <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>