Re: [TLS] checking on an scsv point

[Henrik Grubbström <[e-mail]>]

On Tue, Feb 17, 2015 at 11:25 PM, Stephen Farrell
<[e-mail]> wrote:
[...]
> 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).

I consider breaking the obviously broken intervening proxy a feature,
as it obviously is broken enough that plain recent TLS doesn't work
with it (as otherwise the downgrade wouldn't have been needed), as it
would make it obvious to the system maintainer that something is
wrong. Hiding broken code behind workarounds like the suggested is
almost never a good idea.

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.

> 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, 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. I suspect the most common failure is a
protocol_version alert.

-- 
Henrik Grubbström                                       [e-mail]
Roxen Internet Software AB                              [e-mail]