Monoculture

[Steven M. Bellovin]

In message <87d6dgbnhj.fsf at snark.piermont.com>, "Perry E. Metzger" writes:
>

>Unfortunately, those parts are rather dangerous to omit.
>
>0) If you omit the message authenticator, you will now be subject to a
>   range of fine and well documented cut and paste attacks. With some
>   ciphers, especially stream ciphers, you'll be subject to far worse
>   attacks still.
>1) If you omit the IV, suddenly you're going to be subject to a
>   second new range of attacks based on the fact that fixed blocks
>   will always encrypt the exact same way.
>
>We went through all that, by the way, when designing IPSec. At first,
>we didn't put in mandatory authenticators, because we didn't
>understand that they were security critical. Then, of course, we
>discovered that they were damn critical, and that most of the text
>books on this had been wrong. We didn't understand lots of subtleties
>about our IVs, either. One big hint: do NOT use IVs on sequential
>packets with close hamming distance!

Better yet, don't use predictable IVs; the threat is much clearer.

Perry is right -- a number of us learned the hard way about 
cryptographic protocol complexity.  I led the fight to remove sequence 
numbers from the early version of ESP, since no one could elucidate a 
threat model beyond "the enemy could duplicate packets".  My response 
was "so what -- packet duplication is always possible per the IP 
datagram model".  (A while back, my ISP fulfilled that part of the 
model; I was seeing up to 90% duplicate packets.  But I digress.)  But 
then I wrote a paper where I showed lots of ways to attack IPsec if you 
didn't have both sequence numbers and integrity protection, so I led 
the fight to reintroduce sequence numbers, and to make integrity 
protection part of ESP rather than leaving it to AH.  We all learn, 
even in embarrassing ways.

My first published cryptographic protocol, EKE, has had an interesting 
history.  One version of it is still believed secure:  encrypt both halves
of a DH exchange with a shared secret.  (Ironically enough, that was
the very first variant we came up with -- I still have the notebook 
where I recorded it.)  We came up with lots of variations and 
optimizations that all looked just fine.  We were wrong...

Someone has already alluded to the Needham-Schroeder protocol.  It's 
instructive to review the history of it.  The original protocol was 
published in 1978; it was the first cryptographic protocol in the open 
literature.  Presciently enough, it warned that cryptographic protocol 
design seemed to be a very suble art.  Three years later, Denning and 
Sacco showed an attack on the protocol under certain assumptions; they 
suggested changes.  In 1994, Abadi and Needham published a paper 
showing a flaw in the Denning-Sacco variant.  In 1996, Lowe published 
a new attack on the *original* Needham-Schroeder paper.  Translated 
into modern terms -- the first paper was published before certificates 
were invented -- the faulty protocol was only three lines long!  Three 
lines of protocol, in the oldest paper in the literature, and it took 
18 years to find the flaw...

No, we're not a guild.  To me, "guild" has connotations of exclusivity 
and closed membership.  Anyone can develop their own protocols, and 
we're quite happy -- *if* they understand what they're doing.  That 
means reading the literature, understand the threats, and deciding 
which you need to counter and which you can ignore.  In IPsec, Steve 
Kent -- who has far more experience with cryptographic protocols than 
most of us, since he has access to, shall we say, more than just the 
open literature -- was a strong proponent of making integrity checks 
option in ESP.  Why, when I just finished saying that they're 
important?  Integrity checks can be expensive, and in some situations 
the attacks just don't apply.  The trick is to understand the 
tradeoffs, and *to document them*.  Leave out what you want, but tell 
people what you've left out, why you've left it out, and under what 
circumstances will that change get them into trouble.


		--Steve Bellovin, http://www.research.att.com/~smb


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com