Re: [TLS] access_administratively_disabled v2

[Mateusz Jończyk <[e-mail]>]

W dniu 03.01.2018 o 16:28, Eric Rescorla pisze:
> 
> 
> On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk <[e-mail]
> <mailto:[e-mail]>> 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
>     <http://opendns.access_administratively_disabled.net>. Then the server
>     reachable at
>     access_administratively_disabled.net
>     <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
>     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?

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.




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

>     Firewall and blocking list providers would deploy their own
>     access_administratively_disabled.net
>     <http://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
>     <http://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?
> 

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

> -Ekr
>  
> 
> 
>     [1] http://msdn.microsoft.com/en-us/library/ff827462(v=vs.85).aspx
>     <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 <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> 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}>
>     >     <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>
>     >     <http://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>
>     >     <http://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>
>     >     <http://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}>
>     >     <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>
>     >     <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>
>     >     <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
>     >
>     >
> 
>