Re: [TLS] access_administratively_disabled v2

Mateusz Jończyk <> Thu, 04 January 2018 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DD07127AD4 for <>; Thu, 4 Jan 2018 08:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F3Yo0VFFGFUj for <>; Thu, 4 Jan 2018 08:39:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B491126B7F for <>; Thu, 4 Jan 2018 08:39:10 -0800 (PST)
Received: (wp-smtpd 14571 invoked from network); 4 Jan 2018 17:39:08 +0100
Received: from (HELO []) ([]) (envelope-sender <>) by (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for <>; 4 Jan 2018 17:39:08 +0100
To: Stephen Farrell <>, Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <>
Cc: "<>" <>
From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <>
Message-ID: <>
Date: Thu, 4 Jan 2018 17:39:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-WP-MailID: d07ff0efae169d6d2220381975234699
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 000000A [4YMk]
Archived-At: <>
Subject: Re: [TLS] access_administratively_disabled v2
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: Thu, 04 Jan 2018 16:39:12 -0000

Hash: SHA1

W dniu 04.01.2018 o 16:52, Stephen Farrell pisze:
> I'm fairly sure I'm against attempting to handle captive portal issues at
> the TLS layer. Any changes to TLS needed for captive portals ought really
> garner consensus within the capport wg and then be discussed here. (It
> looks from the archive of that wg that this topic hasn't even been raised
> there despite a few people suggesting that, which is IMO another reason to
> reject this proposal now.)

Captive portals != filtering, these are AFAIK different problems and need
mostly different solutions. I just integrated them under the same umbrella
because they initially both used to seem to benefit from adding alert messages
to TLS (but that idea is dead now).

I am not certain whether adding captive_portal AlertDescription to TLS would
be of benefit. It seems to me that possibly yes, but haven't reviewed this.

> I don't find the more-transparent-censorship argument offered convincing. 
> If DNS-based censorship is offered as the motivation (as opposed to or in
> addition to captive portals) then I think that'd require chatting with the 
> dnsop folks, who are already discussing DNS-RPZ.

Thanks for mentioning DNS-RPZ, I wasn't aware of it.

It isn't only about DNS-based filtering, but also about blocking access to
specific IPs:

	iptables -t nat -A OUTPUT --destination			\
		--jump DNAT --to-destination banned-page-server.local

as well as filtering packets on the HTTPS layer without MITM (the dreaded

> I'd guess, (but not sure as it's not my fav. idea;-), that might throw up a
> requirement that censorship might only be done for a few minutes while some
> previously unseen name was checked out, or a name might be censored for
> days or weeks, if it's newly registered and some censor considers that a
> threat.
I was thinking more about filtering for sex, obscenity and such. That was my
primary motivation when pushing for access_administratively_disabled.

> IOW, if any changes to TLS are warranted based on DNS-based censorship,
> then those are likely more complex than has been seen in this discussion,
> and also aren't things where this list has the right expertise AFAIK.
> S.

Mateusz Jończyk
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: My public key: 0x2C64C488 on hkp://
Comment: Using GnuPG with Thunderbird -