On 21/08/2009 20:30, Ellen Chan wrote:
Hi again Ian,
Yes I can appreciate that there are priorities and you're reluctant to
get into something overly complex.
Well, I won't be coding it :) I'm just offering my opinion, which we
might recognise as being polarised against the majority here. Indeed:
http://iang.org/ssl/h1_the_one_true_cipher_suite.html
I would summarise it that 99.99% of users of Firefox will make the wrong
assessment, and the remaining portion (who are developers) will know
that the information is not indicative.
So one choice in security terms might be to only supply the
specifications of the connection buried in some debug interface... Or
in marketing terms, to dress it up like blinky lights so that it looks
cool, but is fashionable like a paint job on a car. Personal choice,
unlike the brakes, which are carefully hidden away from the eyes.
...
It
would be ideal if Firefox could steal a trick from putty where the
user can set lower bounds--say allowing the user to specify a lower
bound on the algorithm/strength used for each of authentication,
agreement, and encryption. That's an ideal though, and short of that,
it would be nice simply to be able to know.
That I would see as a way to generate annoying support requests, as
users discover more elegant ways not to communicate :) There aren't
many good reasons to give users flexibility in crypto negotiation, and
plenty of bad reasons.
...
As for the small devices with weak processors, the question there is
really whether or not security should be compromised in the name of
efficiency.
I would think it different. There will be a compromise regardless, the
question is which do you prefer: denial of service against all mobile
users, or reduction of security spread across all users, mobile and net.
In the 1990s, it was fashionable to ignore denial of service, but maybe
it is coming into fashion again?
In such cases I think it's probably even more important to
display the values to the user so that no-one makes the mistake of
believing those devices are actually good enough for secure
applications.
"Is actually good enough?" What does that mean? How can we make that
judgement?
In general, to make such a statement, we would have to ground it in an
application or business. E.g., we could suggest "protect the average
online banking transaction" in which case probably anything vaguely
modern works, as long as it is effective against attacks like phishing.
Probably you are leaning towards a judgement that delivers a fully
secure point to point encryption channel with a known party. But
without a "business reason" behind that, you will never know if the
delivered security is making the right compromises. (This is one of the
problems with all SSL, the usage case and threat models were wrong, and
thus questions such as "how much security" are not possible to answer
comfortably.)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
