Re: A proposal

On Tue, Nov 19, 2013 at 12:43 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Nov 18, 2013, at 4:15 PM, Stephen Farrell wrote:
> > On 11/18/2013 11:39 PM, Roy T. Fielding wrote:
> >> 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 think you misunderstood what I said.  It isn't the system
> that has privacy (or not) -- it is the user of the system.
>
> If you want a deeper survey of privacy, look at
>
>   http://tools.ietf.org/html/rfc6973
>
> and its references.  Or spend two years arguing about what DNT: 1
> is supposed to do.
>
> I don't think security is less complicated than privacy.  It is just
> a little easier to talk about because security folks generally refer
> to something specific being secured.  As in, the dead-bolt secures
> the door.  We don't say the dead-bolt secures the house, since there
> are probably many other entrances to the houses, nor do we make
> judgement calls on whether being inside the house is secure
> (e.g., it's not when the house is on fire).  Privacy literature
> often does both.


Nobody here said that TLS was the one-true  deadbolt.


>
> When people talk about "levels of security" they are generally
> referring to strength (resistance to brute force attacks) or
> comprehensiveness (does it cover everything you want secured).
> But when the thing being secured is information, the result is
> mostly binary for the user: either the information is secure
> or somebody can see something that they shouldn't be able to see.
> Actually, I guess we could say that revealing only metadata about
> secured data is a sort of middle ground, but I digress ...
>

Again, nobody claimed that TLS would solve all levels of security that
anyone on this list can dream up.

The leap you're making is your conclusion that TLS is not useful as a
default option because it doesn't solve every level of security.



>
> People here talk about securing http because they assume that
> hiding the information exchanged is a useful act.  There are
> certainly cases where that is true, and for which we should
> recommend, or even insist on, the use of https (or some other
> secure transport).  For all of those cases, a user agent needs
> to verify that only the intended recipient can read the information,
> before the information is sent, which is why we have the https scheme.
>
> However, there are far more cases where encapsulating the entire
> message exchange in encryption will do nothing of value.  The

only "private" information being exposed in HTTP is the same
> information that is exposed by requesting DNS, making the connection,
> and reacting to the results.  Opportunistic encryption in those
> cases is both unwanted by the server and useless for the user.
>

Nonono - this is definitely not true.  Cookies contain orders of magnitude
more personal information than a DNS request generally does.

I'm not saying that DNS exposure isn't an issue, but just because we don't
solve it with TLS doesn't mean that TLS is bad.


> Furthermore, I have a hard time believing the privacy propaganda
> being spread by the browser makers.  If they want to improve
> privacy, all they have to do is remove the crappy features
> that cause their HTTP use to be insecure.  Stop blaming the
> protocols for exposing information that shouldn't be sent in
> the first place.
>

Patches are always welcome.  Sounds like you've got it all figured out.


>
> Don't allow cookies from a secure site to be sent to a non-secured site.

Double-key cookies so that they don't share information across multiple
> referring sites. Implement an obvious logout in the UI chrome.
> Don't send cached credentials if the referring document isn't trusted
> or same-origin.  Don't allow BASIC over an unsecured connection.
> Implement authentication schemes that don't expose the user's secret.
> Prevent extensions and scripts from mimicking authentication forms.
>

Well, cookies are part of HTTP, so....  But seriously, just encrypt the
session, and your cookies get a lot more manageable.  Nothing new needs to
be invented - we have this technology right now.

You're focusing on one level, and ignoring the very real, and now
documented threat of widespread and massive data theft at the internet
routing points.





> Those are just the easy fixes. Sure, some of those changes
> will fail to interop with some sites. Deal with it. That is a
> tiny price to pay when compared to insisting that all http
> traffic be encrypted.
>

Despite the grandstanding on here, we all know that TLS is relatively cheap
already and getting cheaper every day.  If we standardize around it, and
work on tools a little, it'll get even cheaper.  But I don't expect to get
agreement on this point.

One last thing I want to mention is that the downsides of using TLS are a
lot less than the downsides of not using TLS.

As we're all aware, there are about 200 countries on this planet.  Many of
the governments of these countries are using packet siphoning as a key
information gathering technique.  It's easy today.  They do this for many
protocols beyond just HTTP.  But what do they do with this information?  We
know the answer to this too - they are out to kill their dissidents.

So when we don't protect everything from generic siphoning, we are
facilitating murders and genocides.  Is this dramatic?  Yeah its dramatic.
 But is it untrue?  No.  I know the counter argument already!  You'll say
"but we already MITM!", and pretend that MITM is just as easy as siphoning
cleartext when we know that its not even close to the same thing. TLS does
make raw siphoning of packets orders of magnitude more expensive and
difficult to do.  Or you'll say "but DNS is exposed!", as though DNS were
on the same level as words and phrases that you communicate with other
people.  Or you'll say, "but SMTP is cleartext", as though we have to
secure every last possible door if we secure any of them... Sigh.

I am not sure what the next 10 years will bring.  But I am certain it will
bring many incidents where we'll be able to look back and say, "hmmm... if
we had put TLS in HTTP by default, that might not have happened."

People don't die because we did put in TLS.  They only die if we don't.

Dramatically yours,
Mike






>
> ....Roy
>
>