Re: [TLS] Captive portals, "access administratively disabled" and alert messages

Martin Thomson <> Tue, 02 January 2018 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8217812D851 for <>; Tue, 2 Jan 2018 13:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wHuQF36CEVFT for <>; Tue, 2 Jan 2018 13:56:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D14012D852 for <>; Tue, 2 Jan 2018 13:56:13 -0800 (PST)
Received: by with SMTP id o64so34106385oia.9 for <>; Tue, 02 Jan 2018 13:56:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eT9kOS+BHwXqP1lSTJKUneBIT0TvCPhdx8jIGE5be/4=; b=jbkUKTzcrCceinrUIfu5uUC3ycX6GQ8F3zhmpat3kFRFlANiDW6b6AjU6TbTVHh95M p91LCTY8ZuKUgo8+Hv17BPThubwunaeGlEQR6SUhnvW9I1LZ9GRpGkgO5c4OoQSdlzZZ 7LVD31f2m2GkRc5H27bk5YQcm9tlPwna4Qto9tZHClIHuxEv3S4qxkg8FwSBJ/QvqgVN Z+ZGKxYB3EF4SNFMympDnWwpnu9sqKIkk1rhUTpRN1NSWsR4+kBBm1G5MEGd/scc1k22 9oPegTGiK0ULFYaDcO532P3exC/9gP1OlFKbuGMiYzotpeWOccTZVc3MkZ3PVF1XZsYj oiSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eT9kOS+BHwXqP1lSTJKUneBIT0TvCPhdx8jIGE5be/4=; b=nTULIwRlB89CQAlinIbp/n70yF6nf+RaF3n+cuN0hcfjK5k44cNN1jjq/FpkFI5Gn3 f2TXB44yOc/NgrHEfK/BSk64LaZRyxzx9DRbeDwneff9Ns9NY+gkMqWpXAanshe815sT sSKQGhZke1nQ41Jfu8x2yc6APWpPaf1QMOTikgXoT6JI5HhL6jPhnsvnWT3Xf2/ZVT+g apOkldMv7SM/f5iGOrdemq9zAz1QICjRTNpL3dJcSEWaL4Thg2TwHwlu/nPGKHBgQun0 aMs1sSpV7gCp4l8LMoobyU3Q56qvkK1/EYhkAA0Qy9cBwC27avEG58K7TBAmoL3ZNw2M /mEw==
X-Gm-Message-State: AKGB3mKuTOWuUhmiXpIZ/PhKmF0AR0pPvfzTk1u7wro/PqEHrTwFjeHD 4xEtdJkYFH2+6iUXuXXUdIxfoONJCmyqkwUg/nk=
X-Google-Smtp-Source: ACJfBotm7Nt3N0VjgYVy2yzMWhXgqLrABhGtJ0Gg6KA2DttogJqI2yWDv9reujisA2t4SU1XAKotMJ6nf7+8mdcIOOo=
X-Received: by with SMTP id w8mr31368569oiw.284.1514930172426; Tue, 02 Jan 2018 13:56:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Jan 2018 13:56:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Martin Thomson <>
Date: Wed, 3 Jan 2018 08:56:11 +1100
Message-ID: <>
To: Stephen Farrell <>
Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <>, Eric Rescorla <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jan 2018 21:56:17 -0000

On Wed, Jan 3, 2018 at 7:18 AM, Stephen Farrell
<> wrote:
> [...] the capport wg - I'd guess folks
> there are more aware of the full range of cases that may need
> handling and of how to try interpose the portal web page stuff
> before other applications see the n/w as active (or whatever it
> is they're doing with HTTP:-).

As chair of capport, this is definitely something for that group.  The
current approach we are taking there avoids having user equipment
attempt to connect to anything at all, which avoids this class of
problem.  If you look at modern devices, they all probe a network
before making the interface available to applications, and most of
what we would be doing exists at that probing phase.

We are additionally considering a network-based signal for those cases
where the attempt is made anyway, but I don't think that is firm yet.

Captive portal cases are separate to those related to selective
blocking of names or destinations, which is essentially a censorship
mechanism.  We've been careful to avoid creating mechanisms to support
that sort of discrimination.