Re: [TLS] Updated draft

[Michael D'Errico <[e-mail]>]

I disagree with Pasi and with the current wording in the draft.  That
was the reason I sent the message.  I'd like to see this changed.  I
have implemented the spec, and see that it creates a MUST NOT that is
unnecessary.

The current draft suggests that if a server sees SCSV in cipher suites
and then sees RI in the ClientHello.extensions, it must abort the
handshake!  That is not necessary at all.  The RI simply overrides the
SCSV if it contains any data.  It is trivial for a server to handle
receiving both:

    - if SCSV is encountered, set a flag
    - if RI is encountered, set the same flag and extract the data

These happily coexist with no special cases, so requiring an abort is
not a good idea; it just adds complexity.

The problem appears to be the statement that SCSV is equivalent to an
empty RI, and thus would be a conflict if there was also an RI with
data.  This can be fixed by saying that SCSV is to be ignored when an
RI is also received.

Mike



Eric Rescorla wrote:
> At Thu, 17 Dec 2009 10:09:11 -0800,
> Michael D'Errico wrote:
>> s/signalling/signaling/g
>>
>> In section 4 it says:
>>
>>     Because the SCSV is equivalent to an empty "renegotiation_info"
>>     extension, any ClientHello used for secure renegotiation MUST include
>>     the "renegotiation_info" extension and not the SCSV.
>>
>> I would rather see the text say that "an RI extension takes precedence
>> over the SCSV" than to say that you must not send SCSV when you send RI.
>> It is easier for a client to simply include SCSV in every ClientHello.
>> It is also trivial for a server to handle this, as I pointed out in my
>> last message.
> 
> This implements the following point from Pasi's message.
> 
>   - There was some discussion on whether to add the magic cipher suite
>   to patched renegotiation ClientHellos (in addition to the extension),
>   too. I believe rough consensus is not to do this.
> 
> It's of course possible I misunderstood.
> 
> -Ekr