[Freedombox-discuss] Using more than one security scheme

[Daniel Kahn Gillmor]

On 07/09/2011 06:46 AM, belorn wrote:
> There seems to be an implicit assumption where if one can not have one
> "perfect" solution to security, then the alternative is to use none at
> all.

I find it useful to distinguish between different aspects of "security".
 In this discussion, i believe you're taking about communications
confidentiality (the act of making sure that information can only be
read by the intended parties), not message origin verification,
authorization, anonymity, reliability, or other aspects of "security";
so my comments below are about confidentiality. Feel free to correct me
if i'm wrong!

> it could make a decision on what the best solution to
> security is for each separate connection going through the box.  If it
> doesn't have anything better available, then opportunistic encryption
> could be one of the lowest security solutions before anything falls
> back on clear text.

The problem with this kind of "best-effort" approach when it comes to
data confidentiality is two-fold:

 0) in many contexts, it's possible for an active adversary to turn a
permissive "best-effort" policy into a downgrade attack, and

 1) when you fail at data confidentiality, you fail at it *permanently*
(that is, once an adversary has read the supposedly-confidential
message, there is no way to remediate or recover from the failure).

I actually agree that best-effort approaches can be a reasonable part of
a good crypto toolkit, but the willingness to accept a downgrade needs
to reside in the toolkit policy, and the policy needs to be both
comprehensible to and controlled by the user.  That is, if there's a
message that i would rather fail to get through than potentially leak, i
should be able to say "no downgrades on this communication, please".
Alternately, for a message that i don't really care about
confidentiality at all (e.g. i expect it to be public anyway), i ought
to be able to say "downgrades are OK".

The UI challenge here is not an easy one.  And it's even harder if you
want to cover situations more nuanced than the two extreme examples i
gave above.

How do you represent the tradeoffs to the user so that they can make a
safe and reasonable choice?  It's actually easier to design a
crypto-toolkit that is all-on or all-off than it is to provide the
subtle shades of nuance here to the user in an intelligible and useful
way.  And remember that most people don't think about each of their
communications with this level of scrutiny -- if the crypto UI itself
gets in the way of them doing their other work ("oh, i always have to
click some button to get this box to go away") then it becomes less than
useful -- an annoyance!

Do you have a UI proposal for how to help a user craft a coherent and
unobtrusive "best-effort" policy that won't lull them into a false sense
of security while still providing them with real security when they need it?

I'm not trying to shoot your ideas down here; this is a genuine call for
proposals.  It's a hard problem, and i'd be happy if we could be part of
puzzling out a way to address it :)

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110710/d241e2aa/attachment.pgp>