Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00

Eric Rescorla <ekr@networkresonance.com> Tue, 11 March 2008 12:49 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3A028C1D4; Tue, 11 Mar 2008 05:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.149
X-Spam-Level:
X-Spam-Status: No, score=-100.149 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 n+qF-vowyqbK; Tue, 11 Mar 2008 05:48:57 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203713A6DB7; Tue, 11 Mar 2008 05:48:57 -0700 (PDT)
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 A0E8B3A6AFF for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 05:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 d30WVbrEG8SD for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 05:48:51 -0700 (PDT)
Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 9B6E33A6D91 for <tcpm@ietf.org>; Tue, 11 Mar 2008 05:48:51 -0700 (PDT)
Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AFB0C1AB68D; Tue, 11 Mar 2008 08:46:31 -0400 (EDT)
Date: Tue, 11 Mar 2008 08:46:31 -0400
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <47D67BCD.7030508@isi.edu>
References: <20080310233304.47E9B1AA4C7@kilo.rtfm.com> <47D5E090.9010608@isi.edu> <20080311115357.17B5F1AB2D2@kilo.rtfm.com> <47D67BCD.7030508@isi.edu>
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: <20080311124631.AFB0C1AB68D@kilo.rtfm.com>
Cc: saag@mit.edu, tcpm@ietf.org
Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00
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-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

Information is getting spread over two threads here, so I will be repeating
myself a bit.

At Tue, 11 Mar 2008 05:32:13 -0700,
Joe Touch wrote:
> >>> I don't think this API, specification of the TSAD, etc., is
> >>> particularly helpful. IPsec needed the concept of an association
> >>> database because packets corresponding to multiple associations
> >>> got similar treatment. However, TCP has an explicit notion
> >>> of connection so it would be far more convenient to simply
> >>> refer to keys as tied to connections, and then have a set
> >>> of rules for mapping which connections get which keys.
> >> That's exactly what the TSAD is (or at least is supposed to be). It 
> >> might be useful to discuss this offline to figure out what the 
> >> disconnect is...
> > 
> > Perhaps. I think expressing it as a database isn't particularly
> > helpful. There are structures associated with the connection
> > and it's most useful (IMO) to think of this data as attached
> > to them, just as (for instance) the current window or sequence
> > number is.
> 
> Agreed, and that information is deliberately not accessible. Expression 
> of the info as a dbase is equivalent to how TCP describes a "control 
> block". The important issue is the info in each entry, and the index by 
> which they're differentiated.

I think we're going to have to disagree on this one.


> > I really don't see this. The other party presumably has some set of
> > API calls/IPC/whatever, that it talks to. It's not our job to
> > specify the interface between those to, other than the contents
> > of the elements. 
> 
> That's basically all we do - contents, order, and size of each element 
> in each direction.

Well "contents" != "contents, order, and size" and I haven't heard
a clear demonstration that "order and size" are required".


> > I don't see why it's not feasible. They share a key, so there's
> > no reason not to have mutual auth.
> 
> There are cases I can think of - akin to well-known CAs used by web 
> browsers used over wireless channels (see below).

Well, I think any case in which you have public key is fundamentally
different: shared keys imply an opportunity for utual authentication.


> >>>    >> New TSAD entries MUST be checked against a table of previously 
> >>>    used TSAD entries, and key reuse MUST be prohibited. 
> >>>
> >>> Huh? So, I have to keep a list of every TSAD entry ever and check
> >>> against the table. Seems better to just to do this by construction.
>  >>
> >> I'm not sure what "by construction" means, but that's certainly better 
> >> if possible. Can you suggest text or explain this off-line?
> > 
> > I mean that if you randomly generate keys for the TSAD with an
> > appropriate algorithm then there is no reasonable chance that there
> > will be a collision.
> 
> That requires the TSAD only ever be loaded by an automatic key manager, 
> AND that only one such manager ever exist. We don't want to require 
> either for all implementations, thus the TSAD must enforce whatever is 
> needed in this regard.

No, I don't agree with this. Rather, implementors must ensure that 
they don't duplicate entry. If they have two management processes,
they need to somehow coordinate (or use independent algorithms).
That does not mean that the TSAD needs to verify that. Note that
verifying it means retaining records of every key. That seems
impractical.

> >>> S 5.1.
> >>>    o  Number of bytes to be sent/received (two bytes); this is used on 
> >>>       the send side to trigger bytecount-based KeyID changes, and on the 
> >>>       receive side only for statistics or length-sensitive KeyID 
> >>>       selection. 
> >>>
> >>> Please explain the cryptographic rationale for why you would want to
> >>> do bytecount based key changes.
>  >>
> >> That part of the API is strawman; we expect to need to count either 
> >> messages or bytes or both. If message counts are more useful, then we 
> >> can change to that.
> > 
> > I don't see that you need to count either. 
> 
> I recalled this; it's for sequence number rollover. There are TCP 
> connections that send more than 2^32 bytes. We MUST rollover keys when 
> that happens, and we do not want to tie the key system to internal TCP 
> state.

See my previous note for how to do this without rollover using 
ESNs.

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