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.

This would also allow clients (browsers probably) to gather real data
> on potentially incorrect fallbacks, [...]


And it would then be a decision of the (fallback-performing) clients
> whether and when to start hard-failing, once they've sorted out their
> connection management and figured out how to deal with false positives
> in their fallback heuristics.
>

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

Bodo