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

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:

> On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon <[e-mail]> wrote:
>
>> 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.
>>
>
> 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/
>
>