Re: [secdir] Secdir review of draft-ietf-tls-padding-02

Vincent Roca <vincent.roca@inria.fr> Thu, 03 September 2015 09:42 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB91B2E7B; Thu, 3 Sep 2015 02:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Gm_uitGloYow; Thu, 3 Sep 2015 02:42:46 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325301B2A7C; Thu, 3 Sep 2015 02:42:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.17,461,1437429600"; d="asc'?scan'208";a="144607388"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2015 11:42:44 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CFE0695F-ACD9-442A-80A5-7356A4941070"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <CAL9PXLyYLjBVW6Kuv8r_T1e=zaVa0LUihmba8O=jvN7bFK8ALw@mail.gmail.com>
Date: Thu, 03 Sep 2015 11:42:42 +0200
Message-Id: <6F5CD972-6AC1-490B-ABF7-AC14E7EE422F@inria.fr>
References: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr> <CAL9PXLyYLjBVW6Kuv8r_T1e=zaVa0LUihmba8O=jvN7bFK8ALw@mail.gmail.com>
To: Adam Langley <agl@google.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/CVMzVrh-2-qD6BR_2c-gInEd--s>
Cc: IESG <iesg@ietf.org>, draft-ietf-tls-padding@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-tls-padding-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 09:42:49 -0000

Hello Adam,

> On Mon, Aug 31, 2015 at 9:16 AM, Vincent Roca <vincent.roca@inria.fr> wrote:
>> That’s perhaps a naive question, but let me ask it. Shouldn’t a receiver
>> check
>> that the actual length of the extension_data field is in line with the value
>> of the
>> extension_data length field. Since those zero bytes are actually carried
>> over
>> the net and present in the reception buffer, there could be several ways to
>> calculate this length… (I really don’t know if it’s the case or not)
> 
> I don't think that we want to pin down the exact length of the padding
> and would rather leave it up to the sender. Although, for now, we have
> only a single use case for this, some other uses have been
> suggested(*) and it would be nice just to have a single padding
> extension if we decide that we need them in the future.
> 
> (*) for example, padding a DTLS ClientHello to reduce the
> amplification factor of DTLS.

There is a misunderstanding here. Let me reformulate.
What happens if the sender specifies an extension_data length value
that differs (i.e., the value is either smaller or larger) from the actual
padding extension in the packet sent? Well, it depends how it’s
implemented at a receiver… My point was to suggest the receiver to
check this extension_data length value carefully before processing it.
Perhaps this comment is too paranoid? Perhaps the way it works avoids
problems? In that case just ignore it.


>> Additionally, section 3 says:
>> 
>>   The client MUST fill the padding extension completely with zero
>>   bytes, although the padding extension may be empty.
>> 
>> I think that you mean « padding extension_data field » and not « padding
>> extension »:
> 
> Done, thanks.
> 
>> And finally, in the example (figure), instead of:
>> 
>> 16-bit, extension_data length
>> 
>> I’d rather add a « _ » as in:
>> 
>> 16-bit, extension_data_length
> 
> Although I don't have strong feelings either way, I didn't make this
> change. In the TLS 1.2 RFC
> (https://tools.ietf.org/html/rfc5246#section-7.4.1.4), extension_data
> is a named field, but extension_data_length is not. Rather it's an
> implicit part of extension_data. Since this draft isn't defining
> anything new about extensions in general, I feel that it shouldn't
> name new things here.

I understand, no problem.

Cheers,

  Vincent