<div dir="ltr">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.<div><br></div><div><br></div><div>
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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So one conclusion about S/MIME and PGP is that they should support domain level confidentiality and confidentiality, not just account level. </div><div><br></div><div>Another conclusion is that end-to-end security is orthogonal to transport. In particular there are good use cases for the following configuration:</div>
<div><br></div><div>Mail sent from <a href="mailto:alice@example.com">alice@example.com</a> to <a href="mailto:bob@example.net">bob@example.net</a></div><div><br></div><div>* DKIM signature on message from <a href="http://example.com">example.com</a> as outbound MTA 'From'.</div>
<div><br></div><div>* S/MIME Signature on message from <a href="http://example.com">example.com</a> with embedded logotype information.<br></div><div><br></div><div>* TLS Transport Layer Security with Forward Secrecy to <a href="http://example.net">example.net</a> mail server using DNSSEC and DANE to authenticate the IP address and certificate.</div>
<div><br></div><div>* S/MIME encryption under <a href="http://example.net">example.net</a> EV certificate</div><div><br></div><div>* S/MIME encryption under <a href="mailto:bob@example.net">bob@example.net</a> personal certificate.</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 format deployment battle does not mean we are obliged to use the S/MIME PKI unmodified or require use of CA validated certificates.]<br clear="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-end', 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 available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. </div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>