Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Bodo Moeller <[e-mail]>]

>
> > However, this issue really just follows from the relevant language in the
> > TLS RFCs: "Whenever a client already knows the highest protocol version
> > known to a server (for example, when resuming a session), it SHOULD
> initiate
> > the connection in that native protocol." If the client follows these
> > directions, using the old protocol version even in case the server gets
> > upgraded is expected.
>


> I agree. But, my conclusion is that the TLS specification is wrong,
>

Got it; sorry for being slow.

Here's one way to write that.

"If a client sends a ClientHello.client_version containing a lower value
than the latest (highest-valued) version supported by the client, it SHOULD
include the TLS_FALLBACK_SCSV cipher suite value in
ClientHello.cipher_suites. (...)

Sometimes, a client assuming that it already knows the highest protocol
version supported by a server (such as when resuming a session) may
initiate the connection in that native protocol as per Appendix E.1 of
[RFC5246]. In this situation, as an exception to the above, the client MUST
NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites (unless it
downgrades ClientHello.client_version further in additional connection
attempts), since server-side support of protocol versions may have changed
since the previous connection.

(To avoid perpetuating use of an earlier protocol version if the server in
question actually does get updated, such clients SHOULD time out knowledge
of the highest protocol version supported by the server. Also, any such
knowledge MUST be forgotten if the server ever sends an
inappropriate_fallback alert.)"

Bodo