On Thu, Jan 4, 2018 at 7:22 AM, Mateusz Jończyk <mat.jonc...@o2.pl> wrote:
> W dniu 04.01.2018 o 16:00, Salz, Rich pisze: > > > >> Yes, at least in corporate environments, parental control solutions, > etc. > > This will give a more understandable message to the user. > > > > > > 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. > 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 > Greetings, > Mateusz Jończyk > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
