Re: [tcpm] Comments on TCP-AO Draft

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <> Mon, 17 November 2008 20:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 1EDF33A6A3C; Mon, 17 Nov 2008 12:06:14 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DEC83A68F6 for <>; Mon, 17 Nov 2008 12:06:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZKSIarspnsPH for <>; Mon, 17 Nov 2008 12:06:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8934F3A6939 for <>; Mon, 17 Nov 2008 12:06:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D08BC7AB0D; Mon, 17 Nov 2008 14:06:09 -0600 (CST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id mAHK66G9004372; Mon, 17 Nov 2008 14:06:10 -0600
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 14:06:06 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 17 Nov 2008 14:06:10 -0600
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] Comments on TCP-AO Draft
Thread-Index: AclI5XgHf+wZoobzTouVULb4S/pTOQACBnxQ
References: <>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
To: LANGE Andrew <>,
X-OriginalArrivalTime: 17 Nov 2008 20:06:06.0573 (UTC) FILETIME=[ECE739D0:01C948EF]
Subject: Re: [tcpm] Comments on TCP-AO Draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [] On 
>Behalf Of LANGE Andrew
>Sent: Monday, November 17, 2008 1:51 PM
>Subject: [tcpm] Comments on TCP-AO Draft

There are a lot of good comments here that will strengthen
the document.  One of them that concerns the wire-format rather
than text additions, clarifications, and changes that are
needed, which we should address quickly is:

>1.4.1: " IETF-72 topic" sections "No current consensus was 
>reached on this topic, so no change was made."  This is a real 
>problem -- the logic is deeply flawed.  Allow me to restate: 
>One author of this document has appointed themselves the 
>arbiter of consensus.  This author disagrees with other 
>people, and therefore no "consensus" can ever be reached, so 
>the default case this author has chosen is to keep things they 
>way they like it.
> ...
>"..omit an explicit algorithm ID..." -- I've said this before, 
>this is a BAD IDEA^tm. The protocol utility of doing this is 
>minimal (1-bit increase in search space), and the operational 
>complexity goes up.  Not to mention, it makes it operationally 
>incompatible with existing implementations.

There was logic given to support each side of the argument.  My
understanding of the summary for each position is:

(position 1 - "include") Including information like algorithm ID
and k-bit is BAD because it aids in debugging of implementations
and of configurations.

(position 2 - "don't include") Including this information is BAD
because it can expose information about the security parameters.
It doesn't aid in debugging of configuration because operators still
have to call each other in order to read off and verify keys.

There seemed to be more people around position 2 than position 1,
but we should flag this and ask during the meeting, as well as
open this up on the mailing list to see what people prefer.  We
need to pick one and move on.

As an individual, and not a co-chair, I'm in the position 2 "don't
include" camp.

tcpm mailing list