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

[Bodo Moeller <[e-mail]>]

Andrei Popov <[e-mail]>:


> In any case, the client app has a workaround (which is to not send the
> downgrade SCSV when skipping TLS versions).


Well, that could sometimes be acceptable. Or do send the downgrade SCSV for
the version that you want to skip just to confirm that it's this server's
highest supported protocol, and then just use the previous version instead
(in a new connection). There's an extra latency penalty in this, but I
consider this version-skipping scenario very unlikely and we haven't ever
bothered to address this in standard version negotiation either (the client
can't send a list of supported protocol versions) and so have a similar
latency penalty there, so I don't think we should consider this a serious
drawback.

This workaround is far from perfect, but I can live with the current
> downgrade-scsv draft if I have to. In this case, the fix is pretty trivial,
> so I thought it was worth bringing this up.


You mean, version-specific SCSVs? I'd rather not do that, because then
there's much more to do (and possibly get wrong) in servers. And even if we
allocate a bunch of SCSVs for future protocol versions, at some point we
might run out.


(As an aside, if latency is the utmost concern, you don't strictly have to
try protocol versions in sequence -- you could do multiple connections in
parallel. However, that shouldn't be the norm. We *do* have version
negotiation in the protocol, after all. We shouldn't forget that the entire
fallback business is about servers that aren't just up to date with the
latest protocol version, but are exceptionally broken on top of that.)

Bodo