Furthermore, the latter
question is not terribly relevant, and addressing that question
diverts attention from more important issues.
Huh? Not terribly relevant? Any spec that forces weak cryptography should
be rejected out of hand.
I agree, of course, and I'd be surprised if there were any significant
support for a spec that did support weak cryptography. That's why
I didn't think the question was relevant.
I understand now that you were asking whether your clarification
of this in the latest draft was adequate.
The questions to ask are more on the order of:
a. Will the protocol do what it claims to do?
(e.g. does it really provide assurances of authentication and/or
privacy?)
Good question, and I say the answer is yes on both. No one has said otherwise.
I disagree. If the standard claims to provide a certain degree of
privacy and authentication, but doesn't mandate that implementations
use cryptographic algorithms and key lengths sufficient to ensure
that degree of privacy or authentication, the standard has failed
to make good on its claims.
b. Will it provide adequate security for general-purpose use?
(and if not, what is the intended scope of use, and is that
scope sufficiently broad to warrant Internet standards-track
approval?)
Another good question, and again I say yes. The only time that weak
encryption is mandated is if all of the following conditions are met; in
any other case, strong encryption can be used.
If an implementation can fail to implement encryption of adequate
strength for general-purpose use and still claim to conform to the
standard, the standard isn't providing adequate security.
In the current draft, the only required encryption algorithm is
the "FOO" algorithm with a key size of 40 bits. This is inadequate
for general purpose use.
Even with a longer key, I'd have to question whether the FOO
algorithm has received sufficient public review to make it the
only "MUST support" algorithm in the standard.
Keith