Renegotiation extension isn't really correct

[richsalz]

From some email to the IETF TLS list:

I wrote the following: It seems that the semantics of the "renegotiation_info" extension are slightly muddy. Qualys understands it to mean that the server will not perform insecure renegotiation, full stop. But OpenSSL further understands it to mean that the server will perform secure negotiation. OpenSSL therefore makes it difficult to simultaneously simultaneously satisfy both of Qualys's expectations, since disabling all renegotiation will cause it not to send the "renegotiation_info" extension. Popular open source web servers implement a workaround which achieves Qualys's desired behavior. Comments?

Martin Thomson replied: I think that the Qualys interpretation might be safer. That is, you
probably should send R-I always. See Karthik's response to my suggestion that it might be OK to omit R-I in some cases: https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM

David Benjamin also replied: This is BoringSSL's interpretation as well. We don't support renegotiation on the server at all, but our server still implements the renegotiation_info extension in the degenerate case for the initial handshake. It is vacuously true that all renegotiations we'll perform on that connection are secure. :-) I believe the Go TLS stack has the same behavior.

This has impacts on some open source servers, so maybe we can't fix in the 1.1.1 release.

[joymcg]

Hi richsalz
Does openssl now add renegoatiation_info extension in initial client hello message? Can openssl handle renegoatiation_info in initial client hello msg for both tls1.1 and tls1.2 versions.

[richsalz]

Answering because you pinged me: I'm not part of the project any more.

[joymcg]

Answering because you pinged me: I'm not part of the project any more.

Still thanks for the time.

[joymcg]

@mattcaswell do you have any idea about this question?

[kaduk]

Hi @joymcg you should probably have opened a new issue since you have a different question.
That said, since I am responding already, openssl never sends the empty "renegotiation_info" extension in the ClientHello; instead, we use the SCSV defined in Section 3.3 of RFC 5746 that offers equivalent functionality. We always send it initial ClientHellos.
The server can handle renegotiation_info in all versions of TLS for which it is defined (which is to say, all versions prior to 1.3).

[nhorman]

Marking as inactive, to be closed at the end of 3.4 dev barring further input