Re: [tcpm] Comments on TCP-AO Draft

Eric Rescorla <> Tue, 18 November 2008 21:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 75FA53A6923; Tue, 18 Nov 2008 13:40:10 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 876AD3A6923 for <>; Tue, 18 Nov 2008 13:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.407
X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uj-+Z1AlpTB1 for <>; Tue, 18 Nov 2008 13:40:07 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 687C23A6885 for <>; Tue, 18 Nov 2008 13:40:07 -0800 (PST)
Received: from kilo-2.local (localhost []) by (Postfix) with ESMTP id 769F775D4A8; Tue, 18 Nov 2008 15:40:03 -0600 (CST)
Date: Tue, 18 Nov 2008 15:40:03 -0600
From: Eric Rescorla <>
To: LANGE Andrew <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <>
Cc:, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
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

At Tue, 18 Nov 2008 15:34:10 -0600,
LANGE Andrew wrote:
> (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.
> Elaboration: Originally I was also of this position.  However, I
> came around when I considered the operational impacts.  We need to
> make this protocol as operator-friendly as possible.  That is why it
> is being created to begin with.  We shouldn't lose sight of
> deployability and maintainability in the quest to shorten an option
> by a byte (especially when we gain 3 from MD5 to start with.)  Also,
> we have had many strong security experts, such as ekr and Brian Weis
> (gentlemen, correct me if I'm misquoting you) say that putting
> algorithm ID in the packet does very little to make it harder for a
> bad guy to attack the session.  To be specific, the attacker has to
> be a man-in-the-middle to see the ALG ID to start with (whereas
> blind attacks are probably more likely).  In addition, the search
> space would be extended by a single bit.  We're already using very
> strong algorithms, and have the agility to add more.  Search is
> already infeasible with known state, and if that changes the right
> approach, and the secure approach is to introduce another algorithm.

I don't think there's any real security value to hiding the identity
of the MAC algorithm. I leave the question of whether shaving the
byte is worth doing to the TCP experts.

tcpm mailing list