Is the concern that servers which never renegotiate and do not send any renegotiation_info are being flagged on ratings systems? That is desired behavior. See the final paragraph of section 4.3 <https://tools.ietf.org/html/rfc5746#section-4.3>. Those servers should be sending an empty renegotiation_info. "I never renegotiation" is vacuously consistent with "all my renegotiations are secure".
This is important because fixing the renegotiation issue requires either: - The server rejects *all* extension-less renegotiations, or... - The client rejects *all* extension-less handshakes, including initial handshakes <https://tools.ietf.org/html/rfc5746#section-4.1> That second point means that clients cannot protect themselves against non-strict servers if there are any servers which do not implement at least the minimal version of the extension. Server implementations which fail to send the minimal renegotiation_info extension on the initial handshake should indeed be flagged by ratings systems and fixed. On Wed, Mar 27, 2019 at 3:39 PM Salz, Rich <rs...@akamai.com> wrote: > I would like to define a flag that says "no renegotiation allowed" This > has come up (for pre 1.3 of course) a couple of times, that while you can > signal "defaut" or "only secure" renegotiation, you can't signal "no > renegotiation" in a way that is visible purely on the wire, to things like > SSLLabs ratings systems. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
