Subject: [TLS] access_administratively_disabled v2

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 3 Jan 2018 13:48:36 +0100

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jan 2018 05:19:02 -0800

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

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 3 Jan 2018 15:45:10 +0100

W dniu 03.01.2018 o 14:19, Eric Rescorla pisze:
> 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.

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

[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 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hello,
>     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
>     certificate for access_administratively_disabled.net
>     <http://access_administratively_disabled.net> provided that their
>     access_administratively_disabled.net
>     <http://access_administratively_disabled.net> to their own servers.
> 
>     open https://access_admininistratively_disabled.net?d=${domain_name}
>     <https://access_admininistratively_disabled.net?d=${domain_name}> , validate
>     6. If https://access_administratively_disabled.net
>     <https://access_administratively_disabled.net> would not have a valid
>     https://access_administratively_disabled.net
>     <https://access_administratively_disabled.net> service for the public internet.
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jan 2018 07:28:45 -0800

On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk <[email-masked]> wrote:

> assignment in

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?

> 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

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Jan 2018 11:08:03 -0500

Mateusz:

How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain?

Russ

P.S.  If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen.  Underscore is not allowed.

> On Jan 3, 2018, at 7:48 AM, Mateusz Jończyk <[email-masked]> wrote:
> 
> Hello,
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 3 Jan 2018 17:17:24 +0100

W dniu 03.01.2018 o 16:28, Eric Rescorla pisze:
> 
> 
> On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk <[email-masked]
>     opendns.access_administratively_disabled.net
>     <http://opendns.access_administratively_disabled.net>. Then the server
>     reachable at
>     <http://access_administratively_disabled.net> would provide a certificate for
>     opendns.access_administratively_disabled.net
>     <http://opendns.access_administratively_disabled.net>, which would be
>     incorrect but
> Well, this seems like the first arm, in which you change the browser, so the
> question

I'm not exactly sure what You understand by "the first arm".
Of course it would have to be implemented in browsers, by me or somebody else.
Microsoft may wish to deploy this in their Forefront TMG, so browser support in
Internet Explorer / Edge would follow.

Judging from TLS1.3's problems with middleboxes, content filtering isn't so
rare, especially in the corporate world.

The provider of filtering services (for example OpenDNS) / middlebox
manufacturer would have to recognize if the client supports this mechanism.
Having support for TLS1.3 could be one such flag.

>     > entities (every Firewall in the world?) so it may not be practical.
DNS already handles a large number of such entities and it somehow works and is
practical. Having a subdomain of access_administratively_disabled.net registered
would be expensive because a physical validation would have to be followed - it
would probably be no less expensive than EV certificates currently are.

>     <http://access_administratively_disabled.net> servers. For example, Microsoft is
>     <http://access_administratively_disabled.net> server globally.
> 
> 

Then access_administratively_disabled.net would respond with a generic "site
blocked by administrator". It could also modify response according to a source
IP address, but this would not be necessary.
OpenDNS currently does exactly this. It recognizes its users by incoming IP
addresses. It even provides administrator contact data on the "access denied" page.

Greetings,
Mateusz Jończyk

>     <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 <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hello,
>     <https://access_administratively_disabled.net?d=${domain_name}>
>     >     <https://access_administratively_disabled.net?d=${domain_name}
>     <https://access_administratively_disabled.net?d=${domain_name}>> as a simple
>     >     string.
>     >
>     <http://access_administratively_disabled.net>
>     >     <http://access_administratively_disabled.net
>     <http://access_administratively_disabled.net>> are assigned in a
>     <http://access_administratively_disabled.net>
>     >     <http://access_administratively_disabled.net
>     <http://access_administratively_disabled.net>> provided that their
>     <http://access_administratively_disabled.net>
>     >     <http://access_administratively_disabled.net
>     <http://access_administratively_disabled.net>> to their own servers.
>     >
>     <https://access_admininistratively_disabled.net?d=${domain_name}>
>     >     <https://access_admininistratively_disabled.net?d=${domain_name}
>     <https://access_admininistratively_disabled.net?d=${domain_name}>> , validate
>     <https://access_administratively_disabled.net>
>     >     <https://access_administratively_disabled.net
>     <https://access_administratively_disabled.net>> would not have a valid
>     <https://access_administratively_disabled.net>
>     >     <https://access_administratively_disabled.net
>     <https://access_administratively_disabled.net>> service for the public internet.
>     >

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jan 2018 08:31:08 -0800

On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk <[email-masked]> wrote:

> the

My question is whether any browser has indicated interest in doing so.

> would probably be no less expensive than EV certificates currently are.

It's not a matter of scaling. It's a matter of having this many
certificates that can
all generate an acceptable message undermines the value of the signature
because you now have a distributed single point of failure.

-Ekr

> <mailto:[email-masked]>
> >     >     5. After getting an access_administratively_disabled warning
> a browser
> >     would
> >     >     its certificate and display to the user information: what get
> blocked,
> >     by whom
> >     >     and why.
> >     >
> >     >     certificate, the browser would only display that the website
> is being
> >     blocked,
> >     >     This mechanism would provide blocking transparency without
> affecting
> >     security.
> >     >
> >     >     Greetings,
> >     >     Mateusz Jończyk
> >     >
> >     >
> >
> >
>
>

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 3 Jan 2018 17:48:54 +0100

W dniu 03.01.2018 o 17:31, Eric Rescorla pisze:
> 
> 
> On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk <[email-masked]
No, I didn't contact any browser vendors.

If an AlertDescription will be allocated, they will have to implement this at
least halfway - display some warning to the user, without necessarily contacting
access_administratively_disabled.net at all.

>     practical. Having a subdomain of access_administratively_disabled.net
>     <http://access_administratively_disabled.net> registered
> It's not a matter of scaling. It's a matter of having this many certificates
> that can

Just like CAs.

I don't think that there will be more access_administratively_disabled.net
subdomains than there are CAs currently.

After all, the failure won't be very catastrophic: it will only enable someone
who already is able to intercept all traffic to slightly phish the users.

If some key will leak publicly, it will be simply revoked.

Greetings,
Mateusz

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 3 Jan 2018 17:53:57 +0100

> How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain?

IANA is just an example, there could be some other provider controlling the
access_administratively_disabled.net domain - possibly even OpenDNS.
Subdomains [1] would be given out just like EV certificates are today - only
proof of identity (and of payment) would be required.

> P.S.  If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen.  Underscore is not allowed.

Yup, I also thought so.
access_administratively_disabled.net is only a placeholder, the final domain
name would be different.

Greetings,
Mateusz

[1] For a slight modification of the proposal, see
https://www.ietf.org/mail-archive/web/tls/current/msg25226.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Jan 2018 11:05:36 -0600

> Having support for TLS1.3 could be one such flag.

Cherry-picking this one part just for enhanced clarity: I do not think
support for TLS 1.3 can or should be such a flag -- there does not seem
sufficient reason to block TLS 1.3 finalization for this proposal.

-Ben

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 11:46:14 +0100

> sufficient reason to block TLS 1.3 finalization for this proposal.

I would like to ask You to add just this one flag:
access_administratively_disabled to TLS 1.3. This will allow graceful upgrade to
full proposed functionality of the access_administratively_disabled mechanism.

I will try to submit an Internet Draft for the full mechanism till the end of
this week.

Greetings,
Mateusz Jończyk

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 13:48:38 +0100

> I will try to submit an Internet Draft for the full mechanism till the end of

I have sent a pull request:
https://github.com/tlswg/tls13-spec/pull/1134
	Added access_denied_by_intermediary AlertDescription

	Network intermediaries (for example ISPs) may always block traffic by
	using e.g. access_denied. Make it more explicit by adding
	access_denied_by_intermediary.

	This will make censorship more transparent.

Greetings,
Mateusz Jończyk

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Jan 2018 13:32:22 +0000

➢   https://github.com/tlswg/tls13-spec/pull/1134
…
    	This will make censorship more transparent.
  
Only if the censor agrees to use that alert to indicate what they are doing.  Do you really think that will happen?

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 14:45:00 +0100

> Only if the censor agrees to use that alert to indicate what they are doing.  Do you really think that will happen?

Yes, at least in corporate environments, parental control solutions, etc.
This will give a more understandable message to the user.

Greetings,
Mateusz Jończyk

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Jan 2018 06:22:56 -0800

> full proposed functionality of the access_administratively_disabled

I am not in favor of this change at this time.

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.

-Ekr

I will try to submit an Internet Draft for the full mechanism till the end
> of

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 15:43:28 +0100

W dniu 04.01.2018 o 15:22, Eric Rescorla pisze:
> 
> 
> On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk <[email-masked]
> I suspect I'm not in favor of the mechanism, but i'm definitely not in favor of
OK, but what about this change considered separately? I have changed the
semantics slightly:

+access_denied_by_intermediary
+: The access was denied by a network intermediary - i.e. a server other
+  than the client or the desired server, for example by an Internet Sevice
+  Provider.

Justification:
	Network intermediaries (for example ISPs) may block traffic by using
	e.g. access_denied anyway. Make it more explicit by adding
	access_denied_by_intermediary.

Greetings,
Mateusz

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Jan 2018 06:46:10 -0800

>         This will make censorship more transparent.

Sorry, no, I'm not persuaded. It's not clear to me that this is a benefit,
and certainly
not clear enough to merit a last minute change to 1.3.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Jan 2018 15:00:19 +0000

But as others have pointed out, the alert is not signed by the target origin.  So anyone along the path can inject this alert.  So browsers cannot trust it, and they certainly cannot display any possible text associated with it.

How can you distinguish valid and proper use, from not valid and improper use including DoS?  Without that algorithm specified, I doubt any browser would implement this.  (And IMO I doubt they will do so anyway.)

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 16:22:39 +0100

W dniu 04.01.2018 o 16:00, Salz, Rich pisze:
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 4 Jan 2018 15:52:47 +0000

> I am not in favor of this change at this time.

Same here.

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Jan 2018 07:58:28 -0800

> I think browsers would implement it just like they will implement

Well, support for access_denied is pretty minimal. I just tested in Chrome
and Firefox,
and they both generate pretty much generic error pages for both
access_denied
and some unknown alert number. Chrome provides a pretty opaque error code
(ERR_SSL_PROTOCOL_ERROR) and Firefox just provides a confusing error
about how it couldn't complete the connection.

-Ekr

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 4 Jan 2018 17:39:07 +0100

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Jan 2018 09:29:11 +1100

> be of benefit. It seems to me that possibly yes, but haven't reviewed this.

Please take that discussion to the capport WG ([email-masked]).

However, it seems like you want to address filtering/censorship more
than you want to address the captive portal case.  I can say that the
capport WG isn't interested in anything that might improve filtering
or censorship and are explicitly designing mechanisms that avoid doing
so.  I won't say that you can't raise the issue, but you should be
aware that this topic has been discussed quite a bit already and
unless you have new information, I doubt you will change the
conclusions.

---

From: Sean Turner <[email-masked]>
Date: Fri, 5 Jan 2018 09:33:37 -0500

Mateusz,

It appears that the way forward is to document the mechanism you have in mind in an Internet-Draft.  That I-D should include the mechanism as well as the new alert you want.*  It is better that the alert be in a separate I-D (i.e., not in the TLS 1.3 specification) because including an alert in the TLS 1.3 draft that refers to a yet-to-be standardized mechanism is pretty much not going to work with the IETF publication process; we are near the finish line for TLS 1.3 and having a reference of this sort will no doubt add some delay possibly a lot of delay.**

The other issue here is that there is an existing WG chartered (capport) to work on this particular problem or some part of it; the TLS WG would be stepping on their toes if we picked up the work.

For the two reasons listed above, I’m asking ekr to close the PR#1134.

spt

* Please do not include a value for the alert use "(TBD)".

** The reference would be a normative reference to another specification that was not at the same “maturity" level.  The TLS 1.3 specification would have to wait while this new I-D gets to the same maturity - but there’s no guarantee that the I-D will in fact get to the same maturity level.

> On Jan 4, 2018, at 17:29, Martin Thomson <[email-masked]> wrote:
>