On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote: > There's no evidence that the presence or absence of an alert when a > connection is closed makes any positive difference in the security of any > non-secure fallback mechanism. Keep in mind that the alerts during the > handshake are NOT authenticated, and the TLS threat models thus assumes > that the attacker can remove or alter them.
The whole handshake is retroactively authenticated upon completion. Just because an attacker can muck up the attempt to connect, doesn't mean all hope is lost. The primary benefit with the version alert, specifically, is that it allows a client to at least have a clue as to what to attempt. Without alert: client tries server stares blankly into the void and/or drops abruptly now, what does the client do? try again as-is, or try again with old stuff? With alert: client tries if server responds with an alert, react to it if not, try again until there's a response; give up eventually Sure, a MitM could try to downgrade by injecting an unauthenticated alert into the mix, but the handshake will fail once that is authenticated at the end. Just as the obvious footnote: it's impossible to make any of this resistant to an attacker killing the connection. Just assume that's always possible, at minimum with wirecutters. The goal is security or bust. Alerts give clients the confidence to actually bust when they have to. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
