[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

analysis thus far



Warning -- wide (about 160 columns) message follows...

I decided to make a chart of the different attacks and different defenses.
There are four different attack scenarios listed:  CBC cut-and-paste
and replay, for both host-based and router-based cryptography.  What
jumps out from the chart is that no single defense proposed thus far
is a complete solution, though a combination of sequence numbers with
integrity checks comes closest.  (It can fail against an active attack:
the enemy can delete the last few packets, create a new socket using
that port, and reinject the packets, so long as they arrive before the
sequence window has expired.)

It's also apparent that router-based crypto is very hard to defend
against any of these attacks, especially the replay.  I'm tentatively
inclined to stop hardening our mechanisms against that case, and instead
decree that router-based crypto is useful if and only if (a) everyone on
the inside is trustable (but see below), or (b) it's being used as
firewall crypto to superencrypt already-protected traffic when using
the public Internet as a link in a virtual private net.

The remaining case that troubles me is the host-to-router case, where
I, on my host, am doing the right things, but I'm talking to you on
your account on bletch.com (foo.com and foobar.com are real!).  Can
you read my traffic?  Probably, given the stuff we've been discussing.
But that's also the case if you're doing any of myriad other things
wrong, or if you've been hacked, so it's probably not worth worrying
about here.  It might, though, be worth including a flag in the certificate
indicating the granularity of protection.

The chart is below; I'm quite willing to add new rows or columns, or to
change entries as needed, or to reformat it to use tbl or LaTeX tables...


-----
			Host-based			Host-based			Router-based			Router-based
			CBC cut-and-paste		Replay				CBC cut-and-paste		Replay
			-----------------		-----------------		-----------------		-----------------
User-pair keying	safe				safe				hard to implement		hard to implement

Connection keying	safe				safe				hard to implement		hard to implement

Per-packet rekey	safe				no defense			safe				no defense
(SKIP-style)

Sequence numbers	no protection against		some protection against		no protection against		some protection against
w/host-pair keying	active attack unless		active attack; late packets	active attack unless		active attack; late packets
			integrity used also;		may be decipherable		integrity used also;		may be decipherable
			safe if integrity used						safe if integrity used

Integrity checks	safe				no protection			safe				no protection




Notes:

``safe'' means that the mechanism appears to defeat the attack.

``no protection'' means that the attack still works.

``hard to implement'' means that there are conceptual problems or that
other necessary pieces have not yet been defined, such as host-to-router
messages.