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

[Bodo Moeller <[e-mail]>]

>
>
> > *Could* fail, sorry. (As already explained by Martin, the problem
> appears if
> > by the time you try to resume, the server supports additional protocol
> > versions. Of course that could also happen for an immediate retry, and
> > you'll have to live with it then; so I wonder if that "MUST" isn't too
> > strict after all: if you're willing to start over on
> inappropriate_fallback,
> > you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a
> > connection failure if the server has been updated.)
>


> Right. In general, a resumption ClientHello SHOULD be just like a
> non-resumption ClientHello, except for the presence of the session ID
> and/or session ticket, because a resumption ClientHello is potentially
> the start of a full handshake.
>
> The TLS specs (TLS 1.2, in this case) say:
>
>    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.
>
> However, actually the client does not ever know the highest protocol
> version the server supports, because the server may have expanded its
> version support since the last time the client contacted it. But, the
> consequence of that sentence is that at least NSS sends the session
> version as client_version instead of its actual max supported version.
> I think that is wrong.


Well, arguably it is, but at least if you had to do an additional fallback
handshake just to successfully complete a handshake (which is the situation
we unfortunately have to concern us with here), you probably wouldn't want
to repeat this trial-and-error on every session resumption.

So if we accept that fallback handshakes can be a necessity, we also have
to accept that lowered client_version on resumption as a fact of life.




> So, it may be
> the case that it is already safe to always send the max supported
> version as client_version in an initial resumption handshake, without
> any indication from the server, even in the non-secure fallback case.


If the server is version-intolerant for new sessions, why would it be
tolerant on (attempted) resumption?

Bodo