Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

From: Sebastian Gajek <[email-masked]>
Date: Mon, 14 Dec 2009 17:42:06 +0200

Hi there,

sorry for putting another mail into the long list of TLS renegotiation
mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is to
cryptographically link the TLS sessions. There are different approaches to
achieve this goal. I was wondering why you introduce a new cipher suite.
Wouldn't it be easier to require that finished values are a function of all
values received so far (incl. previous TLS sessions or at least their
finished values.) This countermeasure is simple, complies with the present
TLS spec and could result in faster adaption.

Is there a technicality I am not aware?

Thx for any feedback.

-- 
Sebastian Gajek
School of Computer Science
Tel Aviv University, Israel

Web: http://www.cs.tau.ac.il/~gajek/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Dec 2009 22:35:54 +0200

It would be easy to require this, but it's not compliant with the current spec. The current spec says that the finished value depends on all the bytes starting with the first byte of the ClientHello.

We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but adding the previous finished message is a change to the spec, one that requires some sort of signaling, either with a fake cipher suite or with an extension.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sebastian Gajek [[email-masked]]
Sent: Monday, December 14, 2009 17:42
To: [email-masked]
Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Hi there,

Thx for any feedback.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 02:46:05 +0000

Yoav Nir wrote:
> It would be easy to require this, but it's not compliant with the current
> spec. The current spec says that the finished value depends on all the
> bytes starting with the first byte of the ClientHello.
> 
> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but
> adding the previous finished message is a change to the spec, one that
> requires some sort of signaling, either with a fake cipher suite or with
> an extension.

No, this is a misunderstanding; changing how the Finished message is
computed *for renegotiations* does not necessarily require signalling.

Changing the way that the Finished message is computed *only* for
renegotiations, would affect interoperability only when there is a
renegotiation where one peer is unpatched and the other is patched.
Under that condition, being interoperable would allow an attack.

(Some have argued for allowing patched clients and servers to favour
interoperability over security in this case. I don't agree that that is
desirable.)

Furthermore, changing the Finished message only for renegotiations is
sufficient to prevent attacks provided that the renegotiating peer
has been updated.

By itself, however, that would not allow clients to detect non-patched
servers. It is likely, and desirable, that some clients will adopt a
"strict" policy in which they fail an *initial* connection to a non-patched
server. Technically, only the server->client signal is directly necessary
for this. The client->server signal is needed to allow the server->client
signal to be sent without the possibility of breaking unpatched clients.

(The client->server signal also allows servers to reject initial
connections from unpatched clients. However, it's unlikely in practice
that servers will follow that policy, and it's not necessary to prevent
the most serious variant of the attack.)

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Dec 2009 10:21:20 +0200

> Under that condition, being interoperable would allow an attack.

That is just wrong. An RFC compliant client negotiating with an RFC compliant server must not get a wrong Finished message. That's changing the protocol, and it requires signaling either by a new version number or something else. You can't now change the base 1.2.

> interoperability over security in this case. I don't agree that that is

That's not for you to decide. It's for the client and server vendors, and they may or may not pass this decision to their customers.

> sufficient to prevent attacks provided that the renegotiating peer

It's also sufficient to break some things.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 21:26:29 +0000

Yoav Nir wrote:
> That is just wrong.

You're mistaken. What I said is precisely correct.

> An RFC compliant client negotiating with an RFC compliant
> server must not get a wrong Finished message.

That is not a requirement. It does not matter whether a handshake
failure is due to a mismatch in the Finished messages, or a client or
server explicitly aborting because it required that renegotiation is
only performed with a patched peer.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Dec 2009 10:18:10 +0200

> You're mistaken. What I said is precisely correct.

I did not mean "wrong" in the sense of incorrect, but "wrong" in the sense of something we shouldn't do.

> only performed with a patched peer.

Of course it is. Finished message should never fail to verify, unless there is a real attack going on. They are there to detect attacks, not to detect unpatched peers.

Detection of unpatched peers or the requirement to patch should be through signaling or alerts.

---

From: Sebastian Gajek <[email-masked]>
Date: Wed, 16 Dec 2009 12:06:24 +0200

I totally agree. My suggestion was meant as an alternative to the
TLS-renegotiation proposal. One needs to define what is meant by a state
that contains all previous session messages. I am not sure whether you need
a fake ciphersuite for that. You simply need a mechanisms that tells the
parties that TLS session is "alive" (like in the lower layer protocols). I
am a little bit worried about using the previous-session finished messages
as a sub-session identifier (SUSI) in plain text. Imagine there is in future
a higher-layer protocol that allows the attacker to access the TLS
transcript (think of a powerful application like AFLEX). Given the attacker
the finished values in clear means that he gets a verification oracle for
free. I am not saying this leads to a concrete attack. However, this oracle
is unnecessary and can be circumvented by the above proposal.

"Yoav Nir" <[email-masked]> wrote 14/12/09 22:35:

> spec. The current spec says that the finished value depends on all the bytes
> starting with the first byte of the ClientHello.
> 
> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but adding
> the previous finished message is a change to the spec, one that requires some
> sort of signaling, either with a fake cipher suite or with an extension.
>