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

Adam Langley <agl@google.com> Tue, 01 September 2015 17:11 UTC

Return-Path: <agl@google.com>
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 993461B4CFD for <secdir@ietfa.amsl.com>; Tue, 1 Sep 2015 10:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoYC-kN1akaw for <secdir@ietfa.amsl.com>; Tue, 1 Sep 2015 10:11:34 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF3C1B55A9 for <secdir@ietf.org>; Tue, 1 Sep 2015 10:11:32 -0700 (PDT)
Received: by vkhf67 with SMTP id f67so60986504vkh.1 for <secdir@ietf.org>; Tue, 01 Sep 2015 10:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.52.232.225 with SMTP id tr1mr32729815vdc.0.1441127491172; Tue, 01 Sep 2015 10:11:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.193.8 with HTTP; Tue, 1 Sep 2015 10:11:11 -0700 (PDT)
In-Reply-To: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr>
References: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr>
From: Adam Langley <agl@google.com>
Date: Tue, 1 Sep 2015 10:11:11 -0700
Message-ID: <CAL9PXLyYLjBVW6Kuv8r_T1e=zaVa0LUihmba8O=jvN7bFK8ALw@mail.gmail.com>
To: Vincent Roca <vincent.roca@inria.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Fv4ro_CwMThEenG9DpCCqp5CiQY>
X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700
Cc: draft-ietf-tls-padding@tools.ietf.org, IESG <iesg@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: Tue, 01 Sep 2015 17:11:35 -0000

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.

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


Cheers

AGL