Re: [TLS] checking on an scsv point

[David Benjamin <[e-mail]>]

On Tue Feb 17 2015 at 6:10:55 PM Martin Rex <[e-mail]> wrote:

> This NSS behaviour is not necessarily a problem.  The more "interesting"
> question is what the app callers above NSS, that have asked NSS to
> include FALLBACK_SCSV, will do in response to that behaviour of NSS,
> or more specifically, will they do the same that they would do in
> response of a fatal invalid_downgrade alert.
>
> But that is a question for the apps on top rather than for NSS.
>

Chrome will not treat those the same in either NSS or BoringSSL ports.

It'll look like either a generic protocol error or a bad ServerHello
version (not sure which on NSS, but it doesn't matter), both of which
continue the fallback chain. An inappropriate_fallback alert terminates the
fallback chain and restores the original attempt's error code. (So the
error code is reported as if there were no version fallback.)

I don't really care for adding complexity to support this, either in
BoringSSL's server bits or Chrome. I'm especially uninterested in accepting
a client_version+1 ServerHello. It opens up questions with
client_version-conditioned extensions (signature_algorithms) and isn't a
secure version negotiation. FALLBACK_SCSV implies I support
client_version+1 but doesn't imply that I do NOT support client_version+2.

David