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

Adam Langley <> Tue, 01 September 2015 17:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 993461B4CFD for <>; Tue, 1 Sep 2015 10:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CoYC-kN1akaw for <>; Tue, 1 Sep 2015 10:11:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BF3C1B55A9 for <>; Tue, 1 Sep 2015 10:11:32 -0700 (PDT)
Received: by vkhf67 with SMTP id f67so60986504vkh.1 for <>; Tue, 01 Sep 2015 10:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=f+Wp3yWwPvAGpaLsUJHbuyVPXQe+tv4jG/MQTyBFZ2s=; b=h1ikSj12yRwI6l3l6TqvHPRq/INxljgAJPRGGUlykUtFVV2/Z5Xj1RaSJX2EILIhPP XX5NyX6ND1HZtJ05fvjjN9rGzE2EKPfVCtKXmryj97NgRPfukvstbaijx9wDOXGCPNUG R3+Z5hnWz83kb8DyyoUgf+QWxupCLNDe4YF7hYlvkdLcV1PJcRMSmRCwujDTp3KzFXHH biOTdlsWhHuwj2zsubiX1u3S+Hz7kCqv8JOIxJmQodHkvWgwb95ki8AYbURaoYffxBiS DXFR4OY+dW7NFHyfLzmlxSgGaTiacktWqrxg8UMCKaOSUCRHjaVi+UGqCxgL8urrXcLJ cMDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=f+Wp3yWwPvAGpaLsUJHbuyVPXQe+tv4jG/MQTyBFZ2s=; b=gxapSs44oF0kkQRfLlcLtbJmdv4+R5zv7gaf3QCbJCi+h6/2QSABBy4O4YF9iyOPbp LdCpT8e0dDLkQrKKCr7qySt9S31xENoT7CaOdhfXdOIBXvOFapuTnq7fxXjR9W93lbGz ibpEJxQ39KY4WmkDa0VaS4GnWPblJ+EsXJK+dAPD4ysGAlam1AhcEHvGD2eGF8oSovbq /ytUMvWsqazymDCwDWhMCdBiY5K98aA6epZsNgFDB+AUQ6Q4hCzu4WHOC0J5frtB4YIv fKXz7zopXw+9H0ralX86hqFEbm23CJXZ3f5lp4moNXcYenDEJmZrHubG6cO3Q5FkdZm1 JcBQ==
X-Gm-Message-State: ALoCoQkYj9inOTBO++VIvw7JIuD0BnYuT2QS6+71UcxGd3p6bel5RRI5yG9+3DB43CAq2BhHRTtU
X-Received: by with SMTP id tr1mr32729815vdc.0.1441127491172; Tue, 01 Sep 2015 10:11:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Sep 2015 10:11:11 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Adam Langley <>
Date: Tue, 1 Sep 2015 10:11:11 -0700
Message-ID: <>
To: Vincent Roca <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700
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: Tue, 01 Sep 2015 17:11:35 -0000

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.

> 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.