Subject: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt

From: Kyle Hamilton <[email-masked]>
Date: Tue, 24 Nov 2009 15:22:57 -0800

I hadn't actually read this before I wrote my last message.  It
includes both of the aspects that I stated were necessary (a TLS
extension and a magic cipher identifier), and I support it.

4.3.1:
Clients which choose to fall back to an extensionless mode of
   operation MUST include the magic cipher suite [TBD] in any such
   handshake.  Servers MUST reject any ClientHello which uses this
   cipher suite but does not include RI with a fatal "handshake_failure"
   alert.  Because servers ordinarily ignore unknown cipher suites, this
   cipher suite can be added safely on any handshake, thus allowing
   detection and prevention of the MITM attack described above.

This is absolutely essential.  TLS extensions exist, but SSL 3 is
still commonly used.  There's no reason why SSL 3 shouldn't benefit
from anything that happens after-the-fact, even though it was never an
actual IETF protocol.

The only issue I see is... we've got an issue in signalling back to
the client that it knows how to do the updated handshake.  Would a
slightly modified HelloRequest do it?

-Kyle H

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Nov 2009 17:55:16 -0600

> from anything that happens after-the-fact, even though it was never an

There is no fixing re-negotiation without protocol changes.

As far as SSLv3 goes the only real issue is: how hard are protocol
changes to implement?  (And that's assuming that there are SSLv3
implementors who will bother patching, as opposed to telling their
customers to just upgrade.)

> slightly modified HelloRequest do it?

For initial negotiations:

 - The C->S signal has to be a client hello extension.

 - The S->C signal can be either or both of a server hello extension
   and/or a server Finished message verify_data computation change.

   (Note that either way you can fallback on unsafe behavior, if you
   like.)

We do need signalling in both directions during the initial
negotiations.

For re-negotiations:

 - No signal is needed -- just modify the client and server Finished
   message verify_data computation to include a channel binding.

    - The RI proposal does this via hello extensions carrying parts of
      the channel binding, which indirectly gets them into the Finished
      message verify_data computation.

      The advantage to the RI approach is that if you have a TLS 1.1+
      stack then this change just fits the existing extensibility model
      that the stack was written for.

      The disadvantages to the RI approach are: it doesn't fit as well
      for pre-TLS 1.1 implementations, and, more importantly, it
      requires that the peers check the hello extension data sent.
      Whereas just adding the data to the verify_data computation
      without actually sending doesn't require any such checking.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 01:34:21 +0100 (MET)

> slightly modified HelloRequest do it?

Aha.  Someone noticed that the S->C signaling is missing.

I suggest using a bit in ServerHello.server_version.

So far, the magic cipher suite idea in TLS extension RI
is a "solution" to the downgrade vulnerability
from the automatic reconnect fallback in TLS clients.

So as far as SSLv3 support is concern, TLS extension RI
is still firmly determined to exterminate SSLv3  and with the
magic cipher suite, it'll kill conservative TLS clients along with it.

-Martin

---

From: Kyle Hamilton <[email-masked]>
Date: Wed, 25 Nov 2009 10:20:10 -0800

> I suggest using a bit in ServerHello.server_version.

I don't think that many conforming clients are going to be okay with
that, since they're sending {0x03 0x04}, and you're having the server
send back {0x83 0x04} or {0x03 0x84}.

The spec of TLS 1.0 implies that the client SHOULD terminate the
connection if it receives back a higher major version number (or minor
version number) than it was expecting.  It is specified as "the lower
of the client-suggested protocol version, and the protocol version
supported by the server".  It would be very easy to (falsely, in this
case, but that doesn't matter) identify it as an MITM with a version
modification attack going on.

I think that conforming, unpatched TLS 1.0 implementations will
terminate connections if they see a major version of 131, or a minor
version of 132.

-Kyle H

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 12:29:05 -0600

> send back {0x83 0x04} or {0x03 0x84}.

Only if they ask for it via the C->S signal.

> terminate connections if they see a major version of 131, or a minor

It doesn't get sent to unpatched implementations.

Unpatched inspecting firewalls may raise an eyebrow, but in that case
it's a question of least breakage. Short of changing the structure size
with extensions or eliminating noticeable entropy from random_data,
there has got to be some bit flipped which is currently assigned some
other meaning.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 19:32:02 +0100 (MET)

Kyle Hamilton wrote:
> version number) than it was expecting.

Client conforming to rfc2246, rfc4346 or rfc5246 will not send the
magic cipher suite and therefore never get to see this modified
server_version.  The will also be kicked in a renegotiation handshake.

Implementation conforming to the spec that standardizes 
secure TLS renegotiation will perfectly well understand whatever
S->C signal that spec contains.  and it will be spec compliant.

Spec updates can certainly allow behaviour previously not allowed,
but needs provisions not to confuse old implementations.

see also
http://www.ietf.org/mail-archive/web/tls/current/msg04748.html

-Martin