At 12:14 PM -0700 4/18/97, Raph Levien wrote:
Paul Hoffman writes:
It's clear to me that some people who are replying on this list haven't
read the draft since they didn't know that the draft has two profiles, a
"restricted" one that has 40-bit only and an "unrestricted" one that has
both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the
restricted profile should be used, and that's pretty damn rarely.
I have a few problems with this. 2.6.3 appears to give users the choice
between incurring the "risk of failed decryption" and defaulting to
RC2/40. Again, I'm not sure we can claim "interoperability" in the
former case.
Note that a sender or receiver using the unrestricted profile MUST be able
to encrypt *and* decrypt the restricted algorithm. (See the list at the
beginning of Section 2.6.2.) Thus, interoperability is assured in 2.6.3, if
and only if the unrestricted client really does do both halves of the
restricted algorithm.
I don't mean to whine, but I am quite curious why my earlier proposal
(in which the default algorithm was dependent on the length of the
recipient's RSA key) was abandoned. This proposal maximized
interoperability in the case where one of the agents was restricted, yet
prevented RC2/40 from being the default choice in the case where neither
agents were restricted.
This was my decision, and I'm willing to turn around an put it back in if
the group wants it. The reason I took it out is that your heuristic is both
time-dependant and law-dependant, and it seemed wrong to codify this in a
long-lasting spec.
- What if the US government starts allowing longer RSA keys but not
stronger encryption algorithms?
- What if the US government decides that 56 bit DES is OK, and allows
slightly longer RSA keys to match? The current heuristic jumps from 40-bit
RC/2 to full tripleDES.
- What if some other government, using broken logic similar to the US,
allows strong encryption algorithms but only shorter keys?
Again, I'm open to arguments on putting the key-length heuristic back in,
but I'd want to feel that the rules in the spec all would be valid five and
maybe ten years from now. I'm also willing to put in other heuristics that
we all think will pass the test of time.
Section 2.6.3.3 also invites protocol attacks:
. . .
It is not stated here how the sending agent should determine whether it
has receieved "at least one message from the recipient." Does it simply
use the e-mail address in the "From:" header field to identify the
sender? Or does it require a trusted signature as well?
Good point. I'll rewrite this to state that only trusted signatures should
be used to pass the test in this section.
Pardon me for being blunt, but from a user's perspective, having a
single protocol with two different profiles is no different from having
two different protocols.
No need for pardon; in fact, I think thanks are in order. This is probably
the most succint statement yet made on the issue. The protocols may have a
high level of overlap, but they don't have interoperability, and are thus
separate.
--Paul E. Hoffman, Director
--Internet Mail Consortium