On Thursday, September 17, 2015 05:46:39 pm Brian Smith wrote: > Let's ask the browser vendors: > > Browser vendors, if web servers were to stop sending alerts during > handshake failures, would you start doing version fallback when a > connection is closed?
Well, what else would clients do instead? The answer is an unambiguous yes. There's no way to tell a microwave oven killing the WiFi and a legitimate handshake failure apart if no information is sent back. Implementors will always assume it's possible to retry, and we know from history that this will involve an unsafe fallback dance. > > I'd rather keep them than remove them, but I'd be OK with clients never > > sending them. I'm OK with fata alerts being SHOULD send. > > I suggest that, at most, implementations SHOULD NOT send them. IMO it would > be better to remove the alert mechanism altogether in TLS 1.3. > > Most people that are arguing for retaining the alert requirements seem to > be concerned about alerts sent from the server to the client. Does anybody > think it is important to require clients to ever send alerts other than > close_notify? There's also user_canceled and cert errors when doing client authentication. The idea of restricting what alerts clients, specifically, should send is not necessarily something I'd object to, though I don't think it's useful. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
