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

[Bodo Moeller <[e-mail]>]

Brian Smith <[e-mail]>:

[...]

> 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 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.
>

Right, this is the most problematic case. Resuming a session using the old
protocol version (if the server still recognizes that session) is one
thing, but using the old version for a new session is another.

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.


> 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),


Now I'm a bit confused. If you consider that consequence (using the old
version if server capabilities have improved since) "improper", why do you
suggest keeping the current logic?




> 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),


I'm not so sure -- the TLS_FALLBACK_SCSV mechanism by design works equally
well with TLS 1.0 and can be easily retrofitted at least in principle.
Thus, to allow essentially *every* implementation to benefit from the SCSV,
I wouldn't want to require any higher version.

Boo