[secdir] Resend: Secdir review of draft-altman-tls-channel-bindings-10

Magnus Nyström <magnusn@gmail.com> Wed, 05 May 2010 05:43 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503F33A6B0D for <secdir@core3.amsl.com>; Tue, 4 May 2010 22:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.302
X-Spam-Level:
X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smWz8RlkT+Dw for <secdir@core3.amsl.com>; Tue, 4 May 2010 22:43:17 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 3CD9D3A6B00 for <secdir@ietf.org>; Tue, 4 May 2010 22:43:16 -0700 (PDT)
Received: by yxe9 with SMTP id 9so1699044yxe.29 for <secdir@ietf.org>; Tue, 04 May 2010 22:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4IHlew6htsk8+A87E07rMtNBtpcLIgim93IaFPMdeL0=; b=VVnaG2UwxclKYjRSbHiEmt0EHOReeSIhSeKjvDUTH7/QjvIaudLcGXCUInOXH7FaPH s/z1iT9i737zQGZI+JyCjQkDzdYwhE7wiXEgnI3W222arfljjXjzLqpq1bGTqoiLhaMR /DkhCpqOZNBG9GtNCoGoqwjzoOJitH/GWFPSA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dyCnBwTgAgNmfC7k/B/S2vDK61FF8ATBEfzQWwQJDuC7JDfhceScJNJ1xJOlg0Z7ao ST2pQXD7bZRgRGBZN0lKUDOvrFuOOGKhq4nydCbfY/eSk4ZqGyoo8XyEe/Kw+Zf8X1pG pcDPsEcBjADLsFIJLbC2pBPKfp6G+uEX6E+4s=
MIME-Version: 1.0
Received: by 10.100.84.11 with SMTP id h11mr4598515anb.31.1273038179272; Tue, 04 May 2010 22:42:59 -0700 (PDT)
Received: by 10.100.124.16 with HTTP; Tue, 4 May 2010 22:42:59 -0700 (PDT)
Date: Tue, 4 May 2010 22:42:59 -0700
Message-ID: <o2s2f57b9e61005042242z7d66897dx7c4447645e4b4b23@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: draft-altman-tls-channel-bindings@tools.ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary=0016368e1eb2760b990485d24c70
Subject: [secdir] Resend: Secdir review of draft-altman-tls-channel-bindings-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 05 May 2010 05:43:18 -0000

Resend since I used the wrong email address for tools.ietf.org.

---------- Forwarded message ----------
From: Magnus Nyström <magnusn@gmail.com>
Date: Tue, May 4, 2010 at 10:23 PM
Subject: Secdir review of draft-altmann-tls-channel-bindings-10
To: secdir@ietf.org, iesg@ietf.org,
draft-altmann-tls-channel-bindings@tools.ietf.org


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.

This document defines channel binding types for Transport Layer Security
(TLS), in accordance with RFC 5056.

The review is a follow-up of the review I made back in October 2007. Since
then, the unfortunate situation with a delta between an early implementation
of the "tls-unique" channel binding and the description in the IANA
registration was discovered and this prompted several updates to the draft.

As far as I can tell, the current draft solves the issue by adopting the
early implementation. It also contains several prominent warnings to
implementers about the situation.

Two of my comments from my review of -07 still stands:

1. Section 2 should reference RFC 5056, not RFC 5246. This is a bug.
2. It would have been nice with an example of an authentication mechanism
using one of the channel bindings in this document, perhaps in the form of
an illustrative appendix.

-- Magnus




-- 
-- Magnus