On 02/01/18 20:08, Mateusz Jończyk wrote: >> I'm not really enthusiastic about any of these ideas for any of the >> administratively prohibited >> use cases because the information being provided to the user is unverifiable. >> I.e., this >> just tells you that someone on the network didn't like it, but the message >> itself is just >> an assertion (this is different from 451 in that that's provided inside the >> TLS >> channel >> if TLS is used). It's not like, for instance, the browser should display the >> string to the >> user as if it were true. > Then the browser should display a message inside the warning screen that the > string cannot be trusted.
There isn't always a browser. I'd say caldav was responsible for nearly as many cert warnings for me, but I only know that 'cause I delved into detail to find out. And the same'd be true of any application that regularly pulls from somewhere. I think that's another reason to handle this in the capport wg - I'd guess folks there are more aware of the full range of cases that may need handling and of how to try interpose the portal web page stuff before other applications see the n/w as active (or whatever it is they're doing with HTTP:-). > This is no less secure then an alternative: a TLS > certificate error that conveys no message to the user whatsoever. That's true. OTOH, I'm not sure a different error is any more secure either. 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;-)
0x7B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
