Re: [tcpm] Comments on TCP-AO Draft

"Gregory M. Lebovitz" <> Tue, 18 November 2008 01:33 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 2FE7F3A6922; Mon, 17 Nov 2008 17:33:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDB9D3A6922 for <>; Mon, 17 Nov 2008 17:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bAqW4sgluXV4 for <>; Mon, 17 Nov 2008 17:33:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9B3323A67E1 for <>; Mon, 17 Nov 2008 17:33:51 -0800 (PST)
Received: by with SMTP id b25so2665629rvf.49 for <>; Mon, 17 Nov 2008 17:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :in-reply-to:references:mime-version:content-type:message-id; bh=G63zKzr/jUMwTNlgFM9qcBGiMa5+2/q7+xzILEffcmM=; b=vW7Ud7tMO62s07/ayXF8sU58zbnYNk8iH2qwSrZqSab4n0mAUjsRc3+pgh3KEWvJZg +FH5qTMgVFawgAV0Xjw8WVojlPP2tj0S0b5ZbMVa0PAf+fevY8n8Xkvo+ctgpxt87zsm Jnh48IT4C35VpU9YuFTy2Ai1NpSwFIC3jgZYQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=x-mailer:date:to:from:subject:in-reply-to:references:mime-version :content-type:message-id; b=MGT5lENvhmE4ZgV6asc94ZXkg6Sg0NKBmrdJMd6VLNgodO9H80zLGr9FEqXQvIT+LQ 33+FR1NrnKiRtoOVCobmkWCR6i1YjPq0QHNo4QE6sK0q3idzIl0zno0dE7hfE4RngFNG wn37LXU+SobZlo4ztn1juAWDvIdxzzuyWTeyU=
Received: by with SMTP id w11mr73635rve.280.1226972031121; Mon, 17 Nov 2008 17:33:51 -0800 (PST)
Received: from ([]) by with ESMTPS id l31sm11281033rvb.2.2008. (version=SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 17:33:49 -0800 (PST)
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 17 Nov 2008 17:33:43 -0800
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>, LANGE Andrew <>,
From: "Gregory M. Lebovitz" <>
In-Reply-To: <>
References: <> <> <>
Mime-Version: 1.0
Message-ID: <>
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: multipart/mixed; boundary="===============1995258273=="

inline again...

At 05:28 PM 11/17/2008, Gregory M. Lebovitz wrote:
>At 12:06 PM 11/17/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>> >-----Original Message-----
>> >From: [] On
>> >Behalf Of LANGE Andrew
>> >Sent: Monday, November 17, 2008 1:51 PM
>> >To:
>> >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.

BTW, in the reference above, in the newly posted
this comment regards section 1.3.1, not 1.4.1.
Hope it helps,

>>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.
>Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? 
>I'll assume yes.
>>(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.
>I concur with your recollection about the two positions above. I 
>also concur with your recollection that there was more people (not 
>100% consensus, but more) around Position 2 than 1. The argument I 
>made went something like this, and was based on lots of years of 
>debugging interop issues in both IKEv1/ESP and IKEv2/ESP:
>  - there is only the case where the connection will be discussed 
> out of band by system admins before a first connection is made. At 
> that point, there will be some agreement about config choices.
>  - if the connection doesn't work, you double check your config 
> matches your agreement of config choices.
>  - if the config matches the agreement, then you can try the other 
> algo, just in case you misheard that part.
>  - if it doesn't work, then you have to pick up the phone and call 
> the other guy to double check config parameters.
>  Conclusion: having the bits on the wire about the config elements 
> doesn't help practically, and contradicts the basic security 
> principle of hiding as much about the SA as possible.
>So I am also support Position 2.
>>As an individual, and not a co-chair, I'm in the position 2 "don't
>>include" camp.
>>tcpm mailing list
tcpm mailing list