Re: A proposal

On Nov 17, 2013, at 3:40 PM, Mike Belshe wrote:
> On Sun, Nov 17, 2013 at 3:27 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> Security is a systemic issue, not a protocol issue.  There is nothing
> secure about TLS or encryption.  There are merely some use cases in
> which the data crossing the wire can be made confidential to a given
> set of key holders, preferably controlled by the entity to which the
> user intends to communicate in confidence.  That level of confidentiality
> is sufficient for many commerce use cases.  It does not provide privacy.
> 
> Anyone who thinks adding TLS to plain HTTP will improve security,
> let alone privacy, needs to learn how TLS gets its security.
> Encryption is not magic pixie dust.
> 
> So your official statement is that TLS does not improve the security or privacy of HTTP?

I don't make official statements.

rot13 improves privacy, if what you mean by "improve" is that there
exist some tools that do not currently read rotated clear text.
I don't think "improves privacy" is a useful description.
You either have privacy or you don't.

TLS provides security to the extent that it enables systems to be
constructed in a secure manner.  If we follow all of the best
practice, we can deploy a TLS exchange with the same level of
security as using a credit card in a branded establishment that
claims to obey PCI.  That's good enough *when* the user agent
is able to know the end-point of communication to which it wishes
to communicate securely.

TLS alone does not secure https interactions. TLS defines a protocol
for obtaining an authenticated certificate that can be verified to
match a given set of domains.  To the extent that such verification
can be trusted and the domain retains control over its private key,
the connection can be encrypted such that the bytes on the wire
after the key exchange are only visible to the user agent, the
server that decrypts that connection, any observer on either side
of that connection that can see the plain text before encryption
or after decryption, and anyone else with the server's key.

This does not secure the DNS requests that led to obtaining an IP
address, any potentially associated key verification requests, the
destination IP address, and the pattern of subrequests that immediately
follows as a result of the https request.  Each of these is sufficient
to identify what site is being accessed by the user, with the latter
usually being sufficient to identify which common resource is accessed.
They can be seen using the same protocol analyzers that one can see
plain text HTTP/1.1.

Hence, TLS does not provide privacy.  What can be done to provide a
degree of privacy is to route all requests through an encrypted
channel to a trusted intermediary that is shared by enough people
such that it masks *where* the requests are being directed.
That is providing privacy.

Almost all Web sites that use TLS today do so to encrypt the
exchange of user authentication.  User authentication is the
opposite of providing privacy.

In Vancouver, there was a discussion of opportunistic encryption
without server authentication, described as a means of "improving
privacy".  The only way that I can interpret that claim is that
folks don't understand privacy.  If we pretend for a minute that
they aren't just rabble-rousing and actually mean protecting the
confidentiality of user authentication tokens, then using
unauthenticated server certificates is the wrong approach.

This is not an argument against securing Web traffic for the
sake of privacy. It is an argument against window-washing the
subject by applying the wrong tools to the wrong problems.
Go ahead and encourage websites that have user accounts to make
use of https URIs and stay within an encrypted and multiplexed
session, but don't call that privacy.  It is the authenticated
server certificate that provides security of credentials and
the sent message data, which is worthwhile in itself without
mislabeling it as privacy.

If you want privacy against widespread surveillance, then you
need to approach that separately, as a systemic issue involving
all of the network requests and how they are routed, or as a
policy issue that is outside the IETF's scope.

....Roy