Re: [SPAM] Re: [friam] and so it goes
Sandro Magi <[email protected]> Mon, 18 Jan 2016 11:57:43 -0500
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
--===============6159262262134057965==
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Certainly a marked improvement over
unencrypted content, but it doesn't handle key expiry. Once my key
expires, all my subsequent e-mails to you will not match the
public key you stored, so what's a key update protocol that's also
secure?<br>
<br>
Encrypted messages also reduces the effectiveness of search, which
is a big issue with today's e-mail volume.<br>
<br>
Sandro<br>
<br>
On 17/01/2016 3:35 PM, Jed Donnelley wrote:<br>
</div>
<blockquote cite=3D"mid:569BFB10.7060801-iCFHVraI1K1Wk0Htik3J/[email protected]" type=3D"cite">
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">On 1/8/2016 3:23 PM, Raoul Duke
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAJ7XQb7bQD=3Dr_sPqTViHTz8m3jk9yGe2x9tjtfxQcpO0gJM1Zg-Rq2MYuBUFGs@public.gmane.org=
ail.com"
type=3D"cite">
<pre wrap=3D""><a moz-do-not-send=3D"true" class=3D"moz-txt-link-=
freetext" href=3D"https://news.ycombinator.com/item?id=3D10867647">https:=
//news.ycombinator.com/item?id=3D10867647</a>
</pre>
</blockquote>
<br>
This topic of secure email is something that I feel frustrated to
bursting about (from the above): <br>
<br>
"email is not authenticated with GPG: it is a usability nightmare.
Even many technically apt people find it too much of a headache.":
<br>
<br>
This seems so counter intuitive to me that I'm driven toward a
"big brother" conspiracy model. <br>
<br>
Here's how simple I believe it should be: <br>
<br>
1.=A0 Every time I install an email agent it generates a new random
public/private key pair for my use by this agent. <br>
<br>
2.=A0 Every time I send an email the public key for my current agen=
t
install is sent along. <br>
<br>
3.=A0 Any time I receive an email from somebody whose agent sent
their currently used private key along (as all good agents should
with EVERY email), my agent will default to sending any new
messages to that 'from' address (e.g. the initial reply any any
new messages to that "from" address) with an encrypted and signed
message using my private key and their public key - sending my
public key along also of course as always in a header field. <br>
<br>
<b>With this approach EVERY message EXCEPT a first introductory
message is transmitted encrypted and signed</b> so that I have
some crypto identification of the sender - at least to strongly
match their client install. <br>
<br>
IMO the whole business of "web of trust" is way (!) overblown.=A0
With this approach public/private key pairs are "disposable", much
like how ssh keys are commonly used. <br>
<br>
There are some tools to help with "web of trust" stuff that would
be useful with the above approach.=A0 Of course my client <b>must</=
b>
(one of the few agent requirements with this protocol) keep a
table matching email "from" addresses with public keys.=A0 If I eve=
r
receive a message "from" some email address that comes with a
changed public key, I would like to be notified of that fact.=A0 It
may simply be that the sender has installed a new email agent or
generated a new key pair out of concern that an older private key
was compromised.=A0 It might be that something is trying to spoof
sending email from a contact who I had previously identified by a
public key.=A0 Generally this isn't a big deal in either case.=A0 I=
n
most cases I'd simply accept the new key - much like when dealing
with ssh keys.<br>
<br>
It might be helpful for my client to allow me to associated
multiple public keys with a given "person".=A0 Again I don't
consider this a big deal. <br>
<br>
I think it might be illustrative to show how, once the above
approach is established, people could set up a tighter identities
("web of trust") if needed.=A0 For example, suppose we have the
above setup and I want to set up securely identified email
communication with a financial or legal adviser who I otherwise
interact with through a secure login to a web site (think Fidelity
or Etrade or a bank or whatever).=A0 There are many ways to set up
such secure communication.=A0 A simple one would be for the web sit=
e
to display a public key for my agent and for me to submit my
(current) public key to be trusted for such communication through
the web site.=A0 No muss, no fuss.=A0 I'm sure there are even easie=
r
ways (along the lines of emails with web links that are commonly
used) that would avoid exposing the notion of a "public key"
(perish the thought). <br>
<br>
There are many ways to set up stronger notions of trust associated
with a given public key, bind such keys together, transit from one
key to another, etc.=A0 There might be some helpful tools in client=
s
to support such mechanisms, but even without any such support I
believe we would be way, way "ahead" of where we are now in terms
of secure email. <br>
<br>
Of course I can also imagine ways to "spoof" identities with such
a scheme as well as the next person.=A0 In most cases (e.g. as with
current email) I just don't care that much about identities.=A0 In
the few cases when I do (e.g. financial or legal transactions)
care must be taken.=A0 I feel confident that protocols and support
tools could support such situations.<br>
<br>
I'd be interested to hear others criticize the above approach to
secure email.=A0 I can understand how the intelligence agencies
might shake in their boots at the thought that such a scheme
(default strongly encrypted email) might become widespread.
However, for the rest of us, what might anybody see as a downside
to the above approach? <br>
<br>
--Jed=A0 <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext=
"
href=3D"http://www.webstart.com/jed/">http://www.webstart.com/jed=
/</a>
<br>
<br>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
cap-talk mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
s.org">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.eros-os.org/mailman=
/listinfo/cap-talk">http://www.eros-os.org/mailman/listinfo/cap-talk</a>
</pre>
</blockquote>
<br>
</body>
</html>
--===============6159262262134057965==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
--===============6159262262134057965==--