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 :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
On Wed, Jun 13, 2018 at 07:47:11PM +, 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
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
