Re: [tcpm] Comments on TCP-AO Draft

Eric Rescorla <ekr@networkresonance.com> Tue, 18 November 2008 21:40 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FA53A6923; Tue, 18 Nov 2008 13:40:10 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876AD3A6923 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 13:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.407
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj-+Z1AlpTB1 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 13:40:07 -0800 (PST)
Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 687C23A6885 for <tcpm@ietf.org>; Tue, 18 Nov 2008 13:40:07 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (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 <ekr@networkresonance.com>
To: "LANGE Andrew" <Andrew.Lange@alcatel-lucent.com>
In-Reply-To: <66F9363AB70F764C96547BD8A0A3679E154CB9@USDALSMBS05.ad3.ad.alcatel.com>
References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> <B5A5E01F9387F4409E67604C0257C71E7A3296@NDJSEVS25A.ndc.nasa.gov> <66F9363AB70F764C96547BD8A0A3679E154CB9@USDALSMBS05.ad3.ad.alcatel.com>
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: <20081118214003.769F775D4A8@kilo.rtfm.com>
Cc: tcpm@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
Subject: Re: [tcpm] Comments on TCP-AO Draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm