Subject: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt

From: "Robert Dugal" <[email-masked]>
Date: Fri, 13 Nov 2009 14:28:53 -0500

A co-worker an I have been discussing the draft and have some concerns
about sending client and server verify_data in the extension.

In the ClientHello, the client sends the verify_data from the client's
previous Finish message as the renegotiated_connection data.

In the ServerHello, the server sends both the cient's verify_data and
the server's verify_data.

This data is not normally sent in the clear and I am wondering if this
will provide additional data that can be used to mount some other form
of attack .   

The only reason we are sending any data at all is to prove that the
renegotiation is bound to a previous handshake, so why not bind it with
some data that is on the wire and visible to everyone?

One possability is to use the client and server randoms as the
renegotiated_connection data.  This data is sent as plaintext on the
wire so it reveals nothing the attacker doesn't already know.

If these randoms are included in the client hello's
renegotiation_connection data  then they will also be included in the
client and server message hashes. 

Likewise, if they are missing from the renegotiation_connection data  an
attacker cannot add them or else client and server  message hashes will
mismatch and renegotiated handshake will fail.

Another alternative could be to use the client's encrypted Finish
message rather than the verify_data from Client's Finish message, and
server's encrypted Finish message.

Again both these data are sent on the wire so reveal nothing.  It's
probably easier to use the randoms as handshake and record layer may not
be able interchage data.

-- 

Robert Dugal                        Senior Software Developer

Certicom Corp.                    A Subsidiary of Research In Motion 

[email-masked]

direct        905.501.3848

fax             905.507.4230

www.certicom.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Nov 2009 14:23:16 -0600

> will provide additional data that can be used to mount some other form

See:

draft-altman-tls-channel-bindings-07.txt

which addresses your concern.

> some data that is on the wire and visible to everyone?

One of my counter-proposals, which I ask to be considered if the use of
extensions is problematic for interop reasons, is to add the outer/old
connection's client Finished message as one more input in the inner/new
connection's Finished message verify_data computation (see post to
[email-masked] with message-ID <[email-masked]>.

The rationale for that proposal is not that Finished message verify_data
is sensitive (it is not), but that the use of extensions may be harmful
to interop (and if that's not the case, then that proposal is to be
ignored).

> wire so it reveals nothing the attacker doesn't already know.

I explained why that doesn't work in a post with message-ID
<[email-masked]> posted on Thu, 5 Nov 2009 11:13:08
-0600 (subject: Re: [TLS] TLS renegotiation issue).

> server's encrypted Finish message.

See:

draft-altman-tls-channel-bindings-07.txt

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Nov 2009 23:23:50 +0100 (MET)

Robert Dugal wrote:
> of attack.   

This particular issue is a misunderstanding of how this extension works.

The TLS Renegotiation_Info contains the verify_data of the
client.finished (ExtendedClientHello) and
client.finished | server.finished (ExtendedServerHello)

_ONLY_ on the renegotiation handshake, which happens under the
protection of the active TLS session.  The very same verify_data
was actually transferred under exactly this same protection as
the very first message.

As described in my recent proposal, it is not necessary to
send this data at all.  Just devise a different instruction
to have TLS at either end include its local copy of this
previous handshake verify_data in the handshake message hash
that goes into the Finished calculation of the new handshake
(as well as the VerifyCertificate calculation when client-cert is used)
and you get the same effect with respect to including the
previous session in the authentication of the new session.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2009 01:11:10 +0200

At Fri, 13 Nov 2009 14:28:53 -0500,
Robert Dugal wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]

But they're not being sent in the clear here either. They're being
sent over the same encrypted channel that they were originally sent
over. Remember that you're renegotiating over an existing TLS
channel.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 14 Nov 2009 02:38:19 +0000

> will provide additional data that can be used to mount some other form

I can't see a feasible attack as long as the hash function doesn't
reveal information about its input. However, I think you're right to
be concerned; we need input from experienced cryptographers about this.

> wire so it reveals nothing the attacker doesn't already know.

That doesn't have the same security properties. It is possible for two
different sessions to have the same (ClientRandom, ServerRandom) pair.
(Attacker acts as a MITM and forwards client's random to server and
vice-versa.)

The Finished hashes, OTOH, are unique to a session because an attacker
can't force the whole handshake to be identical for two sessions
(well, unless they are talking to themself).

> server's encrypted Finish message.

That would work.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 14 Nov 2009 02:44:41 +0000

> be concerned; we need input from experienced cryptographers about this.

Actually this is definitely fine, because the verify_data will be
encrypted if the preceding session was not controlled by the attacker
(and if it was, then the attacker knows the verify_data anyway).