Re: A proposal

On Nov 19, 2013, at 2:28 AM, Mike Belshe wrote:
> On Tue, Nov 19, 2013 at 12:43 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> 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.

No.  Almost every post you make to this list starts with a disclaimer
of broad applicability and then finishes with an even broader claim
about what mandatory TLS will do for the people.  It is tiresome.

What I explained is that the privacy being leaked by plain text HTTP
(that doesn't contain personal data) is not significantly different
from the privacy leaked just by making direct connections to end-points.
What you don't grasp is that most true privacy protection products
work by hiding those direct connections.  There is a reason for that.

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

No, it just means that we haven't solved the problem by mandating
TLS.  Maybe directly solving the problem would be better then
causing the entire world to change with little effect.

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

Not by my hand.

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

Yeah, like I said ... why should browsers fix actual security holes
when they can insist that everyone else deploy TLS?  Only two of
the above above well-known bugs in browser design, that browsers
claim they cannot possibly fix (because they will lose market share),
would be fixed (indirectly) by sending everything under TLS.

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

No.  I said don't send the data in plain text if it isn't public.
They can't steal it if the data isn't sent.  If you are sending
personal data, use https links, or other protocols that are
equally secure.

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

You don't need agreement on that point.  It has nothing whatsoever
to do with mandating encryption of HTTP/2.  Regardless of what social
requirements we might invent, a considerable number of sites require
strongly authenticated connections, and improving the responsiveness
of those connections should be a priority to everyone.  That doesn't
mean it depends on HTTP/2, in any way, shape, or form.

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

The immediate downsides of requiring TLS are that it increases the
minimum round trips, the amount of packets needed to send the
same information, and the availability of shared caching.
In other words, it impacts latency and bandwidth, particularly
across shared links (like cross-ocean fiber), for the transfer
of public information.  Primarily, videos of cats.

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

Umm, no, they use metadata correlation with public postings, which
Google/Facebook/Twitter search and Telco records can provide far
easier than packet siphoning. Few can afford an NSA.

The defense against both is routing activity through anonymizing
services and identities that can't be traced back to a single user agent,
which is something that typical end-to-end TLS actively works against.

I find it painful to watch IETFers feign shock and dismay over
"new" surveillance techniques when those same techniques have
been portrayed in almost every Hollywood movie about the Internet,
for the past fifteen years.  "Enemy of the State" was released in
1998, for crying out loud.


The question at hand is not whether people should use TLS for
securing connections to authenticated services that publish a
verifiable certificate.  The question is whether anyone is *allowed*
to use HTTP/2 while not on a secured connection.  To the extent we
believe such a social requirement would be obeyed in practice,
what effect would it have on adoption of HTTP/2, and on the
Internet as a system?

Regardless, this question doesn't prevent sites from offering
TLS-secured services and providing certificates for that purpose.
I do not need an IETF mandate to use those services because the
site owners were convinced to offer https-only interfaces, and
the reason they were convinced is because the data that they
contain (like social graphs and posting history) is personal.
Education works, particularly when it is backed by regulators and laws.

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

Absolutely nothing has been revealed in the last 2 years that
wasn't already known during the discussion of SHTTP in 1994.
AFAICT, the only things that have changed are the amount of information,
the rate at which it is sent, the degree of public access to the
Internet, and the overwhelming demand to share too much on social
networks.

Encrypting the channel does not secure the end points.  It certainly
doesn't hide the parties communicating.  Encrypting the message
can allow it to be broadcasted and routed via mechanisms independent
of the original sender.  That can (at least conceptually) anonymize
the sender, but then a few annoying people take advantage of that
feature and abuse the entire commons, such that services need to
add identity requirements just to stay alive, and we are back to
square one.

There are anonymizing services that work.  TLS is not one of them,
though it can certainly be used by them for at least part of the
interaction.  Mail delivery via TLS (along the entire route) makes
sense because all mail messages contain personal data, even spam.
HTTP via TLS isn't necessary because https is always an option.
If you need a header to indicate that, use

   Link: <https://secure.example.com/>; rel="alternate"


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

*sigh*

I seriously doubt that you have thought through the technical impact
of mandating TLS, let alone understood what effect it would have on
people who depend on anonymity.  What do you think happens when a
user agent is forced to communicate directly to a centralized service
instead of through an intermediary?  What effect does an increase in
round-trip latency, resulting in the desire for maintaining
longer-lived connections and additional state on the client, have
on the ability to identify individual users.  To what degree will
forcing the use of TLS cause sites to mandate user accounts, just
because it is only marginally more disruptive and enables the
provision of more customized user experiences?  How does the
reduced availability of decentrally cached public copies make
it easier to track individual access to that information?

I don't know those answers.  I'd rather let the individuals who
are actually impacted decide, for themselves, which services to use,
and how they wish to use them.

....Roy