Re: [tcpm] TCP-AO review comments.

Caitlin Bestler <> Wed, 06 August 2008 14:00 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 7022D28C385; Wed, 6 Aug 2008 07:00:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C3E428C383 for <>; Wed, 6 Aug 2008 07:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uOCzSrNoAHnE for <>; Wed, 6 Aug 2008 07:00:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1667928C384 for <>; Wed, 6 Aug 2008 07:00:02 -0700 (PDT)
Received: (qmail 13870 invoked from network); 6 Aug 2008 13:58:36 -0000
Received: from ([]) (envelope-sender <>) by (qmail-ldap-1.03) with SMTP for <>; 6 Aug 2008 13:58:36 -0000
Message-ID: <>
Date: Wed, 06 Aug 2008 06:58:36 -0700
From: Caitlin Bestler <>
User-Agent: Thunderbird (Macintosh/20080707)
MIME-Version: 1.0
To: Lars Eggert <>
References: <> <> <>
In-Reply-To: <>
Cc:, "Anantha Ramaiah (ananth)" <>, ext Joe Touch <>
Subject: Re: [tcpm] TCP-AO review comments.
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Lars Eggert wrote:
> On 2008-8-2, at 2:16, ext Joe Touch wrote:
>> |    I have problem with the term "obsoletes 2385" [ I did bring this up
>> | before] It is going to be a long time before deployments move over to
>> | the new TCP auth option.
>> Practically, "obsoletes" doesn't obsolete anything. It does indicate
>> that the IETF wants a protocol to be replaced by something else. That
>> doesn't mean the older one can't be used for legacy support, e.g.,
>> AFAICT - and that clearly should apply here. If the IESG thinks that
>> this is consistent with "Obsoltes", would that be OK?
> We need to distinguish between one RFC obsoleting another RFC, and 
> moving an RFC to "historic". Unfortunately, neither is very clearly 
> defined.
> Here's my current thinking: Obsoleting is typically used when one RFC is 
> a drop-in replacement for another RFC. For example, bug-fix revisions of 
> an RFC typically obsolete the previous RFC, as do minor 
> backwards-compatible implementations. That isn't quite the case for AO 
> and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple 
> revision or extension of TCP-MD5, it's a new mechanism to provide 
> similar functionality in a (slightly) different way.
> So, my current thinking is that AO should maybe move TCP-MD5 to 
> "historic". That would indicate that new implementations shouldn't 
> implement TCP-MD5 and existing ones are encouraged to move away from it. 
> But this isn't a clear -cut case. Comments?

I have always viewed a new TCP-Auth RFC as a drop-in replacement
for TCP-MD5.

Basically, this is an application layer problem being foisted upon
the transport layer. It creates unneeded clutter at the transport
layer that is not of general utility.

The fact that it is replacing an existing option is the only real
justification for doing it. Stare decisis is good for constitutional
law, it makes sense for standards as well.

But we need to be clear that we are not creating an *additional*
transport layer encryption solution to solve poor application design,
we're just replacing an existing problem.
tcpm mailing list