Safe renegotiation patch

[Nikos Mavrogiannopoulos]

On Mon, Jan 11, 2010 at 3:46 PM, Steve Dispensa
<dispensa at phonefactor.com> wrote:

> All,
>
> I've updated the patch I initially submitted to conform to the new
> renegotiation draft. It's building and working, and I'm starting
> interoperability testing today. I hope to have something to post to the list
> for review in the next day or two.
> I wanted to run a couple of decisions by the group as to how this should
> work. I've modified GNUTLS to always send (only) the RI extension for TLS1+,
> and to send SCSV for SSLv3 initial client hellos. All other SSLv3 hellos use
> the extension, as required by the draft. Does that make sense? I'd be glad
> to explain my reasoning if you'd like.

Hello Steve,
 That sounds reasonable, however I am mostly concerned with the
changes required to send the SCSV.
I had also ported yesterday your previous patch to git (with
modifications - mostly error checking, priority string support and the
new draft changes except for SCSV), so it would be nice to sync them.
If you post your code I could merge both codes.

> Also, I'm providing three API's:
>  - gnutls_allow_unsafe_renegotiation - allows for "lenient" mode, where
> we'll agree to talk to a peer that doesn't indicate support for safe
> renegotiation

Seems ok.

>  - gnutls_allow_unsafe_initial_negotiation - allows servers to talk to a
> client that doesn't indicate support for safe renegotiation only as long as
> the client doesn't attempt to renegotiate (but drops the connection on any
> renegotiation attempt)

Why this one is needed? Shouldn't all initial negotiations be accepted
and fail only if renegotiation
is requested? I believe this was the behavior of your previous patch.

best regards,
Nikos