Re: [TLS] Proposal for hybrid solution using most of the ideas

[Nasko Oskov <noskov at microsoft.com>]

Yngve N. Pettersen wrote:
>Hello Nasko,
>
>Let me see if I read this correctly:
>
>  - For TLS with Extensions, use the RI extension? Is that right? Or
>  another signaling extension?

For TLS we should always be using extensions. RI is the initial proposal
that I had, but if we are fixing SSLv3 I suggest we alter it a bit to allow
for common code between SSLv3 and TLS.

>  - For SSLv3/TLS without Extensions use the special cipher. Only in this
>  case, or also when the Extension is used, just in case a non-Extension
>  server tolerates Extension (it IS known to happen occasionally), but do
>  understand the cipher?

Ciphersuite is only used in SSLv3. I propose that if apps (mostly browsers)
fall back when connecting to TLS servers that don't tolerate extensions,
instead of falling back to TLS without extensions (insecure) they fall back
to SSLv3 (which we should be fixing too).

>  - If the server understand RI, it uses that

If the server is to use the TLS protocol, yes.

>  - If it does not understand the RI, but the cipher, send the special certificate

If the server has chosen the TLS protocol, don't use any of the workarounds
suggested, just use RI and either allow unpatched clients or not based on
configuration.

>Correct so far?

I hope that clarifies it.

>If so, provided that this is always done for all the Client's Hellos, also
>the first on the connection (I got an impression from your email that this
>was not required, which could cause problems for first handshakes) I think
>it should work (though some will say it is too complex, but with this kind
>of legacy issues you can't fix a problem like this in a simple way).

Signaling (whether with extensions or not) should be present always in
initial ClientHellos.

>The reason the RI/fallback must be used on the first negotiation is, aside
>from the MITM attack, that I as a client need to be able to tell up front
>what I am dealing with, whether to include information in the Security
>information, adjust security levels, display a warning dialog, or refuse to
>connect to an unpatched server. I can't wait for a possible renegotiation.

Correct. We should be signaling on initial handshaking for sure. What
changes in the renegotiation case is how the Finished message is computed.

>Mike was concerned about session resume, but I do not think that is a real
>issue, since we already know the parameters of the server by this time:
>
>   - If the server is using RI, the check will be part of the Hellos
>   - If the server is using the fallback, we already know that it does (it
>     is part of the TLS Session information) and modify the Finished
>     calculations accordingly.
>   - If it is using neither, then we also know that, and does not enable
>     the modified Finished calculation mode.
>
>The S->C signaling is only needed during a full negotiation, while the  
>C->S signaling is needed each Hello since the server might not want to
>resume a session.

What I was exploring is whether we can signal S->C in any other message.
After trying to use the Server Finished and discussing it with Marsh, I
realized that we don't prevent the attack unless we signal *before* the
server generates the Server Finished.

>Mike do have a point about the cipher suites that does not use
>certificates. I am not too concerned about the Anonymous ciphers (they are
>too vulnerable anyway), but there are IIRC several suites relying on
>different key exchange methods than PKI (though not supported by Opera).

That could very well be a problem that I might have missed.

What I might have missed to communicate is the following main ideas:

* We have to fix SSLv3 and this will require changing the Finished message
  calculation (either that or disable fallback to it, which is infeasible in
  the medum term)
* If we were to do the SSLv3 change, to minimize changes overall, the
  approach for TLS could use this change and use the extension mechanism for
  signaling only (without transporting the data).
* Certificate message could be used as S->C signaling, since it is variable
  by default, most likely intermediate devices (firewall, IDS, so on) are
  not inspecting the validity of if (I doubt firewalls do chain
  verification) and as such it is less likely to have interop issues. We
  know the endpoints will handle it properly because they will be patched. I
  am worried about devices that are not upgraded dropping messages because
  of unknown contents.

Nasko