[Cryptography] End to end

Phillip Hallam-Baker hallam at gmail.com
Mon Sep 16 13:49:55 EDT 2013


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 at example.com to bob at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130916/97591491/attachment.html>


More information about the cryptography mailing list