Re: [tcpm] question about TCP-AO and rekeying

Eric Rescorla <ekr@networkresonance.com> Thu, 18 June 2009 05:15 UTC

Return-Path: <ekr@networkresonance.com>
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 65FF73A6B3D for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.205
X-Spam-Level:
X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=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 rZu+S4yGdOTa for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:15:45 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 239143A6B15 for <tcpm@ietf.org>; Wed, 17 Jun 2009 22:15:45 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 719361BDC6B; Wed, 17 Jun 2009 22:16:22 -0700 (PDT)
Date: Wed, 17 Jun 2009 22:16:22 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A39C800.2030901@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090618051622.719361BDC6B@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Thu, 18 Jun 2009 05:15:46 -0000

At Wed, 17 Jun 2009 21:52:16 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> >>> If so, the entry fails. If that's what
> >>> you mean by "prohibit overlaps", yes, I think we should
> >>> prohibit overlaps. 
> >>>
> >>> If what you mean is that two MKTs with different key-ids can't overlap
> >>> the same socket pair space, I don't see a problem with that.
> >> That is a problem for outgoing SYNs. For those, either the connection
> >> has to know a-priori which ID to use, or we need to make sure MKTs can't
> >> overlap at all (ignoring keyIDs).
> > 
> > I'm sorry, but I don't see why. 
> 
> So let's consider outgoing SYNs.
> 
> Consider a system with two MKTs:
> 
> 	MKT alpha	from ANY:ANY to JOE:80	KEYID=4
> 
> 	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5
> 
> 
> So my web client wants to connect to JOE:80. The web client has not been
> modified to indicate a desired KEYID; I doubt many apps will be so
> modified. So I'll need to ensure that the socket pair of the SYN matches
> only one MKT.
>
> That means I can't have default keys, like beta.

Why on earth would you want to do this? The misquote Dr. Strangelove,
"the whole point of a cryptographic key is lost unless you keep it
a secret. Why would you tell the world?"

Since almost every other machine on the Internet isn't going to 
have key beta, you're going to get packets that aren't protected
with AO, in which case you'll have to discard them. Configuring
your system this way is mostly useful for breaking TCP.

-Ekr