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

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Eric Rescorla
> Sent: Tuesday, July 29, 2008 6:53 AM
> To: Joe Touch
> Cc: Adam Langley; tcpm@ietf.org; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
> 
> At Tue, 29 Jul 2008 06:40:48 -0700,
> Joe Touch wrote:
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > 
> > Anantha Ramaiah (ananth) wrote:
> > | Folks,
> > |    The extended feeling which I get after watching some of the 
> > | conversation is that we seem to be in a cherry picking 
> mode of what 
> > | to include/exclude in the digest (MAC) computation. 
> (psuedo header, 
> > | TCP options etc.,)
> > |
> > | 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.
> > 
> > Whether or not there are options to that MAC or not that need to be 
> > coordinated end-to-end is up to the key management system; e.g., 
> > parameters like "just the firs 10 bytes" can be encoded - again 
> > opaquely to TCP-AO - in the key used on a connection.
> 
> 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.

I agree and that was what I was thinking when I was proposing this.

> 
> 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.

Agreed. It needs to come from TCP-AO level even it means changing the
format of the TCP-AO option to accomadate this. As an end user of this
option I wan't to know how much was "digested" explicitly conveyed as
opposed to implicit schemes. Having this in TCP-AO allows a  per packet
granularity and that is good to have, IMO, if we are going down this
route.

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