Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in legacy environments

[David-Sarah Hopwood <[e-mail]>]

Michael Gray wrote:
> Note : Clients that use either of the signaling methods MUST be prepared to
> accept a Server response containing the  "renegotiation_info" extension
> transmitted in a ServerHello message with the SSLv3 protocol version {
> 0x03, 0x00 } and MUST continue with protected renegotiations at this
> protocol level.

This is fine, although obvious.

> Additionally, I believe that adding extensions in the initial ClientHello
> could result in adverse customer events in some very small number of
> environments that are extensions intolerant [1].  The following additional
> note in Section 5 would be useful in providing guidance in mitigating this
> concern:
> 
> Note :  In cases where a ClientHello protocol behavior change from not
> sending extensions to sending extensions is a risk where legacy Servers may
> exist that are extension intolerant then the Client MAY mitigate this risk
> by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHOULD
> NOT send the "renegotiation_info" extension unless the Client is sending
> other extensions.

Strongly opposed. There is no justification for a SHOULD NOT-level statement
insisting that clients work around bugs in nonconformant servers. (Read the
RFC 2119 definition of SHOULD NOT; it clearly doesn't apply.)

Besides, it is incorrect to not send the RI extension in cases where it
would have contained verify_data.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com