[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP revisions straw poll
My original reaction was "no, I don't like this idea". After all, we
have permitted ESP through the firewall, based solely on the protocol
ID and the destination address pointing to the secure tunnel endpoint on
the inside. Do I really want unencrypted traffic flowing that way?
Then I realized that someone could define and implement an arbitarily
weak "encryption" algorithm and use it, if the tunnel permitted. Anyone
for 40-bit RC4? 4-bit RC4? Rot-n? (The spec for Rot-n might make a great
April 1 RFC, save that last April 1, someone actually implemented it as
an encryption mode for ssh and other folks took it seriously... Me -- I
want a monoalphabetic substitution. Done computer-style, there are 256!
possible keys -- by my calculations, about 1684 bits, which puts triple IDEA
to shame...)
In other words, the firewall or its trusted peer have to participate in the
key management dialog, if you want to pass encrypted traffic only if it is
above a certain strength level.
As a complement to AH, it's harmless. As a replacement, it's superior.
(Folks
may remember my long arguments against the AH architecture. This is much
cleaner.) My major concern is that APIs be structured so that *no one* gets
this mode by accident.