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
- [secdir] Secdir review of draft-ietf-tls-padding-… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-tls-padd… Adam Langley
- Re: [secdir] Secdir review of draft-ietf-tls-padd… Vincent Roca