[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
David P. Reed
dpreed at reed.com
Mon Jun 11 11:53:47 PDT 2001
At 11:22 AM 6/11/01 -0700, Jonathan Stone wrote:
>First is that just using md5 doesnt get what you want. With raw MD5,
>the middle-box can recompute (or pass along) MD5 hashes. You have to
>do HMAC-MD5, which pushes up the computational cost considerably.
When I first said MD5 I meant a keyed crypto hash function. The keyed
versions of MD5 are not particularly more complex than MD5. MD5-MAC
involves only a small increment of cost, for example. So we could debate
"considerably" and I think you'd have a hard time convincing me that it's a
very large difference. I'll bow to a careful complexity-class analysis.
>Second is that more computationally expensive error checks are a
>stronger push to outboard checksumming. The data I and Craig have
>gathered shows that the path between the NIC's link-level CRC engine,
>and the TCP (or IP) checksum computation, is a significant cause of
>end-to-end errors. Not checking that part of the end-to-end path
>weakens the end-to-end property of a nominally `end-to-end' error
>check. If advocating ``stronger'', computationally more expensive
>error checks encourages outboard checksumming, you are aiding and
>abbetting in making the check less of an end-to-end check, to
>precisely the degree that outboard checksumming was encouraged.
>Is this what you want to do?
I think I side with Vernon Schryver (as I understand his
point). Checksumming is going to be done in outboard boxes even if it is
cheap, because that gets a few percent. It shouldn't be done there, but it
will. So this is not a strong argument for good design. One could even
argue the opposite - by making the checksum a complex operation that can
only be done efficiently on the application CPU, one encourages it to be
done there. One can increase the probability by providing microcode in the
processor (hey, Intel!) like the inclusion of true random number source in
>Third, is that I wonder if you took in the result from my dissertation
>which Craig reported a couple of days ago? Over the space of all
>possible errors, md5 detects the exact same fraction of errors as MD4,
>or as a 128-bit CRC, or a 128-bit sum, or even a 128-bit constant.
>Given that, what is the *error-detection* rationale for using MD5--
>as opposed (per the earlier disscussion) chooisng a cheaper function,
>which gives us the same Shannon information?
I did, but it does not make sense. Detecting the same fraction is not the
same as having a good probability of detecting the errors that happen in
fact. The constant function is particularly bad on this front. But by
using a keyed class of cryptographically based functions, you increase the
potential set of errors that will be detected eventually if they are repeated.
>Last, a question. I've suggested an adversary models with `blind'
>adversaries which can't exploit the structure of an error-check
>function. You proposed informed, intelligent, malicious adversaries --
>an intruder model which suggests cryptographic approaches.
>We already have protocols which address those latter models.
But they aren't standard. If they were standardly used, we wouldn't need
>Does the end-to-end principle really argue for forcing the cost of
>crypographically-strong error checks onto every end-host, for
>every packet? Or can detecting and defeating middle-boxes
>be achieved via something like ipsec?
IPSEC or something like it would do the job. But it isn't mandatory that
boxes implement IPSEC, and it probably should be mandatory. The end-to-end
argument does support the idea that if security is needed, it must be done
at the endpoints.
I've nearly lost hope that one can argue against those who would deny
authentication and security to all end users. The FBI, NSA, firewall
vendors, and even many operators all have a vested interest in providing
unreliable, insecure, unauthenticatable communications services.
But one more argument is that if most users want some degree of security
and authentication, the "checksum" becomes merely a low-level redundancy
that is unnecessary if the higher levels are doing such checks.
The presumption that most users *don't* want such services end-to-end is
one of the "big lies" (ok, maybe a middle-sized one).
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest