W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: breaking TLS (Was: Re: multiplexing -- don't do it)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 3 Apr 2012 02:34:06 +0200
Message-ID: <CABkgnnUfhbCrodXrUur1rtK8W0oM=rhM42ZeF=+VddLOVazrjQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "William Chan (ι™ˆζ™Ίζ˜Œ)" <willchan@chromium.org>, Mike Belshe <mike@belshe.com>, "Adrien W. de Croy" <adrien@qbik.com>, Peter Lepeska <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 3 April 2012 01:28, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> You really mean "prevent" there? POSTing a rot13 version of the
> corporate secret won't work?

I think that we should be clear in separating the _desire_ to do
something from the effectiveness of a particular measure in achieving
the (desired) end.

I've encountered a policy that blocked a popular online document
sharing/editing site.  Ostensibly, this was to prevent the leakage of
confidential information.  This particular measure was both more
effective in preventing real work than it was in its stated goal; more
convenient methods for disseminating secrets at the same time were
completely unaddressed.

That is, "the hole in the fence we can live with, but the tunneling
under the walls must stop!"

That does not mean that the specific policy rule was not considered
highly desirable by policy-makers.

I suspect that, at the root of all this, is a desperate attempt by
administrators to retain some sort of control.  The fact is that the
way that we communicate on the web is vastly more complex than their
policy engine is capable of managing.  Adding real time communications
only complicates that further.

The quick and easy solution to the realtime communications mess is
blocking UDP.  My guess is that this is what we'll get.  Controlling
this is going to be quite complex.  That said, with a lot of work, I
can see how sites might be selectively allowed onto a whitelist.

Received on Tuesday, 3 April 2012 00:34:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:59 UTC