Re: [TLS] access_administratively_disabled v2

Eric Rescorla <ekr@rtfm.com> Wed, 03 January 2018 13:19 UTC

Return-Path: <ekr@rtfm.com>
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 441FB127023 for <tls@ietfa.amsl.com>; Wed, 3 Jan 2018 05:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 dQpRwaYmHVTf for <tls@ietfa.amsl.com>; Wed, 3 Jan 2018 05:19:44 -0800 (PST)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDEC1201F8 for <tls@ietf.org>; Wed, 3 Jan 2018 05:19:43 -0800 (PST)
Received: by mail-yb0-x234.google.com with SMTP id w1so558601ybe.10 for <tls@ietf.org>; Wed, 03 Jan 2018 05:19:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSc7klvTAG1OaynTxFGl17XED6RUv5dJ0k4v3d2aaNs=; b=M5ftXRsL/LgfdbjI4pBrFWc4IlenxfIql3EfkCUZaYifsxUvbY0ZGe6XF4SXj8z15U qXB8zH9Y1l+CCJhu43y64IhstdUuMMXKwdPU+1uL06WdjlrFMe3HCT7vdnYO2susoe7y CL4AYvrfIXEup2JSA3j2fnrf7Krrm5Iwmk+rZ1HYRW5RniYgjVR0Oj8i+T2FgzOXVb0y l5GPebzTvrTbtuN9T0dHmRekxZXCgAD0R3IBxBmbAcKl+sLoAkpMC1zl+NM/3Ji8Gc8H m/AGFLj2VADZDo0K8iyUhCXuuPCKUqe2AH/w5+Hj5/Lp9BMX8y7wajAhPXhyPwlK9gXj tR6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSc7klvTAG1OaynTxFGl17XED6RUv5dJ0k4v3d2aaNs=; b=rTtJ/e+rl9TdvraABRh7mbJiR++vowZUqU9i6XFA5EjPUeZOETztY+p/qSgiUyM/dm eLTggl8Iq52rWDunQwlaTKrKMc7fGjVmRBb37HfD0T6+mV4bnm0ZyTYgRXCzvoLlDLO/ l2LZIcCoVp9Kj4ck/RBXlDDSG0C7SV6svVVcTHGAqqXyal1aovySlQMHU349wWpO5UgU /NVhUVKFdc36RXilWsGnyPBWiD86npzGFPSNyhT8ZU47MjvWPb1mDIQYMPeN1cIa8MDg vmq3bwdCI/cwo/2/wjZgBA8byknZ8l34xt0tLh9LcjQRIot1s8wyYMAAEzTv5EMGJ7LJ MhLw==
X-Gm-Message-State: AKGB3mIiqTrCWAjn2VPDs1ORRefQ88+ySY1jDJfiUmprLaM7fhINaCMD uC5NUEF/+C3sT1P/a+pEHI8wK6y6s13EIcqbDHWzXg==
X-Google-Smtp-Source: ACJfBosbkS52kHjWUfo4ZqhtnA1QzzXPkCV5pdTUEM86oLKT8j1IcsmISzAQkha82nBRT9uht5Bh4uYwZSGEaomqr6o=
X-Received: by 10.37.134.137 with SMTP id z9mr1287728ybk.497.1514985583112; Wed, 03 Jan 2018 05:19:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 05:19:02 -0800 (PST)
In-Reply-To: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl>
References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 03 Jan 2018 05:19:02 -0800
Message-ID: <CABcZeBN=JHV3gY_JCkCUHHASEqcUQTUmmpRY5i66Dv53k=Z3Ag@mail.gmail.com>
To: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, abbypan@gmail.com, Ted Lemon <mellon@fugue.com>, JW <jw@pcthink.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="089e082608f08587d40561df1116"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gtFD97s52-lCWZeu7KQ-zRFt2dE>
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: Wed, 03 Jan 2018 13:19:46 -0000

I have several comments:

- This is almost entirely out of scope for TLS, so you should start with
CAPPORT. If they're interested, then we can discuss the code point
assignment in TLS.

- You point #2 would effectively require either changes to the browser or
CA issuance policies (the BRs would prohibit issuing to an entity under
these conditions). I'm not sure that browser manufacturers would be excited
about either set of changes. Resolving this seems like a threshold question
for this proposal. It seems like there are going to be rather a large
number of such entities (every Firewall in the world?) so it may not be
practical.

-Ekr





-Ekr



On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:

> Hello,
> Based on Your feedback (for which I am grateful) I have designed a new
> version
> of the access_administratively_disabled mechanism.
>
> 1. One new AlertDescription value should be specified:
> access_administratively_disabled.
>
> 2. The information why the webpage is blocked is specified at the URL
> https://access_administratively_disabled.net?d=${domain_name} as a simple
> string.
>
> 3. Certificates for access_administratively_disabled.net are assigned in a
> non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a
> certificate for access_administratively_disabled.net provided that their
> identity is validated (i.e. in an Extended-Validation way). The list of
> entities
> that received certificates for this domain would be made public and
> managed by
> IANA. This way the risk of phishing would be eliminated.
>
> 4. Any entity that is blocking some websites would redirect traffic for
> access_administratively_disabled.net to their own servers.
>
> 5. After getting an access_administratively_disabled warning a browser
> would
> open https://access_admininistratively_disabled.net?d=${domain_name} ,
> validate
> its certificate and display to the user information: what get blocked, by
> whom
> and why.
>
> 6. If https://access_administratively_disabled.net would not have a valid
> certificate, the browser would only display that the website is being
> blocked,
> without giving any reason.
>
> 7. IANA or someone else would provide a default
> https://access_administratively_disabled.net service for the public
> internet.
>
> This mechanism would provide blocking transparency without affecting
> security.
>
> Greetings,
> Mateusz Jończyk
>