Re: [TLS] checking on an scsv point

[[e-mail] (Martin Rex)]

Henrik Grubbström wrote:
> 
> I also fail to see how you can call this less complex and without new
> connection establishment, as for the FALLBACK_SCSV to have been
> asserted there will already have been a reconnect.

Just using a connection established with
(ClientHello.client_version+1) will be less complexity for
clients (that implement this alternative behaviour properly)
because the app will not have to establish a new connection
and go through the entire app-level protocol preparations again
(HTTP CONNECT proxy and/or STARTTLS prologue)

> 
> > 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
> 
> Yes, this will break (probably most) early adopters,

In which way does it "break" early adopters.
The fatal alert will unconditionally result in complete interop
failure on the established connection.  The "worst" that could possibly
happen is a "different kind of complete interop failure" but an interop
failure is an interop failure is an interop failure.  So really, making
it worse for the current handshake is factually impossible.

>
> as good practice in applications (especially those involving crypto)
> is to validate that all parameters are within the expected range,
> and it isn't allowed for a server to bump the protocol version above
> what the client requested.

It was the CLIENT(!!) who asserted the FALLBACK_SCSV in the first
place, complaining loudly that it would really like to use a higher
TLS protocol version that what the client placed into
ClientHello.client_version, so this reasoning is bogus here.


>
> I suspect the most common failure is a protocol_version alert.

The whole proposal started because the client believes that the
protocol options that the server negotiates would be options that
the client rather does not want.  So what kind of alert the client
sends if it wants to abort the current handshake and start a new one,
doesn't really matter for the server here.

What matters is that the server does not have to take the blame for
the handshake failure.  This will be left to the client, who started
the FALLBACK_SCSV dance.  For this particular connection, the server
has the necessary state to make this handshake failure "soft"
(i.e. not stand out in the traces), when the client aborts in response
to the servers selection of
  ServerHello.server_version = (ClientHello.client_version+1)

so I really don't mind such a client behaviour.

Servers not implementing the alternative approach do not have to bother
about this outcome.


-Martin