Re: [TLS] access_administratively_disabled v2

Eric Rescorla <ekr@rtfm.com> Wed, 03 January 2018 15:29 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 2A3CB127241 for <tls@ietfa.amsl.com>; Wed, 3 Jan 2018 07:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, 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 vCO_w6WxeDBa for <tls@ietfa.amsl.com>; Wed, 3 Jan 2018 07:29:27 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 BFE4B1205D3 for <tls@ietf.org>; Wed, 3 Jan 2018 07:29:26 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id v190so664781ywg.4 for <tls@ietf.org>; Wed, 03 Jan 2018 07:29:26 -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=7Nr9LYS6430zKvXhzcg6Ag/lDeT4OeuCww0AcpAsrFQ=; b=q0cIvSi76uZmlIhuMMvdWcKe/ipC1QnXkN5/2h4RICtgCqA4U94plaXZbOv4Ru8CNe VRtP53kwTZzgBlQhtSoT4sL52FKfLWTDMhUJ5SzE08am8gbf0TrEKi/YMd5jqJwKa3Dn FpKt7qq7fHsDVNcE8cvf2APKTubjg9rZwFBEy1c35EubmsNsplKa69jc9B8+fi2g9fUV fEp/BrDsZXNuVfT4LAjIaxZBfsH9oEoaaDiYIcci/+FJy7lZK+1lQG4yEyCb0MEecTUZ QWNMjji2wMNedy3iS1DTDXjzgObwdZoHS8N18pQbwWz3/v1bvczEg4g2lPJo4BUDBi9l dY4A==
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=7Nr9LYS6430zKvXhzcg6Ag/lDeT4OeuCww0AcpAsrFQ=; b=kZ2Fj//aMt6aGLSOJidNebavyqippVqslbMddmLTLtYhIOYBEZX5lbja8DN23ccXFr hAAP5tCIp9gabW/7Ldww9V0Y/LIzuwg3fqJTsBemrj/BNoZsZtTuQKMPW7jH+RfreXua vQ4TEKxCIQzJl9EdzYVA2R8AFmAJQBQ6QvQ9sq1vG/ntfSB2NZqTGWzo91skfsaKJyg8 1xENtZORyemWPlp1WXw68vjx76Su+a2K3TKwgOF/IlMqLEA9igFBkHyXvnWIpwFnFllq zG8YPn5wFPF00NAyp9a9wdz8hO7Xx/yPoI8dzICk4XboqMft4rxIthj5CxegqQj0U9eJ NvDg==
X-Gm-Message-State: AKGB3mJA4yy+gyaLyg5jIw/xp09VnXF7i1sl/GXfQYE1gi6LpBtq6XRV QwfiOmqWJkvtLW+6qsrnIzH9j9yz4ij5hhROI7nE0g==
X-Google-Smtp-Source: ACJfBovf6L+vL6zW3MNo2UCNdqzwR12scB4a/lUGD8tGmgbD34mO2MGHj6ruJGbYKNii4fZnl1Vwu8061wsU8NNXF4c=
X-Received: by 10.129.154.22 with SMTP id r22mr1605384ywg.296.1514993365864; Wed, 03 Jan 2018 07:29:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 07:28:45 -0800 (PST)
In-Reply-To: <3685a850-03ec-5162-414b-c2676022d661@o2.pl>
References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <CABcZeBN=JHV3gY_JCkCUHHASEqcUQTUmmpRY5i66Dv53k=Z3Ag@mail.gmail.com> <3685a850-03ec-5162-414b-c2676022d661@o2.pl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 3 Jan 2018 07:28:45 -0800
Message-ID: <CABcZeBO0nzmfcA+1ujxceDtNKPGUBZQtBg4-yN-OpOSyEJ3bNg@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <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="94eb2c0bb4e868eabb0561e0e1b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zHWYw_d1GdR2EwQG_CXdQpwzsIk>
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 15:29:29 -0000

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

> W dniu 03.01.2018 o 14:19, Eric Rescorla pisze:
> > 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 could be possible for providers to obtain certifiates for subdomains
> such as
> opendns.access_administratively_disabled.net. Then the server reachable at
> access_administratively_disabled.net would provide a certificate for
> opendns.access_administratively_disabled.net, which would be incorrect but
> browsers would in this special case trust it.
>

Well, this seems like the first arm, in which you change the browser, so
the question
then becomes whether the browsers wish to do so. Are you aware of any
browser vendor which is interested?


> 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.
>
> Firewall and blocking list providers would deploy their own
> access_administratively_disabled.net servers. For example, Microsoft is
> providing their own filtering solution (which is called Microsoft Forefront
> Threat Management Gateway) [1] and it could deploy one
> access_administratively_disabled.net server globally.
>

And how would this work if the firewall admin wants to add their own list
of sites to be blocked?

-Ekr


>
> [1] http://msdn.microsoft.com/en-us/library/ff827462(v=vs.85).aspx
>
> Greetings,
> Mateusz Jończyk
>
> >
> >
> >
> >
> > -Ekr
> >
> >
> >
> > On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jończyk <mat.jonczyk@o2.pl
> > <mailto: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}
> >     <https://access_administratively_disabled.net?d=${domain_name}> as
> a simple
> >     string.
> >
> >     3. Certificates for access_administratively_disabled.net
> >     <http://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
> >     <http://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
> >     <http://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}
> >     <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
> >     <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
> >     <https://access_administratively_disabled.net> service for the
> public internet.
> >
> >     This mechanism would provide blocking transparency without affecting
> security.
> >
> >     Greetings,
> >     Mateusz Jończyk
> >
> >
>
>