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: Mateusz Jończyk <mat.jonczyk@o2.pl>
Message-ID: <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl>
Date: Thu, 04 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-----
- [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Russ Housley
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Benjamin Kaduk
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Salz, Rich
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Salz, Rich
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Stephen Farrell
- Re: [TLS] access_administratively_disabled v2 Eric Rescorla
- Re: [TLS] access_administratively_disabled v2 Mateusz Jończyk
- Re: [TLS] access_administratively_disabled v2 Martin Thomson
- Re: [TLS] access_administratively_disabled v2 Sean Turner