Re: [TLS] Next steps for draft-agl-tls-padding

Andrey Jivsov <crypto@brainhub.org> Mon, 07 April 2014 00:22 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDB81A0584 for <tls@ietfa.amsl.com>; Sun, 6 Apr 2014 17:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE1V3pfbZoYi for <tls@ietfa.amsl.com>; Sun, 6 Apr 2014 17:22:03 -0700 (PDT)
Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7261A00EC for <tls@ietf.org>; Sun, 6 Apr 2014 17:22:02 -0700 (PDT)
Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta08.emeryville.ca.mail.comcast.net with comcast id mo5D1n00316AWCUA8oMxvw; Mon, 07 Apr 2014 00:21:57 +0000
Received: from [192.168.1.8] ([71.202.164.227]) by omta06.emeryville.ca.mail.comcast.net with comcast id moMw1n00N4uhcbK8SoMwLY; Mon, 07 Apr 2014 00:21:57 +0000
Message-ID: <5341EFA4.7070808@brainhub.org>
Date: Sun, 06 Apr 2014 17:21:56 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <cf049a7104934cc7a4bddced33cd00a2@BL2PR03MB419.namprd03.prod.outlook.com> <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <CAL9PXLzawuetexEvU5PECUwuuiLvq5T0bxnhiky3cevQpetjNQ@mail.gmail.com> <CABcZeBNMAB40p+zxTGh354MCtEu+TbikS4w=C0SDyHNCdu=djw@mail.gmail.com> <CAK6vND_4umziyfG=XWe37tUmv=ahVP08jFX+YrgaSG+_THFWUA@mail.gmail.com>
In-Reply-To: <CAK6vND_4umziyfG=XWe37tUmv=ahVP08jFX+YrgaSG+_THFWUA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396830117; bh=btqmaKPrX4G4v9z1DDdSr8DewiRTX5SJTNUx7Z32/ts=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nl9H7ruHjnYWqWy8tyLe6c4x2qsNlpsp5BDaOXhfPaB335ktH47YIKaQqa/3gQOZY mvuuRY1UgaBd1E2JPQ/AEnFP1LBHo/vN+PGx9F1bOVcBUmBsr8Se2FfhXDtkhFAhPd Mw7KxaeVG6PHR9oJ37I8RYJg7KCEq6Es3nINSbVNatbSPOeLDc/ia1O0KE034CaWcn ZqhZxbisYrChASMyh1P0lE9Zp7inltti/MinrNxSHKE0stR09Y5U1YjOldG5NNxNEQ CDrSAv6EccMqs0kvJ9vxZSNtZoRJA38/wx63WeviCsz6SQN2McJGZUMD6hzHGfYrPD zxdZlMemewxcg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kC1iFf2lnvWmPFESqPYLyqOnNI4
Subject: Re: [TLS] Next steps for draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Apr 2014 00:22:08 -0000

>
> 1. Introduction
>
>
>    Successive TLS [RFC5246] versions have added support for more cipher
>    suites and, over time, more TLS extensions have been defined.  This
>    has caused the size of the TLS ClientHello to grow and the additional
>    size has caused some implementation bugs to come to light.  At least
>    one of these implementation bugs can be ameliorated by making the
>    ClientHello even larger.

( Sorry if it was already discussed )

I suggest to explain why the last sentience in the above paragraph holds 
true. The paragraph leads the reader to the idea that "larger 
ClientHello --> bugs", but then there is a shift that "even larger 
ClientHello --> fewer bugs".

The spec would benefit from a suggestion about what the recommended use 
of the padding extension is (i.e. to which size one should pad).

Thank you.