On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk <[email protected]> wrote:
> W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk <[email protected] > > <mailto:[email protected]>> 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. > My question is whether any browser has indicated interest in doing so. > > 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. > 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 > 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 <[email protected] > <mailto:[email protected]> > > > <mailto:[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}> > > > <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 > > > > > > > > > > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
