Re: [TLS] One approach to rollback protection

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
>
> I wrote:
> > 
> >  [ciphersuite minor value composed of bitmask]
>
> Hmm... What's the advantage of something this complicated/expressive,
> especially given that there is no way to currently express
> "I speak TLS 1.2 but not 1.0"?

Having slept over my own proposal (and considering the lack of interop
of the original TLS version negotiation demonstrated by the installed base),
I would be fine with a small set of simple cipher suite values, starting
with TLSv1.0.

My primary interests are

  - reducing the amount of failed TLS handshakes

  - allow TLS clients without reconnect fallback to propose
    TLSv1.1 or higher without risk of new interop failures with
    version intolerant servers or bugs related to RSA premaster secret
    client_version checks, such as the bug in Win7/Win2008R2 renego.

  - get protection for the TLS version negotiation for free
    (for peers that implement this)

Our implementation is unconditionally including the rfc5746 renego SCSV
in every ClientHello, so I don't see an interop issue with this.

Even sending TLS extension (which we do not) seems to be not much
of a problem these days.  But the number of interop problems that
we have noticed ourselves in TLS version negotiation, including incorrect
RSA premaster secret client_version checks, is very disappointing.

The changes necessary to add TLSv1.1 support to our implementation
looks pretty marginal, because it is essentially only the explicit
random IVs for TLS cipher suites with block ciphers in CBC mode
(plus removing the CBC-padding oracle, but already did that
 for all protocol versions).

But I would really like see a more robust TLSv1.1 negotiation
being standardized, because I don't see sending
ClientHello.client_version = { 0x03, 0x02 } as a viable option
due to the known interop problems for some more years.


-Martin