Re: A proposal

On Mon, Nov 18, 2013 at 3:39 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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.
>

Alright, well thats all fine, but I really don't know why you're going off
on this rant.    Can you cite for me the specific quote from anyone on this
list who declared or implied that TLS was a comprehensive solution for
'security' or 'privacy'?  I don't think anyone did, so this rant is really
unnecessary.

The reason we're talking about TLS is because this is the HTTP team,
responsible for how the bits fly over the transport.  We can't control what
happens before or after that.  So the question that is before us is:  can
we make our piece more secure?  more protected against privacy leaks?  I
believe the answer is yes.

We know that cleartext is readable by all, so even rot-13, as you so
sarcastically put forth, would be an improvement.  But we can do a lot
better than rot-13 as well, with TLS.  TLS simultaneously addresses two key
points:  verification of identity of the server and establishing an
encrypted session.  We know that there are individuals siphoning off
packets from the routing infrastructure today.   It's just silly to argue
that TLS isn't substantially better than cleartext in this case.  Am I
saying it is impermeable?  No.  But a way more private and secure way to
transmit your bits.

Mike






>
> ....Roy
>
>