On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> 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. > A fatal alert during the handshake is never authenticated, because (a) the alert record is the last record sent (i.e. there is no Finished message sent afterward to authenticate it), and (b) The handshake hashes only cover Handshake records, not Alert records. > 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? > A conformant TLS 1.3 implementation will not be version intolerant. If the client does insecure version fallback in response to an alert or connection close by a conformant TLS 1.3 implementation then it is guaranteed to be doing the wrong thing. > 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. > This is not how the protocol works at all. The alert is unauthenticated, full stop. The only time an alert is authenticated is when it is sent after the Finished message. But then, since such alerts can be triggered by a MitM who does not have knowledge of the keys, such sending of alerts allows the MitM to effectively inject known plaintext (the alert record) into the connection, which runs the risk of facilitating attacks. > 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. > In general, the "when to bust" is "always." Again, there is no such thing as a secure non-secure fallback. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
