Re: [TLS] TLS versions when renegotiating...

[Yoav Nir <ynir at checkpoint.com>]

Hi.

I don't think that any sane reading of RFC 5246 (or 2246) can lead us to any conclusion other than a.

Personally, I think the solution for the server is to accept in the ClientKeyExchange all version numbers at least equal to its highest supported version. So in that example, we would accept 3.1, 3.2, 3.3, or even 3.99, but not 3.0.

Downgrade attacks are still thwarted (although the hash in the Finished message does that as well), but upgrade attacks are not. Are we worried about upgrade attacks?  I think not.

Yoav

On Feb 9, 2012, at 6:13 PM, Dr Stephen Henson wrote:

> While performing interop testing with some servers an issue arose relating to
> renegotiation and TLS clients supporting TLS 1.1 or later and servers only
> supporting 1.0.
> 
> One scenario is this:
> 
> 1. Client connects using compatible client hello indicating maximum version
>   of TLS 1.2.
> 2. Server only supports TLS 1.0 so sends back server hello containing version
>   1.0. RSA key exchange ciphersuite indicated.
> 3. Connection proceeds using TLS 1.0 with client using maximum supported
>   version of 1.2 in RSA encrypted premaster secret.
> 
> All fine so far. Now suppose the connection renegotiates (e.g. we requested a
> URL needing client authentication). It might go like this...
> 
> 4. Server sends hello request requesting renegotiation.
> 5. Client sends client hello containing version 1.0 this time as we know that
>   is all the server supports.
> 6. Connection proceeds using TLS v1.0.
> 
> Question is: what version should go in the RSA encrypted premaster secret?
> 
> Possible answers:
> 
> a. Same value as in the corresponding client hello for that handshake as that
>   is the maximum version we will permit i.e. 1.0.
> b. Be consistent with initial client hello and use 1.2 as that is the maximum
>   version we support.
> 
> The problem is whichever one you choose some widely deployed servers will choke
> on it.
> 
> The servers which choke on (a) work fine if RSA key exchange is not used but
> they seem to prioritise RSA key exhchange ciphersuites even if others have
> precedence in the client hello.
> 
> My current workaround is to avoid the client hello with version 1.0 when
> renegotiating and use a compatible client hello using version 1.2 and keeping
> that in the RSA encrypted premaster secret.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shenson at drh-consultancy.co.uk, PGP key: via homepage.
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> Scanned by Check Point Total Security Gateway.