At Wed, 16 Dec 2009 10:53:37 +0100, <Pasi.Eronen@xxxxxxxxx> wrote: > - The current draft doesn't clearly say what should be included in > legacy (insecure) renegotiation ClientHellos. I am not sure if we have > enough clear opinions to call consensus, but keeping it aligned with > the initial ClientHello (either MSCV or extension) seems to be one > simple approach (but I hope to see the actual text). Attached is some candidate text that attempts to implement this. 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. 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. 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, however, my personal view, is that I think this goes too far in the direction of accomodating broken servers. 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. > I've asked the document editor to update the draft as soon as > possible. The IESG will discuss this document this Thursday (December > 17), and I hope we can have an approved specification before > Christmas. I'm working on revisions now. -Ekr _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf