Re: [TLS] Minutes from Tuesday

[[e-mail] (Martin Rex)]

Bodo Moeller wrote:
>
> 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.

Even you write somthing to this effect:

> 
> Well, even just having to fall back to make the connection work indicates
> that something is wrong -- that's not a generally expected way of
> establishing a TLS connection. (Clients can gather some statistics without
> sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)

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,  and have to continue
relying on flawed heuristics.  MSIE has a similar bug in connection
management that FF used to have over several years (and which could often
be observed/reproduced by by hitting <F5> ("reload") quickly several
times on complex pages).  On MSIE, I saw it as a result of complex
pages with Javascript-based navigation that performed (and killed)
background downloading of images.


>
> 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.


I would gladly add a server extension into ServerHello of our TLS
implementation in response to a FALLBACK SCSV, whereas I will entirely
ignore this proposal as is.


-Martin