Re: [TLS] TLS Protocol Version

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> BTW, there's another common renegotiation case where a "low-hanging
> fruit" (trivial-to-implement solution known not to cause interop
> problems with broken servers) exists: changing from server-only
> authentication to mutual authentication (with certificate-based 
> cipher suites).
> 
> In this case, the client could include a magic "This is a
> renegotiation, but with same server certificate" cipher suite in the
> renegotiation client hello, and verify that the server certs in the old
> and new sessions are identical (bitwise). This would be just a magic
> cipher suite number: no other on-the-wire changes, and no changes to
> Finished message calculations. But the server would know this
> renegotiation is secure, and could proceed even if it prohibited
> "old-style" insecure renegotiation.


When there really is a desire to add a few simple signals in
a (probably) fully backwards compatible fashion into all existing
TLS&SSL protocols through magic ciphersuite,

Then I would like to suggest the following approach:

 - have an entire range (set of 256 ciphersuites) assigned for
   this purpose (e.g. first byte 190/0xBE or 191/0xBF )

 - use the low byte of this range as a bitfield of 8-bits
   for signaling that can be independently assigned by TLS WG / IANA

 - require this magic ciphersuite to be first in the cipher_suites
   list of the ClientHello if this signaling facility is to be used

 - require the Server to NOT ever negotiate a ciphersuite from this range
   i.e. remove it from the list when it appears first in
   ClientHello.cipher_suites and do not pass it on to functions
   that determine a common cipher suite with the client.

 - strongly recommend clients and servers to filter this magic
   ciphersuite range from normal cipher suite configuration APIs


-Martin