I tried (regarding 3DES as a MUST):
However, doesn't this mean "client MUST implement" rather than
"recipient MUST accept"?
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> responded:
`Accepting' 3DES whilst not implementing it sounds strange -- you
accept it and drop it in /dev/null? Perhaps I am not understanding
what you are saying.
Perhaps I'm misunderstanding. I draw a distinction between what my
program (the client, possibly not written by me) understands, and what
I (the user) am willing to accept. If Rot-N and Plaintext are left as
legitimate entries in Section 9.2 and I receive them, I not only want
to drop them in /dev/null, but also to hunt down and exterminate the
system that sent them. OK, maybe too strong. But if they're going
to send insecure messages to me, let them send them in the clear so
everybody is aware precisely what the level of protection is. If it's
Rot-N or Plaintext with CFB XORed with an IV, it'll look secure until
somebody pokes at it with the right tool.
Try this: next year Kwan totally destroys 3DES by finding a gate
reduction to under 100 for 1DES combined rounds 2-15 when they're
considered as a unit. Finney, you, and the NSA have all received
preprints of his Crypto '99 paper. What do you do when you know the
algorithm's broken? Historically algorithms <have> been broken, and we
can expect at least one of the algorithms on our list may run into
trouble if not an outright break. Should you as the key owner be able
to expect cooperation from senders?
He also suggests that the list of preferred algorithms is all the
algorithms the client supports, ordered by preference of user.
OK, what about algorithms you specifically don't want to receive you
don't list. Except you are not allowed to drop 3DES, so either 3DES
always has to be there, or if it is not listed it is assumed to be
there but at lowest preference level.
Not listing algorithms you don't want to receive is fine with me.
I'm not as comfortable with not being able to drop 3DES, but am
willing to go along with it if this is viewed as too paranoid.
Yes I agree. In fact I'd go further I don't want Rot-13 (or Rot-N) to
be defined at all!
Works for me. Also Plaintext as a symmetric cipher type (9.2).
Is there such a concept as plaintext encrypted messages? This would
be like cipher NULL with SSL to stand as a place holder for messages
which are signed only. NULL meaning `no confidentiality' is much
Our equivalent is cleartext signed messages, which is covered
separately from 9.2 (i.e. in Sec. 7). I think we also don't need
Plaintext (9.2).
Another approach to conflicting sender and recipient algorithm choices
is to use both -- super-encrypt in the case of cipher algorithm
choice. Or use some other (to be decided) mechanism to combine
ciphers such that we are confident that the result is as strong as the
strongest of the two ciphers used.
Super-encrypting sounds good to me. I think there are few cases
where doubling up modern algorithms weakens one.
For conflicting signature preferences sign with both algorithms if
both parties able to understand them (where signature includes both
hash choice and signature algorithm).
Sounds good.
Looking back on the discussion, I think I may have the wrong approach
to the design process. I'm suggesting design constraints that will let
me exercise my own preferences, but we should probably be concentrating
on ways to protect the even more naive user. Lucky us when they
intersect, as in dumping Plaintext and Rot-N.
Jim Gillogly
Highday, 30 Rethe s.R. 1998, 00:01
12.19.5.0.9, 8 Muluc 7 Cumku, Ninth Lord of Night