Re: [TLS] Quest for Unified Solution to TLS Renegotiation

[Kyle Hamilton <[e-mail]>]

On Wed, Nov 25, 2009 at 2:54 PM, Eric Rescorla <[e-mail]> wrote:
>>    3) Incorporate previous verify_data into Finished calc.
>
> I'm not happy with this, actually.
>
> This requires breaking the current clean definition of handshake
> hashes as the hash of all the handshake messages and simply adding
> some synthetic message in the middle. I don't think this is anywhere
> near as clean, as evidenced by the ongoing debate about whether to put
> it the synthetic data in the front, the back, incorporate it into the
> PRF, or chain the pre-existing handshake messages. [FWIW, I think I
> prefer the last of these implicit versions.]

I would prefer to think in terms of "save the handshake hash values
after you verify them in Finished processing".  This would allow them
to be used as (essentially) initialization vectors for the next set of
handshake messages, thus providing "Message Authentication Code
continuity".  (The reason the attack works is because the server
doesn't properly authenticate the message, and the client can't know
that anything untoward happened.  The server doesn't chain any
information from the prior handshake into the current handshake, the
client doesn't chain any information from the prior handshake into the
current handshake, and there's no way for either the server or client
to tell the other exactly which negotiation epoch it thinks it's on.
If the prior handshake's information isn't chained in, from a security
standpoint it appears to be the same outcome as not verifying the MAC
on any given record.)  There shouldn't need to be any additional
verify_data sent, since all the information for ensuring that the same
client is talking with the same server is in those hashes.

So, potential ways to resolve this include:

1) including a 'negotiation epoch' in the handshake (if the server
thinks this is the first renegotiation, it's going to expect that the
epoch received from the client would be 1, not 0... and same for
subsequent negotiations).
2) Chain the last Finished hashes (NOT the master_secret or any key
material) as the initialization vector for the next handshake's
Finished MAC calculation.  (If you think about it, this is pretty much
the same as an epoch-based system, with each epoch 'named' by a
semi-random string of bits.)  Include the IV'd MAC as a field in the
Finished structure, and keep the current MAC calculation in place
(simply to simplify the lives of the vendors) -- which provides a
useful safety net: if they are the same, it's epoch 0, and if they're
not, it's not.

Now that we have some idea of how to authenticate the new session as
being an outgrowth of the prior, we now need to provide a means for
clients and servers that do this to notify each other that they're
using the modified handshake message algorithm.  We have on the table:

A) Secure Renegotiation Indicator TLS extension.
B) Magic cipher_suite.
C) Bit-fiddled version identifiers.

We are constrained by the following:

1) The mechanism for signalling must not screw up the protocol steps
for unpatched libraries.
2) The mechanism for signalling must be backward-compatible to SSLv3
(this is my interpretation of what the Area Director stated; please
correct me if I am wrong).

Because of constraint number 2, option A cannot be the mandated
mechanism for the client to signal the server that it supports
renegotiation continuity.  It is absolutely daft to try to turn an
integer into a bitfield, so option C is pretty much insane (and is
also fairly incompatible with DTLS, since its version is a
2s-complement of the TLS version it's based on).  This leaves option B
as the only sane mechanism that meets both constraints, for the client
to signal the server.

However, once the protocol is patched, it can be patched in any manner
the TLS group defines (and the TLS group has dominion over SSLv3, by
default, too).  So, the client's signal can tell the server that it's
okay to use a slightly different Finished message, no matter which
protocol version it's using -- one that includes a specific sequence
of bytes (a "magic number", if you will) after the end of the normal
Finished message.

Now, define the hash/PRF to have IVs of the prior iteration's Finished
hashes (each side has its own hash, so there's [a cryptographic
question: is there a reason to include both Finished hashes as IV
input to both the Server and the Client calculations?  Or should it be
sufficient to only include that side's prior hash?]  (the initial
vector for the first one is all bits clear), and you have a verifiable
chain of channel "ownership".

Am I misunderstanding the situation here?

> By contrast, RI allows that part of the system (which is well
> understood) to remain the same and in fact when RI is offered on the
> first handshake, there is no change to the TLS core at all. It's all
> just hashed into Finished as part of the ordinary TLS procedures,
> and everything is in fact compliant TLS, which I think is desirable.

The problem is this: all vendors -- not just a single vendor -- need
to be able to implement whatever's here *quickly*.  They need to do it
not just for TLS, but also for That Pre-TLS Protocol That Refuses To
Die.  There's no reason to change one in a manner that's incompatible
with the change made to the other.  (SSLv3 needs the magic cipher
suite, and that means that servers are going to have to support it if
they want to talk to even IE7 (which, IIRC, enabled SSLv3 but not
TLSv1.0).  SSLv3 ClientHello is still going to be used, and relying
only on an RI extension fails to support it.  Thus, it's pretty much a
non-starter.

As the Area Director has stated, the IETF is in this to ensure that
the network *works*, not to adhere to some ideologically 'pure'
concept.  SSLv3 is, unfortunately, going to have to be supported --
because if we suddenly break 75% of the clients on the network, not
only the users but IT admins and CTOs alike are going to be *pissed*.

An "unsolicited" empty RI extension from the server when it sees the
magic cipher_suite is probably the cleanest way to insert the
signalling required for any defense against the attack to work... the
server would not send it unless the client sent the magic ciphersuite
(or, following the TLS Extensions model, if the client offered it as
an extension during negotiation).  An unpatched server won't send the
RI extension even if the client sends the magic cipher_suite, so the
client should know not to renegotiate.  An unpatched client won't send
either the magic cipher_suite or the RI extension, so the server
should know not to renegotiate (and thus won't send the RI extension
-- again following the extensions model, with an addendum that the RI
extension is the only one that can be requested with a magic
cipher_suite being prepended to the actual list of ciphers that the
client's willing to use).

> I appreciate that this is to some extent a matter of tradeoffs,
> but I don't find the arguments in favor of the implicit version
> very compelling when weighed against the above.

"Implicit version"?  There is no "implicit version" in the
Moeller/D'Errico proposal.  The version structure is never touched at
all.

-Kyle H