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

Vincent Roca <vincent.roca@inria.fr> Mon, 31 August 2015 16:16 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 D05B41B5612; Mon, 31 Aug 2015 09:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.159
X-Spam-Level:
X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 X2zS03kuRXOv; Mon, 31 Aug 2015 09:16:45 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B3D1B560C; Mon, 31 Aug 2015 09:16:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.17,442,1437429600"; d="asc'?scan'208,217";a="175483752"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2015 18:16:42 +0200
From: Vincent Roca <vincent.roca@inria.fr>
X-Pgp-Agent: GPGMail 2.5
Content-Type: multipart/signed; boundary="Apple-Mail=_1F2C43E4-6328-4108-A244-97C1FCEB562C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Date: Mon, 31 Aug 2015 18:16:41 +0200
Message-Id: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-tls-padding@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/CzO86h-4LdrHQCuL7CMjlxQJz4o>
Subject: [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: Mon, 31 Aug 2015 16:16:48 -0000

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.


IMHO, the document is almost ready. However I have a question plus a
non-security related comment.

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)


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 »:
   The client MUST fill the padding extension_data field completely with zero
   bytes, although the padding extension_data field may be empty.

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

Cheers,


  Vincent