Pasi.Eronen@xxxxxxxxx wrote: > > The detail in question is whether the "Signalling Cipher Suite Value" > (SCSV) can be included when performing secure renegotiation (in > addition to the renegotiation_info extension). > > Currently, the SCSV is not included. In the version that went to IETF > Last Call (version -01), the relevant text was: > > "This cipher suite has exactly the same semantics as an empty > "renegotiation_info" extension. [..] Because this cipher suite is > equivalent to an empty "renegotiation_info" extension, only > "renegotiation_info" may be used rehandshakes." (in Section 4) > > Version -03 (the latest version) has rephrased the text as follows: > > "The SCSV MUST NOT be included." (in Section 3.5, "Client Behavior: > Secure Renegotiation") > > "When ClientHello is received, the server MUST verify that it does > not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV is > present, the server MUST abort the handshake." (in Section 3.7, > "Server Behavior: Secure Renegotiation") http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives^M Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6! Keep in mind that sending SCSV on renegotiations is explicitly permitted by -03 for old renegotiations so that is inconsistent. Further inconsistencies: section 3.3 says "the SCSV may be safely be sent to any server". which obviously contradicts both new MUST NOTs. I think we all agree that using a cipher suite value for signaling is a creative use ("hack") of a TLS protocol extensibility option that is not documented in this fashion in SSL/TLS. By doing this, we should limit the changes of the semantics of this extensibility option to the absolute necessary. There never was an interop problem based on a presence of a particular cipher suite value in TLS, and it doesn't seem like a good idea to create such an interop problem for the presence of a cipher suite value in ClientHello when it is avoidable. It can be easily avoided The WG discussion just before XMas developed consensus on how to do this. Did anyone of you review the new sections in the -03 draft? Question to those who are voicing opinions just now, what would you tell someone who has little TLS experience and just read the -03 document, to which attack this paragraph in -03 refers (section 4.2, bottom of page 9): http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#page-9 and to which "above attack" section 4.3 on page 10 refers? section 4.2, is not only confusing, it is also inconsistent. 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. contradicts When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. [Because the server has already indicated it does not support secure renegotiation the only way that this can happen is if the server is broken or there is an attack.] I do not think that rushing the document out of the door as-is would be a good idea. This would set new lows for the level of IETF Proposed Standard. *I* have never suggested and do not endorse the specific SCSV semantics as described in the -03 document. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf