Re: Getting to default encrypted/signed email (was: Re: [friam] and so it goes)

--===============0932078930820178363==
Content-Type: multipart/alternative; boundary=001a113f9b44b72b4e05299f914c

--001a113f9b44b72b4e05299f914c
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 18, 2016 at 1:02 AM, Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>
wrote:

> This is why I suggested an implementation change in email clients that
> would make such encryption and signing:  1. happen by default and 2.  be
> invisible.  In that case there would be never be any "weird
> incomprehensible junk" seen in emails.  I hope you agree that if the
> implementation is automatic and invisible then a situation like this, "*Three
> hours later I hadn't gotten it working and gave up.*" doesn't arise.
> With this approach there is nothing to get working.  If there are other
> social problems that would still be there I very much want to learn about
> them before pursuing this topic further, so I appreciate any thoughts on
> the matter.
>

So for what it's worth, this is already happening server-side with SPF,
DKIM, and DMARC, just not in an end-to-end manner. Any emails coming from
me, for example, are DMARC authenticated by Google. This is happening in a
totally transparent manner without any additional "gunk" added to message
bodies (only to the headers).


> In that case neither user would be aware of the key change.  Sure, in that
> case a user would be subject to a man in the middle 'attack' where such a
> middle man could pose as a previously known end user.  That can be
> important in the 1% of cases where it's vital that a person or institution
> is bound to a message exchange.
>

A system where any remote attacker can arbitrarily change authentication
keys without notifying the user doesn't sound like it offers any security
at all.

There are systems that try to manage keys on a user's behalf, like CONIKS:

http://www.coniks.org/our-solution/

In a system like this, a user authenticates to their provider and publishes
a new key in their provider's CONIKS key directory. This directory
maintains an append-only log of all key changes ala a Certificate
Transparency log (authenticated as a Merkle log proof).

The key directory can be kept "honest" by auditor nodes which watch the
directories looking for inconsistencies (and having clients check with
auditors before using a particular directory's keys), and/or by clients
gossiping Merkle roots to each other.

-- 
Tony Arcieri

--001a113f9b44b72b4e05299f914c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 18, 2016 at 1:02 AM, Jed Donnelley <span dir=3D"ltr">&lt;<a href=3D=
"mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]" target=3D"_blank">capability-iCFHVraI1K1Wk0Htik3J/[email protected]<=
/a>&gt;</span> wrote:<br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>This is why I suggested an implementation change in email clients
    that would make such encryption and signing:=C2=A0 1. happen by default
    and 2.=C2=A0 be invisible.=C2=A0 In that case there would be never be a=
ny
    &quot;weird incomprehensible junk&quot; seen in emails.=C2=A0 I hope yo=
u agree that
    if the implementation is automatic and invisible then a situation
    like this, &quot;<i>Three hours later I hadn&#39;t gotten it working an=
d gave
      up<b>.</b></i>&quot; doesn&#39;t arise.=C2=A0 With this approach ther=
e is
    nothing to get working.=C2=A0 If there are other social problems that
    would still be there I very much want to learn about them before
    pursuing this topic further, so I appreciate any thoughts on the
    matter.<br></div></div></blockquote><div><br></div><div>So for what it&=
#39;s worth, this is already happening server-side with SPF, DKIM, and DMAR=
C, just not in an end-to-end manner. Any emails coming from me, for example=
, are DMARC authenticated by Google. This is happening in a totally transpa=
rent manner without any additional &quot;gunk&quot; added to message bodies=
 (only to the headers).</div><div>=C2=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">In
    that case neither user would be aware of the key change.=C2=A0 Sure, in
    that case a user would be subject to a man in the middle &#39;attack&#3=
9;
    where such a middle man could pose as a previously known end user.=C2=
=A0
    That can be important in the 1% of cases where it&#39;s vital that a
    person or institution is bound to a message exchange.=C2=A0</div></bloc=
kquote><div><br></div><div>A system where any remote attacker can arbitrari=
ly change authentication keys without notifying the user doesn&#39;t sound =
like it offers any security at all.</div><div><br></div><div>There are syst=
ems that try to manage keys on a user&#39;s behalf, like CONIKS:</div><div>=
<br></div><div><a href=3D"http://www.coniks.org/our-solution/">http://www.c=
oniks.org/our-solution/</a><br></div><div><br></div><div>In a system like t=
his, a user authenticates to their provider and publishes a new key in thei=
r provider&#39;s CONIKS key directory. This directory maintains an append-o=
nly log of all key changes ala a Certificate Transparency log (authenticate=
d as a Merkle log proof).</div><div><br></div><div>The key directory can be=
 kept &quot;honest&quot; by auditor nodes which watch the directories looki=
ng for inconsistencies (and having clients check with auditors before using=
 a particular directory&#39;s keys), and/or by clients gossiping Merkle roo=
ts to each other.</div></div><div><br></div>-- <br><div class=3D"gmail_sign=
ature">Tony Arcieri<br></div>
</div></div>

--001a113f9b44b72b4e05299f914c--

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

--===============0932078930820178363==--