draft paper: "Deploying a New Hash Algorithm"

Florian Weimer fw at deneb.enyo.de
Wed Aug 17 09:59:49 EDT 2005


* Steven M. Bellovin:

> I'd have phrased it differently than Perry did.  I'd say that the 
> attackers are often cleverer *about security* than protocol designers, 
> because insecurity is their specialty.

I think this misses the point.  Hardly anybody attacks protocols.  In
fact, I think that those who design protocols easily outnumber those
who attack them.

What is being attacked aren't protocols, but implementations.  More
precisely, deployed implementations.  (I'm not talking about PR
attacks here, which can be powerful and costly as well; these are
completely different matters.)  I will receive a lot of flak for this
from the "faith is a verb", sorry, "security is a process" crowd, but
I'm convinced that at the moment, with the technology we have,
security is primarily a deployment issue.  This becomes becomes even
more clear when you give up the misguided and completely unrealistic
focus on prevention, which still plagues large parts of the industry,
despite continuous failure of this approach.

That's why I was shocked when one vocal critic of electronic voting
disclosed that he'd never observed an actual electronic procedure.
When he did, he suddenly realized that some of the attacks he'd been
speculating about couldn't actually work in the field.  (Other attacks
still seemed realistic, though.)

Or another example: Can you criticize the designers of the cookie
protocol that the cookies are not sufficient for secure session
management in web applications?  Or that IPsec XAUTH doesn't prevent
gateway impersonation attacks from insiders?  There are limits what
protocol designers can do, especially if the protocol is a universal
building block.  Security doesn't compose well, so getting individual
protocols right simply isn't the whole story.  Usually, it's even
possible to deploy insecure protocols and implementations in a
reasonably secure manner, and often, this isn't as costly as it
sounds.

> \item   Your enemy is just as smart as you are.  If we haven't seen
>         a given class of attack yet, it's because it hasn't been necessary;
>         simpler attacks have worked well enough.  (Besides, how do you know
>         if you'll actually notice it?)

I think it's also important to realize that new protocols or
countermeasures which protect valuable assets (at least in the
attackers' eyes) can result in a considerable shift in attack
technology, especially on underlying protocols.

In the DoS context, this effect is quite well-known.  Once the end
system's application and TCP/IP stack can withstand the attack, your
network components or link bandwidth is attacked.  Of course, this
increases collateral damage, so it's common practice in a certain
class of DoS targets not to protect your hosts as well as you could.

I fear that a similar shift could occur at a protocol level.  Take
mail authentication, for example.  We have various proposals to use
DNS as a trusted data source.  If attackers think that subverting mail
authentication is a reasonable goal (which I doubt, but let's assume
it for the sake of argument), then it might be feasible to begin
large-scale attacks on DNS.  Of course, these attacks would have
enormous side effects, not just for mail delivery.  You make one thing
more secure, attacks shift to the underlying protocols which are
historically weak, and everybody loses because an old, widely used
protocol is suddenly put under significant stress.

Maybe this fear is a bit far-fetched, especially in the
SPF/DKIM/Sender-ID context, but I think the effect might indeed exist.
In general, attackers don't follow an economic model.  They don't
necessarily attack the weakest link where their attacks might be the
most effective, they just use what works for them.

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



More information about the cryptography mailing list