[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
> Well, okay, but be that as it may, 40 bit encryption remains worthless
> for confidentiality, and becomes even less worthwhile by the day. An
> RFC defining how to do it puts an implicit IETF imprimateur on a bad
> practice. I'd rather it not be standardized or endorsed in any
> fashion.
You should've read my post before you got carried away with that knee
jerk reaction. I said "'40 bit DES' is out." I was suggesting standardization
on a cipher which takes variable-length key, such as Blowfish, and _not_
40 bit DES.
> > I'm trying to forge a compromise and am sympathetic to people who
> > may not have a job because their company can't make enough money in
> > a domestic market alone.
>
> Tell them to call up their Senator and explain to them that export
> controls are destroying their jobs.
You obviously think people have been sitting on their thumbs for the past
few years. Without going into the gory details let me just submit that you
obviously don't know what you're talking about.
> In short, standardizing bad technology to give jobs to people selling
> literally worthless devices is not what the IETF is about. We are not
> about job creation. We are about *Engineering*.
If your worried about tarnishing the good name of the IETF or out-of-control
marketeers saying their product is "blessed by the IETF" let me point a
few things out:
1. Marketeers are already doing this. "We're RFC-compliant" means
their proprietary protocol uses HMAC. Or even better, It's been
"submitted to the IETF" means their braindead idea has been
written up as an Internet Draft and languishes in some working
group and will expire shortly.
2. An "exportable" IPSec implementation which only supported a
variable length key cipher (like Blowfish) and refused to
negotiate any length > 40 would not be "IPSec compliant" anyway
because they didn't do the mandatory-to-implement transform.
Of course, that won't stop the marketeers from claiming compliance
but there's nothing you can do about that and there are plenty
of companies that currently do only the depricated transforms with
manual keying and still say they're "IPSec compliant".
3. Someone can already produce "exportable" IPSec implementations
by negotiating a transform from the private use range in the
DOI numberspace and negotiate a 512-bit Diffie-Hellman group
directly (P,G,type instead of using one of the already-defined
identifiers). And, again, there's nothing you can do to stop them
from claiming they "do IPSec".
4. A standardized cipher which used variable length keys would not
have to have the number 40 in it anywhere; it would not have to
discuss dumbing down your crypto. It would not be an IETF
endorsement to do anthing stupid in the way that a standardized
40bit DES specification would. (Of course, you know the _real_,
sinister reason for variable length keyed ciphers, wouldn't you
Agent Molner?).
5. I know of a company (not mine!) that is working on a version
of IPSec that includes key recovery. It's gonna do 3DES especially
for you Perry but the key will be leaked. They can proudly
boast that the IETF imprimatur is stamped on their foreheads
and their product is insecure.
Given the amount of times "IETF approved" is used in vain your arguments
about the sanctity of the IETF imprimatur reminds me of someone defending
the good name of a prostitute. Give it up, her virginity was gone long ago.
The real problem it seems to me is the blind faith that someone would put
in the statement "RFC compliant" or "IETF approved" or "security expert".
Especially if it come out of a marketing brochure.
You're right, this is about "engineering". What is your non-political
opposition to standardization on Blowfish? It's free, it's (pretty) fast,
and it supports 448-bit keys if you're really hung up on key length (and
it appears you are).
Dan.
Follow-Ups:
References: