Re: [TLS] access_administratively_disabled v2

Mateusz Jończyk <mat.jonczyk@o2.pl> Thu, 04 January 2018 15:22 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 9CC9112D879 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 07:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 jdQP_-Q_heDw for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 07:22:45 -0800 (PST)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 4AD3012D882 for <tls@ietf.org>; Thu, 4 Jan 2018 07:22:42 -0800 (PST)
Received: (wp-smtpd smtp.tlen.pl 17181 invoked from network); 4 Jan 2018 16:22:40 +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 16:22:40 +0100
To: "Salz, Rich" <rsalz@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>, "<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> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> <a4800b5a-59e1-8ab0-7418-d47b9ca5283c@o2.pl> <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
X-Enigmail-Draft-Status: N1110
Message-ID: <1cee37b1-eef9-9b6f-97d0-09b340751015@o2.pl>
Date: Thu, 04 Jan 2018 16:22:39 +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: <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-WP-MailID: 2844ebfb3ca9bad2ff1f69abd135ac98
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 000000A [QQOk]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/f9v1N1zE44nt2v5S4RHXcW36f0g>
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:22:47 -0000

W dniu 04.01.2018 o 16:00, Salz, Rich pisze:
>
>>    Yes, at least in corporate environments, parental control solutions, etc.
>     This will give a more understandable message to the user.
>
>
> But as others have pointed out, the alert is not signed by the target origin.
> So anyone along the path can inject this alert.
Yup, just as anyone along the path can block the website.
> So browsers cannot trust it,
> and they certainly cannot display any possible text associated with it.
In the version being discussed there is no associated text.
>
> How can you distinguish valid and proper use, from not valid and improper use
> including DoS?
Any intermediary (ISP, etc.) can block a website and this way cause a DoS. TLS
changes nothing in this regard.
This solution only makes it obvious that the DoS is introduced intentionally.

> Without that algorithm specified, I doubt any browser
> would implement this.  (And IMO I doubt they will do so anyway.)
>
In the version being discussed it is just another error value.
I think browsers would implement it just like they will implement access_denied.

Greetings,
Mateusz Jończyk