Re: [TLS] Chatter on consensus

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

Kemp, David P. wrote:
> Michael D'Errico's solution:
> 
>> In my code, I added three boolean configuration
>> options which all default to false:
>>
>>     AllowUnsafeInitialConnect
>>     AllowRenegotiation
>>     AllowUnsafeRenegotiation
>>
>> Hopefully this will make it obvious to people that
>> choosing the Unsafe options are just that (though
>> the first one will be needed for a while yet).
> 
> ... sounds quite reasonable.
> 
> But how many bits would it take to fully control how renegotiation is
> performed assuming that -03 permits everything (contains no MUSTs/MUST
> NOTs), and how many of those bits would any customers really want to
> have or understand how to use?

I have one other related client option:  UseExtensions.  If it is
false, then SCSV is sent instead of RI.  If a renegotiation happens,
an RI is sent even though UseExtensions is false (though no others
are sent).

These 4 bits seem to be enough to fully control renegotiation
without moving to a callback-style interface.

Mike



> 	default (all others false - renegotiation not allowed, sends
> neither SCSV nor RI)
> 
> Secure_renegotiation flag is True:
> 	AllowRenegotiationUsingExtension (sends RI) (Section 3.5
> required by elimination)
> 	AllowRenegotiationUsingBoth (sends SCSV and RI) (Section 3.5
> MUST NOT)
> 
> Secure_renegotiation flag is False:
> 	AllowUnsafeRenegotiationUsingSSLTLS (sends neither SCSV nor RI)
> (uses legacy specs)
> 	AllowUnsafeRenegotiationUsingExtension (sends RI) (Section 4.2
> recommended by elimination)
> 	AllowUnsafeRenegotiationUsingCipherSuite (sends SCSV) (Section
> 4.2 NOT RECOMMENDED)
> 	AllowUnsafeRenegotiationUsingBoth (sends SCSV and RI) (Section
> 4.2 silent)
> 
> 
> For secure renegotiation, if you eliminate the MUST NOT in section 3.5,
> then you must add a configuration somewhere (either hard coded or as a
> configuration option) that determines how the software will behave.
> 
> For insecure renegotiation, backwards interop scenarios can be supported
> non-disruptively in 3 different ways in accordance with -03, but they
> can also be supported non-disruptively in a 4th way, by following the
> RFCs for TLSv1.0-v1.2 and ignoring -03.
> 
> As a customer, I don't really care about having 4 different ways of
> doing insecure renegotiation; I'd be just as happy using software that
> acts like a legacy application when it talks to other legacy
> applications, and where that legacy behavior can be turned off with a
> single switch when interop isn't needed.
> 
> Dave