Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10

Paul Hoffman <> Sun, 27 June 2010 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 160373A6980; Sun, 27 Jun 2010 14:44:53 -0700 (PDT)
X-Quarantine-ID: <T-pE8cmRgpe0>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Magnus Nystr\366m <magnusn@gmai[...]
X-Spam-Flag: NO
X-Spam-Score: 0.742
X-Spam-Status: No, score=0.742 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T-pE8cmRgpe0; Sun, 27 Jun 2010 14:44:52 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id 2EE513A6954; Sun, 27 Jun 2010 14:44:52 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id o5RLiwLq030804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jun 2010 14:45:00 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240826c84d76ae19d7@[]>
In-Reply-To: <>
References: <> <>
Date: Sun, 27 Jun 2010 14:44:57 -0700
To: Magnus Nystr�m <>,,,
From: Paul Hoffman <>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Jun 2010 21:44:53 -0000

Given that I have made this same copy-and-paste error in the past: this review is for draft-c1222-transport-over-ip, not the one in the Subject: line.

At 10:31 AM -0700 6/27/10, Magnus Nyström wrote:
>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 a framework for transporting ANSI C12.22
>advanced metering infrastructure (AMI) messages on IP networks.
>AMI is intended for interaction with various types of utility meters;
>as such, it is clear that security services such as data authenticity,
>integrity and confidentiality will be quite important.  This draft
>defers to ANSI C12.22 for application-layer security and states that
>any transport (or IP) network layer security security functionality
>shall act "only to enhance and preserve [and] ... not be a substitute
>for ... ANSI C12.22 ... security provisions." This is all good but I
>have not had access to C12.22 for this review and so cannot comment
>further on it. It seems to me, however, that the layering of C12.22
>on top of IP networks may warrant a discussion about potential methods
>to enhance C12.22 security? For example, could privacy be enhanced
>beyond what C12.22 offers through use of a transport network's
>confidentiality services?
>Other than this I have no particular comments on this draft; it reads
>good to me.
>-- Magnus
>secdir mailing list