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

[Brian Smith <[e-mail]>]

On Fri, Oct 10, 2014 at 12:52 PM, Bodo Moeller <[e-mail]> wrote:
> (Given that the protocol version has previously been negotiated
> between the client and server, TLS_FALLBACK_SCSV is only
> expected to have an effect if the server has since been updated
> to support higher versions. Omitting TLS_FALLBACK_SCSV
> lets the client continue to use the previously negotiated protocol
> version. Sending TLS_FALLBACK_SCSV, in contrast, could lead
> to an inappropriate_fallback alert if the client should start anew
> to create a new session using the new highest protocol version.)"

Let's review the scenerio in detail:

1. Client attempts handshake with client_version == TLS 1.2, and the
handshake fails.
2. Client attempts handshake with client_version == TLS 1.1, and the
handshake succeeds, with both sides saving the session information.
3. Server is upgraded to support TLS 1.2 or higher.
4. Client attempts to handshake with client_version == TLS 1.1 and a
resumed session ticket.

There are four cases to consider:

CASE 1: Client included the TLS_FALLBACK_SCSV, server forgot session
state when it was upgraded. The result is an inappropriate_fallback
alert.

CASE 2: Client included the TLS_FALLBACK_SCSV, server (magically!!!)
retained the session state across the server software upgrade. The
result is an inappropriate_fallback alert.

CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
forgot session state when it was upgraded. The server starts a new TLS
1.1 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

CASE 4: Client did not include the TLS_FALLBACK_SCSV, the server
(magically!!!) retained the session state across the software upgrade.
The server resumes the TLS 1.1 session instead of starting a new TLS
1.2 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

> Previously I'd assumed you'd want to keep "normal" behavior (simply continue
> to use the previous protocol version), but I don't see a compelling reason
> for the specification to prescribe that to clients.

Doing that also allows version downgrade to succeed inappropriately in
the case where the server's capabilities were improved during the
lifetime of a session cached by a client.

I think the best solution is to take my original suggestion (i.e. keep
the current logic, but make it more clear), and also suggest that,
after the client has received an inappropriate_fallback alert, the
client SHOULD forget what it has learned about what the server's
version tolerance and cached sessions, and retry its version
intolerance logic over, taking care not to get into an infinite loop
in the even that it receives another inappropriate_fallback alert when
it retries.

I think it is realistic to expect that servers that implement the
inappropriate_fallback logic to implement at least TLS 1.2 (or at
least TLS 1.1), so you could also suggest that the client MUST (not
just SHOULD) send always send TLS_FALLBACK_SCSV when it negotiates TLS
1.1 or lower, because the "deployment of a new protocol version"
consideration does not apply for those versions.

If for some reason this cannot be done, then at a minimum the security
considerations need to be expanded to document that downgrade is still
possible in CASE 3 and CASE 4 above.

Cheers,
Brian