On 6/28/2013 8:16 AM, Brad Wetmore wrote: > Rearranging and tweaking a bit. What do you think of: > > --- > Reject client initiated renegotiation? > > If server side should reject client-initiated renegotiation, send an > alert_handshake_failure fatal alert, not a no_renegotiation warning > alert (no_renegotiation must be a warning: RFC 2246). no_renegotiation > might seem more natural at first, but warnings are not appropriate > because the sending party does not know how the receiving party will > behave. This state must be treated as a fatal server condition. > > This will not have any impact on server initiated renegotiation. > --- > Looks nice to me.
Xuelei > Brad > > > > > On 6/27/2013 4:51 PM, Xuelei Fan wrote: >> On 6/28/2013 6:44 AM, Brad Wetmore wrote: >>> continued, I forgot this next part. >>> >>>>> ServerHandshaker.java >>>>> ===================== >>>>> 283: My initial thought was a no_renegotiation(100) warning, but that >>>>> allows the client to decide what to do, rather than the server >>>>> terminating. >>>>> >>>> No, we cannot. First of all, warning message is not very useful >>>> because >>>> in general the sending party cannot know how the receiving party >>>> behave. >>>> Secondly, it is the expected behavior to *reject" client initiated >>>> renegotiation. It is the server who should make the decision, but not >>>> the client. >>> >>> Exactly. >>> >>>>> This TLS logic decision is not straightforward, so this needs >>>>> commenting. >>> >>> And the above is what I wanted to see in the comments. That is, why we >>> don't send a no_renegotiation warning alert. It's a subtle but >>> important enough point that should be documented. I think we should >>> open a separate bug to handle this. Just a couple of lines are needed. >>> >> What do you think these words: >> >> "Please don't send a no_renegotiation warning alert. Warning message is >> not very useful because in general the sending party cannot know how the >> receiving party behave. The server side need to reject client initiated >> renegotiation proactively." >> >> Thanks, >> Xuelei >> >> >> >>
