Subject: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Jun 2016 13:21:12 -0400

I've posted a new document to the datatracker that adds some TLS alert
codes that can be sent to indicate that a particular TLS request has been
blocked by the network.   This attempts to address the problem of notifying
the user of what went wrong when a site is blocked, without creating a
channel that can be used by a hostile network to attack a user.

Feedback is solicited, naturally.

Thanks!

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Blocked Site Alerts for TLS
        Author          : Ted Lemon
        Filename        : draft-lemon-tls-blocking-alert-00.txt
        Pages           : 7
        Date            : 2016-06-06

Abstract:
   Hosts connecting to the Internet should generally be able to connect
   to all available services.  However, as a matter of policy, need or
   preference, some services may be blocked by the network.  TLS
   correctly treats attempts to communicate the reason for such blockage
   to the client as an attack.  This memo describes a safe way for hosts
   to be notified using the TLS alert mechanism that a connection has
   been blocked by the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 Jun 2016 11:55:50 +0200

On Monday 06 June 2016 13:21:12 Ted Lemon wrote:
> codes that can be sent to indicate that a particular TLS request has
> been blocked by the network.   This attempts to address the problem
> of notifying the user of what went wrong when a site is blocked,
> without creating a channel that can be used by a hostile network to
> attack a user.

why separate malicious_site and policy_violation? Why not provide just a 
single administratively_prohibited? I don't see a difference to the 
user, in both cases the site will remain unavailable when retrying 
connection and in both cases if the user thinks it's a mistake he or she 
will need to contact the network administrator.

I don't understand the account_attention_* alerts. What account does the 
user need to log in? In what scenarios would they be used? How is it 
different from the captive_portal?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Jun 2016 15:57:32 -0400

The point of the different result codes is to give the end-user some basis
for figuring out why they didn't get to the site.   "Malicious site" is
different than "policy violation."   A malicious site is a site that serves
malware, or does phishing, or typosquatting, or something like that.
Policy violation could be "no facebook during business hours."   Policies
are typically under user control, so being able to know that you can do
something to address the problem is key.

The difference between "captive portal" and "user needs to check account
status" is that in the one case, you have no (anticipated) business
relationship with the operator of the network, whereas in the case of
account status, you do.   Or in any case, the network is claiming you do.
So what the user would be expected to do is different--in the case of a
captive portal, they might have to use some out-of-band mechanism to
discover the URL they should visit to sign up, whereas in the case of a
relationship with an ISP, they already presumably know the ISP's web site,
and hopefully have a secure URL they can use to access it.

Of course we can't do anything about that, and there is some security
exposure in the case, for example, that they have an HTTP URL and an
attacker wants to trick them into using it.   Ideally the ISP would already
have asserted that it only is accessible through TLS, and the browser would
already have cached that.

---

From: Brian Smith <[email-masked]>
Date: Tue, 7 Jun 2016 09:55:58 -1000

> channel that can be used by a hostile network to attack a user.

This is a bad idea in general, and we shouldn't do things like this.

Standardizing and implementing things like this signals, politically, that
we accept and even encourage censorship like we see in China and many other
places already in the world. That, on its own, makes this a non-starter.

The inconvenience, confusion, and unreliability of current methods of (not)
notifying the user about the filtering is a strong disincentive towards
people thinking about deploying filtering that is abusive.

Perhaps there is some kind of filtering that isn't abusive, but IMO the
gain from improving that doesn't outweigh any loss, politically or
otherwise, from, intentionally or unintentionally supporting the abusive
filtering.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Jun 2016 16:17:01 -0400

Brian, I totally sympathize with that, but this isn't really the 451 use
case, much as it seems to resemble it.   In reality, there are actual risks
that people want to be protected from, and services that offer to protect
them from those risks.   Malware and phishing are obvious examples--older
folks with diminished capacity who aren't protected from phishing attacks
can lose everything, and malware is a serious problem.   Some families want
to protect their kids from contact with people they consider unsuitable,
and this is a reasonable thing for them to want to do.

It's also useful to be able to notify the end user when their connection is
in a state where they won't be able to get access, and there is something
they can do to change that.   The more web sites that are properly
protected by TLS, the harder it becomes to do this.   We can't offer
network operators, who are potentially attackers, a way to send content to
the user.   A result code with no operator-configurable content is a good
way out of that problem.

Furthermore, transparency is useful.   The IETF recently published an RFC
documenting the 451 result code precisely because it aids in transparency.
The IETF didn't signal, politically, that the IETF is in favor of
censorship.   When you get this result code, you know what happened.
That's important: if you don't know that your connection was censored, you
might think it's just a network problem, and not realize that you need to
take action at layer 9 to correct the problem.   These result codes
accomplish the same thing, in a finer-grained way, for TLS connections.

Current methods aren't at all unreliable.   It's no problem to block web
sites that fall into classes the end user wants blocked, or that are
blocked for policy reasons.   The problem is that we need to inform the end
user as to what happened.   Right now we have two options for doing that.
Either we require the user to install and trust a cert, or we require them
to click through security warnings.

Both of these options are extremely damaging from a security perspective.
End-to-end TLS encryption is really important for protecting sensitive
communication.   Trusting your ISP to MiTM your communication is a dumb
idea.   But ISPs won't have any trouble at all convincing users to do this.

Similarly, training your end users to click through invalid cert warnings
will also work.   But it's a terrible idea to solve the problem that way.

The point being that right now all the standards-compliant ways of being
transparent about this are bad from a security perspective.   I don't think
the IETF should take a position on whether this is a good idea, but if the
IETF consensus is not to add these result codes, I think that would be a
worse outcome than publishing them.

On Tue, Jun 7, 2016 at 3:55 PM, Brian Smith <[email-masked]> wrote:

> The inconvenience, confusion, and unreliability of current methods of
> (not) notifying the user about the filtering is a strong disincentive
> towards people thinking about deploying filtering that is abusive.
>

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jun 2016 17:28:34 -0400

> something to address the problem is key.

I think the problem that we would want to stress here is that there are far too many places where things that people just don't like get treated as "malicious" and policies are created to block them. The difference between the two is valid, but I have no faith whatsoever that people can really rely on them being properly labeled and communicated. As far as I'm concerned, the determination of explicit designation as malicious is up to the client and any sort of its _own_ content blocking, not anything on the network. As such, I feel like these two alerts can't safely be considered separate. One alert simply for all prohibited connections, without trying to explain human reasoning in one bit of information, would be preferable.

Likewise, I don't immediately see why captive portals are sufficiently different from the account attention requested/required cases to warrant separate designation. Upon reading the draft, my first impression is that a set of 3 codes (preferably named more akin to: network_prohibited_connection, network_account_reqested, network_account_required) instead of the current 5 would be more appropriate, and even then, the please/maybe/whatever nature of the second one seems a little odd to me. Just the two "nobody allowed ever" and "you're not allowed (yet)" alerts are the only ones I see particularly convincing justification for.

Dave