[147158] in cryptography@c2.net mail archive
[Cryptography] End to end
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Sep 16 14:23:54 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 16 Sep 2013 13:49:55 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3212193700116697328==
Content-Type: multipart/alternative; boundary=001a11c3fba2fe836204e683d445
--001a11c3fba2fe836204e683d445
Content-Type: text/plain; charset=ISO-8859-1
Just writing document two in the PRISM-Proof series. I probably have to
change the name before November. Thinking about 'Privacy Protected' which
has the same initials.
People talk about end-to-end without talking about what they are. In most
cases at least one end is a person or an organization, not a machine. So
when we look at the security of the whole system people security issues
like the fact they forget private key passphrases and lose machines matter.
Which ends you are talking about depends on what the context is. If we are
talking about message formats then the ends are machines. If we are talking
about trust then the ends are people and organizations.
End to end has a lot of costs. Deploying certificates to end users is
expensive in an enterprise and often unnecessary. If people are sending
email through the corporate email system then in many cases the corporation
has a need/right to see what they are sending/receiving.
So one conclusion about S/MIME and PGP is that they should support domain
level confidentiality and confidentiality, not just account level.
Another conclusion is that end-to-end security is orthogonal to transport.
In particular there are good use cases for the following configuration:
Mail sent from alice@example.com to bob@example.net
* DKIM signature on message from example.com as outbound MTA 'From'.
* S/MIME Signature on message from example.com with embedded logotype
information.
* TLS Transport Layer Security with Forward Secrecy to example.net mail
server using DNSSEC and DANE to authenticate the IP address and certificate.
* S/MIME encryption under example.net EV certificate
* S/MIME encryption under bob@example.net personal certificate.
[Hold onto flames about key validation and web of trust for the time being.
Accepting the fact that S/MIME has won the message format deployment battle
does not mean we are obliged to use the S/MIME PKI unmodified or require
use of CA validated certificates.]
Looking at the Certificate Transparency work, I see a big problem with
getting the transparency to be 'end-to-end', particularly with Google's
insistence on no side channels and ultra-low latency.
To me the important thing about transparency is that it is possible for
anyone to audit the key signing process from publicly available
information. Doing the audit at the relying party end prior to every
reliance seems a lower priority.
In particular, there are some type of audit that I don't think it is
feasible to do in the endpoint. The validity of a CT audit is only as good
as your newest notary timestamp value. It is really hard to guarantee that
the endpoint is not being spoofed by a PRISM capable adversary without
going to techniques like quorate checking which I think are completely
practical in a specialized tracker but impractical to do in an iPhone or
any other device likely to spend much time turned off or otherwise
disconnected from the network.
--
Website: http://hallambaker.com/
--001a11c3fba2fe836204e683d445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just writing document two in the PRISM-Proof series. I pro=
bably have to change the name before November. Thinking about 'Privacy =
Protected' which has the same initials.<div><br></div><div><br></div><d=
iv>
People talk about end-to-end without talking about what they are. In most c=
ases at least one end is a person or an organization, not a machine. So whe=
n we look at the security of the whole system people security issues like t=
he fact they forget private key passphrases and lose machines matter.</div>
<div><br></div><div>Which ends you are talking about depends on what the co=
ntext is. If we are talking about message formats then the ends are machine=
s. If we are talking about trust then the ends are people and organizations=
.</div>
<div><br></div><div>End to end has a lot of costs. Deploying certificates t=
o end users is expensive in an enterprise and often unnecessary. If people =
are sending email through the corporate email system then in many cases the=
corporation has a need/right to see what they are sending/receiving.</div>
<div><br></div><div>So one conclusion about S/MIME and PGP is that they sho=
uld support domain level confidentiality and confidentiality, not just acco=
unt level.=A0</div><div><br></div><div>Another conclusion is that end-to-en=
d security is orthogonal to transport. In particular there are good use cas=
es for the following configuration:</div>
<div><br></div><div>Mail sent from <a href=3D"mailto:alice@example.com">ali=
ce@example.com</a> to <a href=3D"mailto:bob@example.net">bob@example.net</a=
></div><div><br></div><div>* DKIM signature on message from <a href=3D"http=
://example.com">example.com</a> as outbound MTA 'From'.</div>
<div><br></div><div>* S/MIME Signature on message from <a href=3D"http://ex=
ample.com">example.com</a> with embedded logotype information.<br></div><di=
v><br></div><div>* TLS Transport Layer Security with Forward Secrecy to <a =
href=3D"http://example.net">example.net</a> mail server using DNSSEC and DA=
NE to authenticate the IP address and certificate.</div>
<div><br></div><div>* S/MIME encryption under <a href=3D"http://example.net=
">example.net</a> EV certificate</div><div><br></div><div>* S/MIME encrypti=
on under <a href=3D"mailto:bob@example.net">bob@example.net</a> personal ce=
rtificate.</div>
<div><br></div><div>[Hold onto flames about key validation and web of trust=
for the time being. Accepting the fact that S/MIME has won the message for=
mat deployment battle does not mean we are obliged to use the S/MIME PKI un=
modified or require use of CA validated certificates.]<br clear=3D"all">
<div><br></div><div><br></div><div>Looking at the Certificate Transparency =
work, I see a big problem with getting the transparency to be 'end-to-e=
nd', particularly with Google's insistence on no side channels and =
ultra-low latency.</div>
<div><br></div><div>To me the important thing about transparency is that it=
is possible for anyone to audit the key signing process from publicly avai=
lable information. Doing the audit at the relying party end prior to every =
reliance seems a lower priority.=A0</div>
<div><br></div><div>In particular, there are some type of audit that I don&=
#39;t think it is feasible to do in the endpoint. The validity of a CT audi=
t is only as good as your newest notary timestamp value. It is really hard =
to guarantee that the endpoint is not being spoofed by a PRISM capable adve=
rsary without going to techniques like quorate checking which I think are c=
ompletely practical in a specialized tracker but impractical to do in an iP=
hone or any other device likely to spend much time turned off or otherwise =
disconnected from the network.</div>
<div><br></div><div><br></div><div><br></div>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c3fba2fe836204e683d445--
--===============3212193700116697328==
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
--===============3212193700116697328==--
