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

Vincent Roca <> Thu, 03 September 2015 09:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 26DB91B2E7B; Thu, 3 Sep 2015 02:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.56
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gm_uitGloYow; Thu, 3 Sep 2015 02:42:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (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 ([]) by 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 <>
In-Reply-To: <>
Date: Thu, 3 Sep 2015 11:42:42 +0200
Message-Id: <>
References: <> <>
To: Adam Langley <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: IESG <>,,
Subject: Re: [secdir] Secdir review of draft-ietf-tls-padding-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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
> (, 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.