Jim Gillogly <jim(_at_)mentat(_dot_)com> writes:
Perhaps we should consider some scenarios about why a recipient or
a sender would have a preference.
- Example: I normally use this key/username to get gigabyte files of
satellite data dumped to my machine. If they send it in 3DES
my scruffy P1 can't keep up. I need it to use CAST or Blowfish.
If the sender overrides this and sends me 3DES, my machine chokes.
Note that in this latter case the user chooses not to accept the
MUST algorithm for good (though uncommon) reasons -- should this
be OK?
It seems valid to be able to say you don't want to receive messages
encrypted with 3DES (by leaving it off the list of capabilites).
However I think this equates roughly to putting 3DES last on your list
of accepted ciphers, because as 3DES is a MUST algorithm, everyone
knows you can actually read it, and may choose to send you it against
your wishes. Indeed some people may have no other choice if they are
using a minimal implementation. There wouldn't be much point ignoring
the data encrypted with 3DES after you've received it, and because of
users of minimal implementations your client would need to accept it
to claim compliance as 3DES is a MUST. I think this leads to the
conclusion that you SHOULD NOT be able to disable 3DES, though putting
it lowest on your list of preferred algorithms should be fair enough.
Adam Back suggests that 3DES need not be listed, since it's a MUST.
My reason for saying this was I thought that perhaps it was redundant
to list it, but on further reflection I retract that: you will have to
list 3DES in order to specify your relative preference for it over
other ciphers you choose to accept if you want to give it other than
default preference.
However, doesn't this mean "client MUST implement" rather than
"recipient MUST accept"?
`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.
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.
I strongly object to this -- I do not want to accept Rot-N or
Plaintext encrypted messages, whether or not my client knows what to
do with them, since I trust my own guesses about security of
algorithms more than I trust most people sending messages to me.
Yes I agree. In fact I'd go further I don't want Rot-13 (or Rot-N) to
be defined at all!
If I remember rightly the sequence of events that led to ROT-N being
listed was that I made a reductio ad adsurdum (sp) argument giving
ROT-n as the example of why you should not implement something which I
viewed to have weak security, and Jon promptly added the ROT-N as a
joke. Please remove it! It is a security risk.
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
preferable to Rot-13 meaning `no confidentiality' because it will
confuse people. Rot-13 is redundant anyway if there is a NULL cipher.
What are some scenarios that would make ignoring the recipient's
preference the correct decision?
I am the sender, I am control what algorithms get used on sending. If
the recipient says he would prefer CAST5, but I prefer IDEA and his
capabilities say that he can accept IDEA but prefers CAST5, well I
will send it to him as IDEA if I want to.
I as sender have a right to over-ride recipients algorithm preferences
up to but not beyond the point of using ciphers which he claims to not
be capable of decrypting. I also have a `right' to send stuff
encrypted to him which I know he won't be able to read, however, I
don't think a conforming implementation should assist me in doing
this.
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.
For conflicting signature preferences sign with both algorithms if
both parties able to understand them (where signature includes both
hash choice and signature algorithm).
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`