Recall that the original renegotiation attack relied on a client that has no intention to renegotiate but was still fooled into renegotiating the attackers’s connection to the server. To prevent this attack, it is essential that the client includes an empty R-I in its client hello. This negative acknowledgment is as useful as a positive one.
This is particularly true on the client side. A server that does not support renegotiation may be able to get away with not supporting R-I, but this probably also leads to some (weak) attacks. > On 31 Aug 2016, at 11:21, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 26 August 2016 at 06:43, Sean Turner <s...@sn3rd.com> wrote: >> Any more thoughts on these? > > I have no problem with implementations that don't use R-I (in either > extension or SCSV form) if they don't intend to ever renegotiate. I > know that that disagrees with RFC 5746, but there you have it. > > _______________________________________________ > 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
