Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf