[148488] in cryptography@c2.net mail archive
Re: [Cryptography] The next generation secure email solution
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Tue Dec 17 13:48:36 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <201312170629.rBH6TUtl028402@new.toad.com>
Date: Tue, 17 Dec 2013 11:46:56 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Gilmore <gnu@toad.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
"James A. Donald" <jamesd@echeque.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2129428493460942895==
Content-Type: multipart/alternative; boundary=e89a8f3bafef3650b704edbdadc9
--e89a8f3bafef3650b704edbdadc9
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 17, 2013 at 1:29 AM, John Gilmore <gnu@toad.com> wrote:
> > Need a system for handing one's keys around that protects end users from
> > the horrifying sight of actual keys or actual strong hashes of keys.
>
> But at the same time the system has to not say, "I can't deliver your
> message to that person because an invisible gnotzaframmit that I won't
> describe to you seems to be unavailable to me in the flabogrommit."
>
There are different use cases that need to be solved.
How much security we provide is going to be limited by the amount of effort
a user can or will put in.
Trust infrastructure is an obvious potential point of failure. But in the
real world none of the models that are used has a significant failure rate.
I can even pick up a key from a PGP server that does nothing to
authenticate the published keys and it is most probably the right one.
So while developing a better trust infrastructure that offers more security
and is easier to use is certainly a worthwhile goal, it is much better for
people to use any of the existing end-to-end email schemes with their
possible flaws than to send the message without encryption.
If everyone was using strong end to end encryption and we discovered that
the trust model was being exploited then we could fix the trust model much
more easily than the problem we currently face which is getting people to
use strong crypto at all.
I don't specify what the trust infrastructure is or how it works in PPE. I
have a proposal that merges OpenPGP and S/MIME but other people might have
other ideas. And even if my proposal was right for 99% of users, the
remaining 1% might have a different set of requirements.
In PPE I have three types of email address:
Mail with the to address alice@example.com will be encrypted on an
opportunistic basis. That is, it will only be sent encrypted if the trust
infrastructure returns an assertion bound to that address that says '
alice@example.com prefers email encrypted under key X'.
Mail with the to address ?alice@example.com will only be sent if it can be
sent with end-to-end encryption with a key that meets the sender's trust
criteria.
Mail with the to address
AALNAT-USYLKI-WT5OKIK-QFPDQ2-PDA@alice.example.comwill only be set if
the senders trust criteria and the criteria specified
by an email sending policy signed by a key authenticated under the
specified hash are both met.
The first two approaches are easy to use but require reliance on a trust
infrastructure. The last is a direct trust model that does not require any
third party to be trusted.
We can certainly get a lot of users using the first approach because they
don't even need to know that they are using it. I think we can even get
people to use the third if it is sufficiently sugar coated.
The gap between strong email addresses and using a regular email address
plus a PGP fingerprint might seem small but so are the differences in
usability between Windows CE, PalmOS and the iPhone 1.
Combining the fingerprint into the address makes it possible to exchange a
strong email address in (almost) every venue that supports regular emails.
--
Website: http://hallambaker.com/
--e89a8f3bafef3650b704edbdadc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Dec 17, 2013 at 1:29 AM, John Gilmore <span dir=3D"ltr"><=
;<a href=3D"mailto:gnu@toad.com" target=3D"_blank">gnu@toad.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">> Need a system for handing one's=
keys around that protects end users from<br>
> the horrifying sight of actual keys or actual strong hashes of keys.<b=
r>
<br>
</div>But at the same time the system has to not say, "I can't del=
iver your<br>
message to that person because an invisible gnotzaframmit that I won't<=
br>
describe to you seems to be unavailable to me in the flabogrommit."<br=
></blockquote><div><br></div><div>There are different use cases that need t=
o be solved.</div><div><br></div><div>How much security we provide is going=
to be limited by the amount of effort a user can or will put in.=A0</div>
<div><br></div><div>Trust infrastructure is an obvious potential point of f=
ailure. But in the real world none of the models that are used has a signif=
icant failure rate. I can even pick up a key from a PGP server that does no=
thing to authenticate the published keys and it is most probably the right =
one.</div>
<div><br></div><div><br></div><div>So while developing a better trust infra=
structure that offers more security and is easier to use is certainly a wor=
thwhile goal, it is much better for people to use any of the existing end-t=
o-end email schemes with their possible flaws than to send the message with=
out encryption.</div>
<div><br></div><div>If everyone was using strong end to end encryption and =
we discovered that the trust model was being exploited then we could fix th=
e trust model much more easily than the problem we currently face which is =
getting people to use strong crypto at all.</div>
<div><br></div><div>I don't specify what the trust infrastructure is or=
how it works in PPE. I have a proposal that merges OpenPGP and S/MIME but =
other people might have other ideas. And even if my proposal was right for =
99% of users, the remaining 1% might have a different set of requirements.<=
br>
</div><div><br></div><div><br></div><div>In PPE I have three types of email=
address:</div><div><br></div><div>Mail with the to address <a href=3D"mail=
to:alice@example.com">alice@example.com</a> will be encrypted on an opportu=
nistic basis. That is, it will only be sent encrypted if the trust infrastr=
ucture returns an assertion bound to that address that says '<a href=3D=
"mailto:alice@example.com">alice@example.com</a> prefers email encrypted un=
der key X'.</div>
<div><br></div><div>Mail with the to address ?<a href=3D"mailto:alice@examp=
le.com">alice@example.com</a> will only be sent if it can be sent with end-=
to-end encryption with a key that meets the sender's trust criteria.</d=
iv>
<div><br></div><div>Mail with the to address <a href=3D"mailto:AALNAT-USYLK=
I-WT5OKIK-QFPDQ2-PDA@alice.example.com">AALNAT-USYLKI-WT5OKIK-QFPDQ2-PDA@al=
ice.example.com</a> will only be set if the senders trust criteria and the =
criteria specified by an email sending policy signed by a key authenticated=
under the specified hash are both met.</div>
<div><br></div><div><br></div><div>The first two approaches are easy to use=
but require reliance on a trust infrastructure. The last is a direct trust=
model that does not require any third party to be trusted.</div><div><br>
</div><div>We can certainly get a lot of users using the first approach bec=
ause they don't even need to know that they are using it. I think we ca=
n even get people to use the third if it is sufficiently sugar coated.</div=
>
<div><br></div><div>The gap between strong email addresses and using a regu=
lar email address plus a PGP fingerprint might seem small but so are the di=
fferences in usability between Windows CE, PalmOS and the iPhone 1.</div>
<div><br></div><div>Combining the fingerprint into the address makes it pos=
sible to exchange a strong email address in (almost) every venue that suppo=
rts regular emails.</div><div><br></div><div><br></div></div>-- <br>Website=
: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--e89a8f3bafef3650b704edbdadc9--
--===============2129428493460942895==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2129428493460942895==--
