Re: [friam] and so it goes

This is a multi-part message in MIME format.
--===============3289349583803404774==
Content-Type: multipart/alternative;
 boundary="------------060703040908010108050402"

This is a multi-part message in MIME format.
--------------060703040908010108050402
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 1/8/2016 3:23 PM, Raoul Duke wrote:
> https://news.ycombinator.com/item?id=10867647

This topic of secure email is something that I feel frustrated to 
bursting about (from the above):

"email is not authenticated with GPG: it is a usability nightmare. Even 
many technically apt people find it too much of a headache.":

This seems so counter intuitive to me that I'm driven toward a "big 
brother" conspiracy model.

Here's how simple I believe it should be:

1.  Every time I install an email agent it generates a new random 
public/private key pair for my use by this agent.

2.  Every time I send an email the public key for my current agent 
install is sent along.

3.  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.

*With this approach EVERY message EXCEPT a first introductory message is 
transmitted encrypted and signed* so that I have some crypto 
identification of the sender - at least to strongly match their client 
install.

IMO the whole business of "web of trust" is way (!) overblown.  With 
this approach public/private key pairs are "disposable", much like how 
ssh keys are commonly used.

There are some tools to help with "web of trust" stuff that would be 
useful with the above approach.  Of course my client *must* (one of the 
few agent requirements with this protocol) keep a table matching email 
"from" addresses with public keys.  If I ever receive a message "from" 
some email address that comes with a changed public key, I would like to 
be notified of that fact.  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. It might be that something is 
trying to spoof sending email from a contact who I had previously 
identified by a public key.  Generally this isn't a big deal in either 
case. In most cases I'd simply accept the new key - much like when 
dealing with ssh keys.

It might be helpful for my client to allow me to associated multiple 
public keys with a given "person".  Again I don't consider this a big deal.

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.  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).  There are many 
ways to set up such secure communication.  A simple one would be for the 
web site 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.  No muss, no fuss.  I'm sure there are even easier 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).

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.  There might be some helpful tools in clients 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.

Of course I can also imagine ways to "spoof" identities with such a 
scheme as well as the next person.  In most cases (e.g. as with current 
email) I just don't care that much about identities.  In the few cases 
when I do (e.g. financial or legal transactions) care must be taken.  I 
feel confident that protocols and support tools could support such 
situations.

I'd be interested to hear others criticize the above approach to secure 
email.  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?

--Jed http://www.webstart.com/jed/


--------------060703040908010108050402
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <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 class=3D"moz-txt-link-freetext" href=3D"https://n=
ews.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.=C2=A0 Every time I install an email agent it generates a new rando=
m
    public/private key pair for my use by this agent.
    <br>
    <br>
    2.=C2=A0 Every time I send an email the public key for my current age=
nt
    install is sent along.
    <br>
    <br>
    3.=C2=A0 Any time I receive an email from somebody whose agent sent t=
heir
    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.=C2=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.=C2=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.=C2=A0 If I ever rec=
eive
    a message "from" some email address that comes with a changed public
    key, I would like to be notified of that fact.=C2=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.=C2=
=A0
    It might be that something is trying to spoof sending email from a
    contact who I had previously identified by a public key.=C2=A0 Genera=
lly
    this isn't a big deal in either case.=C2=A0
    In 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".=C2=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.=C2=A0 For example, suppose we have the ab=
ove
    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).=C2=A0 There are many ways to set up such secure
    communication.=C2=A0 A simple one would be for the web site to displa=
y 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.=C2=A0 No m=
uss,
    no fuss.=C2=A0 I'm sure there are even easier ways (along the lines o=
f
    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.=C2=A0 There might be some helpful tools in clien=
ts
    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.=C2=A0 In most cases (e.g. as with
    current email) I just don't care that much about identities.=C2=A0 In=
 the
    few cases when I do (e.g. financial or legal transactions) care must
    be taken.=C2=A0 I feel confident that protocols and support tools cou=
ld
    support such situations.<br>
    <br>
    I'd be interested to hear others criticize the above approach to
    secure email.=C2=A0 I can understand how the intelligence agencies mi=
ght
    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=C2=A0 <a class=3D"moz-txt-link-freetext"
      href=3D"http://www.webstart.com/jed/">http://www.webstart.com/jed/<=
/a>
    <br>
    <br>
  </body>
</html>

--------------060703040908010108050402--

--===============3289349583803404774==
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

--===============3289349583803404774==--