Re: A proposal

Roy,

One request for clarification below:

On 11/18/2013 11:39 PM, Roy T. Fielding 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.

Security is less complicated than privacy and is definitely
not a binary property. Privacy is at this point far less
well defined, so I find the last statement above quite hard
to accept. (In fact, I find it unbelievable.) However, privacy
is so ill-defined that its possible you're using some
definition that does support such a binary distinction. FWIW,
I'd be hugely surprised if there were a useful definition in
which privacy was a binary property of systems.

I suspect there's not much point in a blow by blow response
if it turns out our terminology is miles apart in that
respect, so can you provide or point at your definition of
privacy such that its a binary property of systems?

Thanks,
S.

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

Received on Tuesday, 19 November 2013 00:15:38 UTC