Re: [TLS] access_administratively_disabled v2

Mateusz Jończyk <mat.jonczyk@o2.pl> Thu, 04 January 2018 16:39 UTC

Return-Path: <mat.jonczyk@o2.pl>
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 6DD07127AD4 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 08:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Yo0VFFGFUj for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 08:39:10 -0800 (PST)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B491126B7F for <tls@ietf.org>; Thu, 4 Jan 2018 08:39:10 -0800 (PST)
Received: (wp-smtpd smtp.tlen.pl 14571 invoked from network); 4 Jan 2018 17:39:08 +0100
Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for <tls@ietf.org>; 4 Jan 2018 17:39:08 +0100
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>
References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <CABcZeBN=JHV3gY_JCkCUHHASEqcUQTUmmpRY5i66Dv53k=Z3Ag@mail.gmail.com> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <CABcZeBO0nzmfcA+1ujxceDtNKPGUBZQtBg4-yN-OpOSyEJ3bNg@mail.gmail.com> <eb4530ad-2e6e-d5b6-72e7-4f84dae635e3@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <CABcZeBMtU41cuNw=JGVRe8=7GtAzCL1RsRnm3UKeNgBb5FFicw@mail.gmail.com> <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie>
Cc: "<tls@ietf.org>" <tls@ietf.org>
From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <mat.jonczyk@o2.pl>
Message-ID: <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl>
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: <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie>
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: <https://mailarchive.ietf.org/arch/msg/tls/67bVFtWXTSEvWD1zqhyEFCe6ebE>
Subject: Re: [TLS] access_administratively_disabled v2
X-BeenThere: tls@ietf.org
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." <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: Thu, 04 Jan 2018 16:39:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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 sex.com			\
		--jump DNAT --to-destination banned-page-server.local

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

> 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.
> 

Greetings,
Mateusz Jończyk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: My public key: 0x2C64C488 on hkp://pool.sks-keyservers.net
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJaTlipAAoJELLT9LcsZMSIX9YIAKHh5kcWPzSUsn6I5kIVIIna
CRwvxFVL933e7h99mi7D4/mSifUsFCOAsna3YLMzBjsKgABNTivLyGU8iUuQu+B0
4tq0vxHRUnuVy4OmwJrvl2IT42rTXqUP6GAjhh1HLPoEAiDL5WlthQi7AaKkYiBu
baPGCKjNZaPTT0+B+/OCp9IZW84BkcW4rwzWweynLZgDQd74CIEb2SiWqA+SAPxs
OtzClEIjdnRSPhsTcwA7G1aBqStNQAhgP/O/K+FTuqK2+n6vJhwkQLGwo0B+SXlz
nBVBI2MTEqx6K7ngLE/7UEibqyPIIJZ/i9H11/EAk3pJ19+IGnuXgix1zM30vqA=
=GJXR
-----END PGP SIGNATURE-----