[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IVs, summary of discussion
>I'd like to vote against two trends here: violating protocol layering
>and analyzing privacy and authentication as if they were totally
>orthogonal. Using the IP ID in IPSEC seems like a hack of such micro
>advantage in its context as to approach silliness. And with regard to
>the mix-n-match approach to encryption and authentication/integrity. I
A similar but well-established layer-violating hack is the
"pseudo-header" used to compute TCP and UDP checksums. An IPSEC that
uses the ID field as an IV would hardly be unique -- existing
transport protocols have the same property, and solutions will already
have to be found to the IPv6 porting problem.
Even if IPSEC didn't use the ID field, it would still need to know the
sender's IP address since it is logically part of the security
association identifier, just as the sender's IP address is part of a
TCP or UDP connection identifier. Passing up IP addresses is arguably
just as much a "layering violation" as passing up the IP ID for use as
an IV. The only way around it would be to extend the 4-byte SAID field
to make it globally unique, which is really not necessary.
The "micro advantage" you speak of is the saving of overhead -- up to
8 bytes for DES depending on alignment considerations -- that would
otherwise be needed to carry an explicit IV. This may not matter to
some of you, but it does matter a lot to people like Ran and me who
want to run this stuff over slow radio links -- where security is
probably more urgent than on any other medium. I'm willing to add
overhead if that's the only way I can get some sort of benefit, but
not if there's another way to do the same exact thing for free.
On the mix-and-match issue, nothing says we can't define each IPSEC
"mode" as a combination of an encryption algorithm (e.g., DES CBC) and
an authentication algorithm (e.g., keyed MD5). One of the nice things
about the latter algorithm as opposed to relying on side effects of an
encryption algorithm is that we can "tune" the authentication strength
(and overhead) by simply sending as much or as little of the MD5 hash
as desired. If you want something comparable to the 16-bit TCP header
checksum, then you only need send and verify 2 bytes of the hash; if
you want maximum protection, send all 16 bytes, or switch to SHA
and send 20.
Then the next question is whether we can agree on a "default" size for
the authentication field that would satisfy enough users to make
changing it (either bigger or smaller) a relatively unusual thing.
Comments?
Phil
Follow-Ups:
References: