Eric Rescorla wrote: > > It is possible that un-upgraded servers will request that the client > renegotiate. It is RECOMMENDED that clients refuse this > renegotiation request. Clients which do so MUST respond to such > requests with a "no_renegotiation" alert [RFC 5246 requires this > alert to be at the "warning" level.] It is possible that the > apparently un-upgraded server is in fact an attacker who is then > allowing the client to renegotiate with a different, legitimate, > upgraded server. In order to detect this attack, clients which > choose to renegotiate MUST provide either the > TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their > ClientHello. In a legitimate renegotiation with an un-upgraded > server, either of these signals will be ignored by the server. > However, if the server (incorrectly) fails to ignore extensions, > sending the "renegotiation_info" extension may cause a handshake > failure. > Thus, it is permitted, though NOT RECOMMENDED, for the > client to simply send the SCSV. This is the only situation in which > clients are permitted to not send the "renegotiation_info" extension > in a ClientHello which is used for renegotiation. This is bad because it greatly complicates the simple definition of the SCSV as "exactly the same semantics as an empty 'renegotiation_info' extension". In fact, it tends to convey exactly the message that the attacker wants "this is an initial handshake". > Note that in the case of this downgrade attack attack above, if this > is the initial handshake from the server's perspective, then use of > the SCSV from the client precludes detection of this attack by the > server. However, the attack will be detected by the client when the > server sends an empty "renegotiation_info" extension and the client > is expecting one containing the previous verify data. It doesn't seem very robust to me. A very long chain of things have to go just so (some even at the option of the attacker) for the client to detect this attack. > By contrast, > if the client sends the "renegotiation_info" extension, then the > server will immediately detect the attack. > > After flip-flopping on this in my head a few times, You're not the only one. :-) > however, my > personal view, is that I think this goes too far in the direction of > accomodating broken servers. Not so much that we want to specifically not be accommodating, but this case introduces complexities and internal contradictions at the expense of non-crusty clients and servers. There's also something to be said for specifically declining to accommodate things in a spec that are already broken twice or thrice over (depending on which spec you read) in the first place. It's not even fixing things half-way. It may be fixing things one-third-way or not at all depending on your philosophy. IMHO, the IETF shouldn't endorse the making of insecure TLS connections by attempting to secure them poorly. In this case, however, the specs should leave enough room for applications to do that sort of thing on their own if they so choose. But in doing so, application vendors, admins, and users alike should know that they are engaging in risky behavior in public. It's visible on the wire. > Sending RI in this instance only creates > an interop problem when a server (1) is doing something we know to be > really unsafe and (2) can't even ignore extensions correctly. We've > seen a number of suggestions that we actually forbid renegotiation in > case (1) and while I suspect WG consensus doesn't go that far, it's not > clear to me that we need to not only allow it but also compensate for > servers which are broken in other respects. > So, my preference would > be to simply mandate RI with the previous verify_data here as in > all other cases. +1 for simplicity and consistency - Marsh _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf