Re: [TLS] access_administratively_disabled v2

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 04 January 2018 15:53 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 D849D12D851 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 07:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 6WwwVTBsp6vA for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 07:52:58 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AFF12D879 for <tls@ietf.org>; Thu, 4 Jan 2018 07:52:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F379BDD8; Thu, 4 Jan 2018 15:52:51 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os8UE0mhebaj; Thu, 4 Jan 2018 15:52:49 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8FA76BE56; Thu, 4 Jan 2018 15:52:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515081168; bh=Va9Zdr74cXQO5ye0jgI9cZX2qURwNIi/py9poG/kjtE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CuAs8aYF+bPHRj5XYyP4VQ9I3b++SFmO3hPbTdfJLEJSikVaaRrSkoVAUrcBbZ8xL rYBuhCvxiUWinOeNER4NmS6CfQ+iGfPnrfDWvl3guouiRIpup+bnpFxyKMdnySz3Fm 9ZW+uvSEvueKHLL4IuudLnlmJ9NH8weHEqkKaAIE=
To: Eric Rescorla <ekr@rtfm.com>, =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <mat.jonczyk@o2.pl>
Cc: "<tls@ietf.org>" <tls@ietf.org>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie>
Date: Thu, 4 Jan 2018 15:52:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMtU41cuNw=JGVRe8=7GtAzCL1RsRnm3UKeNgBb5FFicw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FLkuFgTh6v4lqBERTwWoRZSNJJlQtQT92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oLoFSri7sDoTmCMF96TCo80dArY>
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 15:53:03 -0000


On 04/01/18 14:22, Eric Rescorla wrote:
> I am not in favor of this change at this time.

Same here.

> 
> I suspect I'm not in favor of the mechanism, but i'm definitely not in
> favor of
> adding a placeholder alert for some mechanism which isn't specified.

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

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

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)