Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Salz, Rich wrote:
> I read your note very carefully.
> It is a nice detailed list of things that could be improved.

Permitting the server to continue the TLS handshake with
ServerHello.server_version = (ClientHello.client_version +1)

This would be an extremely small change, but a *HUGE* improvement to this
proposal and make TLS handshakes _succeed_, i.e. promote interop.
Should a TLS client be unsatisfied with the properties of the resulting
TLS session, that client could still decide attempting a new/different
handshake by proposing additional features in ClientHello (that should
have never been absent from ClientHello in the first place).

And this improvement is something that I could imagine implementing
for our servers -- other than the currently specified knee-jerk-reaction.


> 
> But I see no elucidation of any massive serious operational problems.
> The I-D section you pointed to contains an answer.

The current last call is a request to rubber-stamp the current
fallback-scsv proposal, that wants to require from the server
an unconditional knee-jerk-reaction and complete interop failure,
onto the standards track.

It is difficult to conceive a proposal that violates rfc2116 section 6
in a more serious fashion than the current fallback-scsv proposal --
and fixing this would be trivial (see above).


It's not that suggestions to improvement to this proposal haven't been
made.  It's really disappointing to see this go _through_ the TLS WG
and not seeing any improvement whatsoever, and then going straight
to asking for rubber-stamping it.


http://www.ietf.org/mail-archive/web/tls/current/msg11238.html
http://www.ietf.org/mail-archive/web/tls/current/msg11221.html



>
> Many large network operators have rolled this out, and the net has
> been pretty silent about any "tales of woe."


If all of the parties that you care for already have this implemented,
then there is no need to puslish this proposal on the standards track
any more.  So we don't have to find out how others implement this.


I can easily remember the unfortunate outcome the last time that
the TLS WG asked for anal behaviour (RSA premaster secret version check)
and how much interop problems this caused in the installed base
because one vendor decided to ship this unvalidated:

  http://www.ietf.org/mail-archive/web/tls/current/msg11226.html

This particular handshake failure flaw has is known for > 3 years,
and still has not been fixed on the platform that has by far the
largest market share...


No, I am *NOT* in favour of the IESG rubber-stamping another proposal
for TLS handshake failures, when the alternative, allowing a handshake
complete with better properties (such as suggested at the beginning
of this message) will be trivial to achieve. 




Several implementers may be in the fortunate position to ignore or
laugh at most end-users that see error messages or white pages in
their browsers.

And the firefox bug with the brittle client-side connection management
that caused fallbacks to SSLv3 all by itself over several years:
   https://bugzilla.mozilla.org/show_bug.cgi?id=450280

is a good example of this.


I'm not in such a position.  We take support seriously, and we try
to actually help customers overcome interoperability problems, even
when such interop problems are caused by third party software or
network middle-boxes.  (We don't actually fix third-party software,
but I do the analysis sufficiently thorough so that customers request
patches for clear defects from the relevant vendors).



-Martin