Re: [TLS] checking on an scsv point

[Martin Thomson <[e-mail]>]

FWIW, I just checked and an NSS client would fail the handshake if a
server did this.  We'd probably need new configuration to avoid the
"upgrade attack" if this were permitted.

On 18 February 2015 at 09:25, Stephen Farrell <[e-mail]> wrote:
>
> 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)
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls