Re: [TLS] Protected Renegotiation -- refined proposal

[Martin Rex <[e-mail]>]

Eric,

Maybe you remember my privat Email to Steve and Marsh (you were cc)
3 hours after I had posted my observation about the MITM susceptibility
of the TLS renegotiation:


  An approach to fixing the situation would be to use a TLS extension
  to securely identify the session that is to be renegotiated.

  Fixed clients would have to identify the TLS session that they
  want to renegotiate.  Once the fixed clients are shipped, the
  fixed servers can require clients to identify the to-be-renegotiated
  session and abort if they don't.

  In the initial in-the-clear TLS-handshake, the clients should indicate
  with this extension (and and empty extension data) that the clients
  supports secure renegotiation, so that the server may defer the
  sending of a ClientCertificateRequest in the initial handshake
  to a later renegotiation.

This matches the TLS extension RI that you published the next day.


Cryptographically, the approach of the TLS extension RI looks fine,
but I having thought about it for a few days, I really dislike
how this fix is integrated into the protocol.


The lack of protection of the renegotiation is a flaw of the SSL/TLS
base protocol, and so it REALLY should be fixed there.  If the
original SSL protocol had used different finished calculations for
initial and renegotiate handshakes, then we wouldn't have the
problem that a clients initial handshake can be proxied into the
renegotiation of the server.

Now that we know that this was a stupid mistake, we should not
continue with this mistake.  The original TLS renegotiation is
a security problem and should be entirely abandoned.

Changing the finished message calculation for the TLS renegotiation
by virtually adding the verify_data from the currents session finished
messages to the handshake messages (hashes) of the renegotiation
handshake is the most natural solution.  There really is no point
in wasting the network bandwith and send the verify_data over the
network.

What we should add to the protocol is the signaling of this protocol
change Client->Server and Server->Client through the ClientHello
and ServerHello handshake messages.  The most interoperable signaling
C->S is a specially assigned ciphersuites ID, we probably do not need
to discuss that.  I'm open to sugestions for the S->C signaling.
Since the Server will signal only when he sees the clients signal
in the ClientHello, you could at that point actually change the
ServerHello message.  Changing the ServerHello is NOT going to
break anything here!

IMNSHO the IETF should _NOT_ continue to support the insecure original
TLS renegotiation, the implementors can decide themselves whether they
want to or need to offer their customers that configuration option
and use the original Finished message calculation if the negotiation
(=signaling C->S and S->C) indicates that at least one of the peers
has not been updated.  


TLS v1.3 should REALLY require that only the modified finished
message calculation may be used for TLS renegotiation.  Supporting
the original TLS renegotiation in TLS v1.3 would be unreasonable,
and if we use the TLS extension RI, then we would have to keep
that band-aid forever wasting network bandwidth.


And all those vendors and implementors who have added a reconnect-fallback
to their TLS clients,

  - I do not want the IETF recommend them to trash this fallback
  - I do not want the IETF leave the fallback handshake unprotected

If we do NOT use the TLS extension RI on the initial handshake, but
instead a different signaling, then both of this is unnecessary,
the vendors can have their TLS client still signal and use the
protected renegotiation, encounter less connection drops and the
ability to produce better error messages.


I do admit that tunneling the Finished Messages through TLS extensions
in ClientHello and ServerHello into the Handshake message hash might
require ~20 lines of code less for TLS implementations that already
implement the extensions code.  Personally, I think the un-usability
that comes with a strict requirement for TLS extensions and the
uncertainty for the fallbacks, the impaired error reporting and
the waste of network bandwidth saves the consumers of this
technology MUCH MUCH more every day in the future.

And every implementer that doesn't have TLS extensions all of the codebase
that he maintains will have to add much more for tls extensions than
for the actual fix.



I guess, I will have to write an I-D so that we can let the
community decide (this probably is no longer an TLS WG internal
decision, because it affects the internet as a whole).


-Martin