--On Monday, April 25, 2016 15:52 -0700 Dave Crocker
<dcrocker(_at_)bbiw(_dot_)net> wrote:
On 4/25/2016 1:18 PM, Steve Atkins wrote:
The nasty bit is trusting someone you don't trust with your
private key to serve you the javascript code your crypto is
executing on.
+1, and thanks for noting it.
In practical terms, if the mail operator is supplying the
client code, then the client's activity is wholly controlled
by the operator. That includes the operator knowing the
user's private key.
But the general form of this is: whoever supplies the MUA --
or, more precisely, the user's encryption-related software and
process -- knows the user's private key. Or at least, they
can. So creafully vetting that code and supplier is essential.
I agree almost completely, but with one small, practical,
exception. It, again, depends on who and what one is trying to
protect against. If the concern is about the casual curiosity
of a neighbor, then mail provider (or MUA provider) protection
or encryption just good enough to constitute a significant
annoyance may be sufficient protection. If one is worried about
curious operators working for the mail provider who have too
much time on their hands, even a compromised MUA may be ok if
the compromise is not widely known and whether or not mail
encrypted in keys supplied by the mail provider is at risk
depends on that provider's policies and how strictly they are
monitored and enforced. If one is concerned about surveillance
of messages in transit, then TLS-style link encryption is fine
("opportunistic" or otherwise) as long as you trust the MTA
providers at both ends and their staffs. If you don't, it is
often easier to attack the servers, message queues and mailboxes
than the links and, even for the links, if the decryption keys
can be (or are) compromised. all bets are off. Finally, if the
real concern is an entity who is targeting you in particular and
has resources (of money, supercomputers, the ability to issue
secret subpoenas, or all three), then it is not clear what helps
unless the message is strongly encrypted end to end using
mechanisms, software, and keys that you control and have audited.
Looking at those distinctions makes a lot of the current efforts
look, to some of us, a lot more like security theater than real
and focused protection -- overkill for the casually curious and
insufficient for targeted and well-resourced attacks. That
doesn't get me to "you can't control everything so it is
hopeless and you should just give up" but I think it argues for
some careful thought about methods, claims, and what is actually
being protected and against whom.
best.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp