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. > 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 protected] > <mailto:[email protected]>> 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 > > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
