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

Ted Lemon <mellon@fugue.com> Tue, 07 June 2016 19:58 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 0A89A12D1E7 for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 12:58:16 -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 0SZiXZdX3vWe for <tls@ietfa.amsl.com>; Tue, 7 Jun 2016 12:58:14 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 2E08C12D0A8 for <tls@ietf.org>; Tue, 7 Jun 2016 12:58:14 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id u74so15259141lff.2 for <tls@ietf.org>; Tue, 07 Jun 2016 12:58:13 -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=zPHJKnF0g3i2uAndKFjCQdtGyDtTYFms88SWtozbFTc=; b=Ph+0IWY1We5ar6zNfwE27DK/8Zj4///vrbwZCMTt5zKiMeXn9jwxKVklZAm5PRqZqO G3ao2xpokmOiowN7bG+UsYScpvkVra8K9tLXZo2Usns7TjPdLtNmGIcCOg7Kqqo+QOP0 HazqnjFlq6mn0zSQ8hpIbHlzshEeGSusOtpgYWSVBCZujzwO6WaPq2G6OixMvM5N/ioi Bb60vQwV3YiR0lr0BLmDq/Evp7P7vioiS3ZLQSTbsxyR6rN/d7ortn/BqSCCTYCrn5WL q0gN89Hoq+rH+hdwrZgC0q8FtVAFEKcwBfiFlQR96iaxv6FKyr/xpqEWMV3x4hS+7/9D dY8w==
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=zPHJKnF0g3i2uAndKFjCQdtGyDtTYFms88SWtozbFTc=; b=iXA//aZDTvihzyz+LCG2eKtt8h0c62cwRU8wa9SR7zO/6emp57TXKcOqebTXrZylJ/ cRtIoXr+gqOM78o+BKB2fn8j1oe/ROtDzyx72ueWy1W+W9obLHOp8RHqUiqRh24l2I3s kAHkaj4s9S4wLFB1hTZexgJPkE4B5LkDX5JbqOCQJK2pX6GDaiUj9qNGkdz/tqxx9W8H UUJSJoNHLGhkMG5/z82Rm+U4BYwEckku1mrxJLH/8GFafXL7E8tpm5B39gncuJFeGpK0 Ki4O1LFmS4DsynaOANInPzZ9RrYhoEEkZxzysK5NI/Jm6FEMo3hmUU4WqKMDxoiRL9U5 o6Nw==
X-Gm-Message-State: ALyK8tL7aLoH89wuTmZM3HpEE9InV13McYEDQlwBbGONRlX3eEAmV6UiwGic5wUohdvf2gHiTRSG0RIYWYn+Fw==
X-Received: by 10.25.142.16 with SMTP id q16mr2821917lfd.53.1465329492054; Tue, 07 Jun 2016 12:58:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.153.135 with HTTP; Tue, 7 Jun 2016 12:57:32 -0700 (PDT)
In-Reply-To: <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com>
References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> <CAPt1N1=YRyfmWDFxNHTj6Kb+mVf4w=sqt2Wp_i-gzp03+UjGqw@mail.gmail.com> <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 7 Jun 2016 15:57:32 -0400
Message-ID: <CAPt1N1m7UUAERkLFc=p1wA-PWdkkfL7CThUhkKnQzWW9Dd2cQw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary=001a11401682da63800534b59bf7
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2ypu2DEIAlTAoSJ6rMkGPg1LhzY>
Cc: 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 19:58:16 -0000

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.

On Tue, Jun 7, 2016 at 5:55 AM, Hubert Kario <hkario@redhat.com>; wrote:

> On Monday 06 June 2016 13:21:12 Ted Lemon 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.
>
> 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