Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

Eric Rescorla <ekr@networkresonance.com> Tue, 29 July 2008 15:17 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 800383A6B96; Tue, 29 Jul 2008 08:17:39 -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 B32DC3A6B92 for <tcpm@core3.amsl.com>; Tue, 29 Jul 2008 08:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 14cu2ow7f33s for <tcpm@core3.amsl.com>; Tue, 29 Jul 2008 08:17:37 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id EEBF23A6B96 for <tcpm@ietf.org>; Tue, 29 Jul 2008 08:17:36 -0700 (PDT)
Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BFC344BD795; Tue, 29 Jul 2008 08:17:49 -0700 (PDT)
Date: Tue, 29 Jul 2008 08:17:49 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <488F24CB.8060803@isi.edu>
References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> <488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> <488F24CB.8060803@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: <20080729151749.BFC344BD795@kilo.rtfm.com>
Cc: Adam Langley <agl@imperialviolet.org>, tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
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, 29 Jul 2008 07:10:19 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Eric,
> 
> Eric Rescorla wrote:
> | At Tue, 29 Jul 2008 06:40:48 -0700,
> | Joe Touch wrote:
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> ...
> |> | So, if we are going down that route, then I would argue it may be
> |> | worthwhile to debate "how much" to include in general, i.e, is it
> |> | worthwhile to include selective portions OR part of the data portion of
> |> | the TCP data in the MAC computation instead of he entire data.?
> |>
> |> Absolutely; that can be implemented inside the MAC algorithm, opaquely
> |> to TCP-AO, though. I.e., I can create a MAC that hashes only the odd
> |> blocks, only the first half of the blocks, etc.
> ...
> | Well, it's true that one *could* do this, but I think it's a really
> | bad idea. MACs should provide a uniform interface and set of semantics.
> | If you want to have partial coverage, this should be handled at the
> | TCP-AO level.
> 
> First, I'm not sure this overall function is useful; since apps can't
> align data to the TCP segments, IMO the data is "all or none". I don't
> see a reason to omit the data entirely from a MAC (excepting performance
> for statistical benefit).
> 
> Overall, this doesn't seem to fit the spirit of "TCP-AO should be simple".
> 
> | I appreciate that you're trying to isolate the crypto from the TCP-AO
> | service, but I don't think you can isolate it to this extent.
> 
> It would be useful to explain the reason you see a need for coupling
> here (provided this is even needed, as noted above).

(1) I don't think it's needed.
(2) The semantics of partial protection are only meaningful at the TCP
    layer. The MAC just operates on chunks of bits.

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