Re: [TLS] Minutes from Tuesday

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:


> >> Rather than aborthing the TLS handshake, the server ought to include
> >> a TLS extension in the ServerHello indicating that he recognized a
> >> potentially inappropriate fallback and otherwise continue the TLS
> handshake
> >> in the regular fashion, leaving the decision of whether&how to continue
> >> entirely up to those clients who do perform insecure fallbacks.
>


> > That would work too, but the server would then be doing all the work to
> > send a ServerKeyExchange even if the client is going to abort the
> > connection.
>


> I do believe the server load issue here to be sufficiently close to
> marginal to be irrelevant.
>

Normally, yes (after all, TLS_FALLBACK_SCSV isn't expected to be seen *at
all* as long as everything works well). The kind of scenario I'm thinking
of is one with clients on bad wireless networks, which can lead to rather
frequent spurious handshake failures followed by (inappropriate) fallback
retries.  I just don't think that the additional benefit (per connection)
is worth the additional computational effort (per connection), and the
extra latency: for many clients, there is *no* additional benefit at all.

I'm also concerned about the mechanism being more error-prone if servers
don't respond with a fatal alert.  If it's a warning alert (or other
signal) instead, clients will require additional code to handle this
properly, whereas reacting to a fatal alert is something that all TLS
implementations already know how to do.

We could create a client-side signal that allows the client to specify the
desired AlertLevel, but this again would add further complexity to the
protocol (by making server behavior more complex).


The problem with having the server (rather than the falling-back client)
> abort the connection is that the client has no reliable indicator to
> figure out the reason for connection failures,


You have the fatal alert telling you that the current protocol version with
TLS_FALLBACK_SCSV wasn't right.


> It seems that the response mechanism that you propose would allow the
> > server to confirm to that client that the server noticed that the client
> > noticed that something is wrong. What would really be gained by that,
> > compared to what the current TLS_FALLBACK_SCSV protocol offers?
>


> It would leave the decision whether to abort or continue the handshake
> with the one-and-only connection peer that is (a) doing the fallback
> and (b) in the position to establish another connection and attempt
> another handshake, and (c) query the user interactively if something
> odd is going on.
>

You can basically do the same thing with the TLS_FALLBACK_SCSV mechanism,
it just may require an additional connection.

Fallback retries always *are* a kludge, hence I want to keep the
TLS_FALLBACK_SCSV mechanism very simple and easy to support rather than
optimizing for special scenarios.

Bodo