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

Ted Lemon <mellon@fugue.com> Tue, 07 June 2016 20:17 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BFF12D550 for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 13:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnWz4gYHTHud for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 13:17:44 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA5D12B026 for <tls@ietf.org>; Tue, 7 Jun 2016 13:17:43 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id u74so15574954lff.2 for <tls@ietf.org>; Tue, 07 Jun 2016 13:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HaWhZ7Xhcqu2KfVAatgdwTL0jLC4xs34+LDCoWmhAB8=; b=sKVpjl9Eu3trgOXqwXd5rozdlPHbsCUJCTOsGuQ/Z3MyZbnVWUijPfKtFM0a0pGWlU oqHCRHxq1Z1risKMXAzpv7fFoRvlpqFEYCUWMAKVmHoGYV74GZjlZPOE4e+NvU3iIKwt HxsGsSHRQyk0qp9E9OoLZcVOTCGIg8hGJJ4QnthruWiAHOhxo/dSGQv5Ky0vMCq2/Gl+ Db7z7UnUiCuq1S3eFedcLmrRBsirSwCyZLL/VsvHlrXlEOnch0wMTFb2+VzI0ZbglcZL nxD3JOT/4a6Y5M+2n1CxG7GxjrK0RK5cLikQPj+CFqWHRTvwL9+xBCfbMKuKirlDMmly Ls1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HaWhZ7Xhcqu2KfVAatgdwTL0jLC4xs34+LDCoWmhAB8=; b=f+TfSe/C0xopsMUYtVKuxRiziqOZ7q5qnZPo2g8uK87QP8cncAepg4RMgUTWSSXZns 7iLF8xQFLOscLP0mwWtZ4wVezUJGVvkuR5gR7RECJ1P6TwCf8xQE0Y7BOefhiTXzAfe4 +kPIQpQNpTNxTp7SXBFEoClzC2yC/0S/RMR1goPqxu8FeScNfL+oez6vtjZDKAqFjOc9 7RuZTRReP6QFztDbzgHQ+dlCVmq2cSO63yBD8U5DQDj8rmsQbcpojML5I5xqfNO5YTDO Y4ftzM0x9tLkLF31p/RW9Q1obpgsRFgjsBwWMBco/AZII8CQYpPfZCOMiOu/P8oL3sFI lwKQ==
X-Gm-Message-State: ALyK8tINk1AWdZ0NFV65HVptUTKKjHy/yUoT49P5tLJmznZdKjAfif1N586JosUoWAeIGrDKYdMPVSFPhJezJA==
X-Received: by 10.25.142.16 with SMTP id q16mr2837704lfd.53.1465330661461; Tue, 07 Jun 2016 13:17:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.153.135 with HTTP; Tue, 7 Jun 2016 13:17:01 -0700 (PDT)
In-Reply-To: <CAFewVt4DHa_jmGaDhT4sm+12MVEV=5qSktpNAiS=_T2PMDyHzQ@mail.gmail.com>
References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> <CAPt1N1=YRyfmWDFxNHTj6Kb+mVf4w=sqt2Wp_i-gzp03+UjGqw@mail.gmail.com> <CAFewVt4DHa_jmGaDhT4sm+12MVEV=5qSktpNAiS=_T2PMDyHzQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 7 Jun 2016 16:17:01 -0400
Message-ID: <CAPt1N1=9nacaiO+=8HKgbyVKbHXEfacTd7vEwaXWzFPv6m7vAQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=001a114016828e1cfc0534b5e1be
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/owyrXyDy3gAu-zYKJgJoE0IoChg>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2016 20:17:46 -0000

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 <brian@briansmith.org>; wrote:

> On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon <mellon@fugue.com>; 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/
>
>