Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

[Martin Rex <[e-mail]>]

David-Sarah Hopwood wrote:
> 
> Martin Rex wrote:
> > Michael Gray wrote:
> >>> in order to reliably provide this,
> >>>
> >>>   - MCSV is defined to represent an empty TLS extension RI
> >>>
> >>>   - MSCV MUST be included in *ALL* initial ClientHello handshakes
> >>>     messages _plus_ all renegotiation ClientHellos in backwards
> >>>     interop scenarios (independent of full handshake or session resume).
> >>>
> >>>   - empty TLS extension RI MUST NOT be sent, ever!
> >>
> >> This looks good to me, the only thing I would change is I think MUST NOT
> >> would be better as SHOULD NOT as the later requires that the implementer
> >> examine the conditions and implications etc to make the best decision.
> > 
> > You are right.  I'm sorry.  I got a little carried away.
> > 
> > A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate.
> 
> Why? What is the point of allowing the client to send an empty extension,
> when a patched client MUST send the MSCV, and a patched server MUST use
> *only* the MSCV to determine whether the client is patched? You'd just be
> adding the option to send an extension that has no defined meaning.

I have mixed feelings about this.  Maybe we do need a MUST to make
things clear.

There *IS* no point in doing that (which is why I lightheartedly wrote
MUST NOT).  An implementation that is sending it will just waste
code and network bandwidth.

As far as I understand there seem to be architectures where the
ServerHello extensions parser will only search for replies to
TLS extensions it requested (and ignore others).  Now for the
RENEGO_PROTECTION to reliably work against downgrade attacks in
backwards interop scenarios, that code MUST be changed to process
a TLS extension RI reply in ServerHello in cases where it did _NOT_
send an empty TLS extension RI in ClientHello--otherwise there
would be no downgrade MitM attack protection.

Therefore a mere SHOULD NOT might lead to defective/vulnerable
implementations in case these implementations allow backwards
interoperability or extension-less SSLv3 ClientHellos
or SSLv2 ClientHellos.


-Martin