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

Eric Rescorla <ekr@networkresonance.com> Fri, 19 June 2009 16:12 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 43AE53A6B0D for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=1.197, BAYES_00=-2.599]
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 IU6V35yj3SzK for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:12:39 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7FDCD3A6832 for <tcpm@ietf.org>; Fri, 19 Jun 2009 09:12:39 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id EFC4850822; Fri, 19 Jun 2009 09:16:14 -0700 (PDT)
Date: Fri, 19 Jun 2009 09:16:14 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3BB16A.1000508@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> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) 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: <20090619161614.EFC4850822@romeo.rtfm.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: Fri, 19 Jun 2009 16:12:40 -0000

At Fri, 19 Jun 2009 08:40:26 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> >> If that's where we put that logic, what happens when we don't have a
> >> KMP? How do we know that both ends will do the same thing with a set of
> >> manually entered keys?
> > 
> > It was my understanding that the consensus was that we were not 
> > going to design a system that attempted to prevent user error.
> 
> Oh, absolutely, agreed.
> 
> This is the kind of error where two ends install the keys correctly, but
> internally the two implementations resolve overlap in different ways, so
> keying fails.
> 
> > Given that typographical errors in key entry seem far more likely
> > than this kind of misconfiguration, if our intent is to prevent
> > user error, then we should be attacking that first.
> 
> As above, this isn't a user error issue. This is a case where leaving
> something to the implementer is what is causing the problem.

Then I don't understand what you're talking about.

The user installs two MKTs, one of which covers all ports and
one of which covers port 521 (randomly chosen). Either of these
MKTs is valid and either end can use either one to secure
the connection independently. It doesn't matter what the
prioritization schemes are on either end.

If you're saying that the installation of a more specific MKT
should not only take priority over but actually disable a
less specific MKT for that port, then I think that's a pretty
clear bug.

-Ekr