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
On 26 August 2016 at 06:43, Sean Turner 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.
Any more thoughts on these?
spt
> On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS)
> wrote:
>
> Hi Ben,
>
> On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote:
> > The next step is for someone to write proposed text that would be more
> > clear.
> > Maybe you
On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote:
>
> So I take it my interpretation is correct -- these values are only ever
> required for renegotiation and serve no other purpose? I.e. the hint can
> safely be ignored in this case and the implementation will still be fully
>
Hi Watson,
On Tue, Aug 2, 2016 at 16:02, Watson Ladd wrote:
>> However, there is also this in Sect. 3.6 which has caused some confusion and
>> lengthy discussion among my colleagues and myself:
>>
>>o When the handshake has completed, the server needs to save the
>> client_verify_data
Dear mailing list,
regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a question
which could not be solved in our internal discussions. Therefore I would kindly
ask for your comments on my issue. If I posted to the wrong place, please
advise on where such a question would be