Subject: [TLS] What does "renegotiation_info" mean?

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Jun 2018 19:47:11 +0000

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?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jun 2018 13:03:19 -0700

Hi Rich,

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
On Wed, Jun 13, 2018 at 12:47 PM Salz, Rich
<rsalz=[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Jun 2018 23:09:45 +0300

On Wed, Jun 13, 2018 at 07:47:11PM +0000, Salz, Rich wrote:
> 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?

Then there are the clients that justifiably immediately abort the
handshake if TLS 1.2 server_hello lacks renegotiation_info.

This is because unless client then tries to probe for renegoitiation,
which it can not in practice do because all the servers that just fail
to renegotiate correctly, it can not tell if it is under attack or not.

Not responding to renegotiation_info in TLS 1.2 is a security issue,
even if there is no renegotiation support. OpenSSL should be fixed to
respond to it in TLS 1.0 to 1.2 _regardless_ of if renegotiation is
enabled or not.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Wed, 13 Jun 2018 16:10:55 -0400

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.

On Wed, Jun 13, 2018 at 4:03 PM Martin Thomson <[email-masked]>
wrote:

> 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?
> >

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Jun 2018 21:57:11 +0000

Thanks for the replies; I put a summary in https://github.com/openssl/openssl/issues/6484 for OpenSSL

(ooh, look, I got a DMARC work-around :)