[TLS] checking on an scsv point

[Stephen Farrell <[e-mail]>]

Hiya,

In going over the threads on this I think there was one point of
Martin's where it wasn't clear to me that the WG considered his
proposal. That might be because it was raised just before the
holidays and was part of a mega-thread and fairly deeply embedded
in a longer message. Anyway, I asked Martin if he could describe
it better and he did (see below) so I'd like to just check that
the WG don't in fact want this.

If you do not want to make this change, silence if fine, but if
you would implement this in your TLS stack then please say so in
the next few days. (Pretty please: let's not side-track - I'm
really only looking for "yes, I'd implement that in my TLS
code" responses, or silence:-)

I figure it's not likely that the WG will want this, but if
there's a groundswell for doing it, we can handle the process
stuff, so don't worry about that.

Thanks,
S.

What I've been asking for time and time again is allowing (adding)
an additional/alternative server behaviour, which a TLS (server)
implementer will be _allowed_ to implement instead of a fatal
handshake failure.

The most simplistic alternative server behaviour would be for
the server to continue the handshake successfully, using

ServerHello.server_version = (ClientHello.client_version + 1)

i.e. negotiating a _higher_ TLS version instead of aborting the
TLS handshake with a fatal error.

A client (and this affects only the clients that assert the
FALLBACK_SCSV) will be able to recognize that the server supports a
higher TLS protocol version than what the TLS client proposed in
ClientHello.client_version, and it will be left to that client to
decide whether the resulting TLS session properties are OK, or wether
the client want to take chances, establishing a new connection,
starting a new handshake and proposing other/additional TLS protocol
features in ClientHello that it might have omitted (for whatever
reason) in the last ClientHello.

This alternative behaviour is better, because it provides actual
*interoperability* between TLS client and TLS server -- and in many
cases the same or reasonably secure TLS session properties without
the need for complex heuristics and a whole new connection establishment
and handshake through the entire application protocol stack
(such as HTTP CONNECT proxy traversals or the stuff before STARTTLS).

Keep in mind that I'm NOT asking to make early adopter servers(!)
non-compliant.  Admittedly, I don't know what exactly the early
adopting clients will currently do when they receive

   ServerHello.server_version = (ClientHello.client_version + 1)