[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything else ?

[vince_cavanna at agilent.com]

I have been thinking more about this idea of mine and have the following
addional observations:

1. A middle box can, without ever needing to know the secret key, actually
make changes to a portion of a protected packet and compensate for the
effect, on the CRC, of the changes by following the changes with a computed
32 bit field that restores the CRC "state" to what it would have been at
that same point in the data stream had the changes not been made.

This observation does not render my idea useless since unintentional changes
by middle boxes would be caught at the receiver end-node.  The middle box
would be forced to make an adjustment for the intentional changes that it
has made to the packet rather than recompute, as many do today, the CRC of
the entire packet and risk fixing the CRC after making unintentional changes
as well as intentional ones. The middle box cannot recompute the entire CRC
because it does not have all the data (is missing the secret key) protected
by the CRC. 

2. The middle box can relatively easily compute the secret key from a single
packet and thus has no need to discover it nor store it. There is therefore
little point in using a secure key exchange mechanism to distribute the
secret key shared by the end-nodes.

Conclusion:

This idea may have some merit in protecting from unintentional changes by
middle boxes but is not useful for protection from intentional changes.

A motivated and well-heeled middle box can compute the secret key and store
it and use it to recompute the CRC over the entire packet thus defeating the
entire scheme.

Vince

|-----Original Message-----
|From: CAVANNA,VICENTE V (A-Roseville,ex1) 
|Sent: Thursday, June 07, 2001 11:40 AM
|To: 'Jonathan Stone'
|Cc: David P. Reed; tsvwg at ietf.org; end2end;
|sommerfeld at orchard.arlington.ma.us; STEINMETZ,JOE (A-Americas,unix1);
|WAKELEY,MATT (A-Americas,unix1); CAVANNA,VICENTE V (A-Roseville,ex1)
|Subject: RE: [e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
|else? 
|
|
|Jonathan and others,
|
|Would a "keyed CRC32" instead of "keyed MD5" be appropriate 
|for the purpose of preventing unauthorized tampering of the 
|protected packet by middle boxes? A CRC is much further from 
|being a one-way hash function than the MD5, but once keyed, by 
|including the shared secret in the data protected by the CRC, 
|it may be good enough to discourage tampering by middle boxes. 
|The benefit, of course, is that computing the CRC32 digest is 
|much easier than computing an MD5 digest. To foil such 
|protection, Middle boxes would need to, first, discover the 
|shared secret and, second, remember the shared secret - for 
|each connection. Since, as David Reed has pointed out, middle 
|boxes do not store per-connection state, the second step alone 
|may be a large enough obstacle to render adequate the 
|communication of the shared "secret" in the clear and thus 
|avoid the use of a secure key-exchange protocol.
|
|Vince
|
||-----Original Message-----
||From: Jonathan Stone [mailto:jonathan at DSG.Stanford.EDU]
||Sent: Friday, May 25, 2001 2:51 PM
||To: sommerfeld at orchard.arlington.ma.us
||Cc: David P. Reed; tsvwg at ietf.org; end2end
||Subject: Re: [e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
||else? 
||
||
||
||In message 
||<20010525212300.A8F062A4B at orchard.arlington.ma.us>Bill Sommerfeld wr
||ites
||>> [... md5 as an error-check function to defeat would-be 
||middleboxers...]
||>> 
||>> If you put that in the transport layer, won't that makes 
||communication
||>> without a shared-secret impossible? At least without using 
||some other
||>> transport protocol, to bootstrap a D-H or SPEKE or other 
|initial key
||>> exchange.
||>
||>md5 is an unkeyed function, just like the CRC or internet checksum.
||>
||>hmac-md5 is a keyed function built out of md5 (it's one of two MAC
||>functions used with IPsec). [...]
||
||Yes, I know.  David Reed was explicitly suggesting md5 *with* a
||shared-secret (like hmac-md5) as an e2e integrity check in order to
||detect middle-boxes.  Using shared secrets at the transport protocol
||needs way -- perhaps unekeyed md5? -- to bootstrap the conversation.
||
||I hope just aying "md5" while referring to shared-secrets didn't
||cause confusion.
||
||
||_______________________________________________
||tsvwg mailing list
||tsvwg at ietf.org
||http://www1.ietf.org/mailman/listinfo/tsvwg
||
|