Martin Rex wrote: > > Adding the aggressive automatic silent fallback reconnects > (the "downgrade dance") to browser was not very smart. The problems > such fallbacks create was extensively discussed in the TLS WG in late 2009 > (renegotiation issue that resulted in rfc5746). > > Making repetitive/frequent downgrades (e.g. more than 1 full handshake > per host per hour) an interactive user opt-in, rather than the automatic > silent can-not-be-disabled-by-user nuisance and security problem that it > currently is, would immediately provide significant protection > -- and entirely without server-side changes. As a bonus, this would also > help in identifying/reminding on server software/devices that should > probably be updated. For quite a while, Yngve Petterson has been proposing a scheme to limit the downgrade dance problem (and willingness of clients/browsers to perform the downgrade dance), that will work immediately, not require and server-side changes, and without all of the massive serious operational problems of the current fallback-scsv proposal: https://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-03 Rubber-Stamping the fallback-scsv hack onto the standards track is IMHO a very bad idea. I've once heard the saying "If you can't be good, at least be good at it." If Browsers (and the few, if any) other TLS clients that are currently doing the dangerous downgrade dances, can't be good and stop doing such dangerous stuff, they should at least do this in a much less risky fashion than what they're currently doing. ... such as adopting Yngve's approach above and do not perform downgrades without interactive user confirmation where Yngve's proposal asks for a handshake failure. bottom line: I am violently opposed to making the fallback-scsv document a proposed standard. -Martin