Subject: [TLS] What is spliced

From: Eric Rescorla <[email-masked]>
Date: Mon, 07 Dec 2009 14:04:27 -0800

There has been a bunch of discussion about what the introduction should
say about what is spliced together in this attack. Here's my proposed
new text, based on trying to integrate various comments from Nelson,
Marsh, etc.

This attack can be prevented by cryptographically binding
renegotiation handshakes to the enclosing TLS channel, or more
properly, to the TLS handshake which established the security
parameters over which the new handshake is being performed. This
prevents the attacker from splicing a negotiation occuring over one
set of security parameters (including the initial pre-handshake
set of TLS_NULL_WITH_NULL_NULL) into
another set of security parameters. An attempt by an attacker to
inject himself as described above will result in a mismatch of the
extension and can thus be detected. The data used in the extension is
similar to, but not the same as, the channel binding data used in
[I-D.altman-tls-channel-bindings], however this extension is not a
generic-purpose RFC 5056 channel binding facility.

Comments?

-Ekr

---

From: "tom.petch" <[email-masked]>
Date: Thu, 10 Dec 2009 17:08:14 +0100

----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
Sent: Monday, December 07, 2009 11:04 PM
Subject: [TLS] What is spliced

> generic-purpose RFC 5056 channel binding facility.

Eric

- What is spliced:-)  As Martin says in another response, I would prefer
a single term, and spliced is not one I see anywhere else.  Would injected,
which is the verb used in the next sentence, not be adequate? (I rewrote
1.Introduction using 'Injected Data' and found it easier to follow)

- Why is the injection/splice into a set of security parameters?  Isn't the 
injection into a TLS session with a different set of security parameters?

- In the absence of Nico, I suggest that 'channel binding data' should be
'channel bindings data' - as RFC5056 says, channel binding is the process,
channel bindings is the data.

- One point I have got confused on in the discussions is which set of data
is used; this text implies that it will be from the most recent re-negotiation
as opposed to that from the negotiation which established the session in 
the first place.  If so, the text could be more explicit eg 'most recent TLS
handshake/(re-)negotiation'. Nico's use of channel, with which I concur, is the
channel stays the same no matter how many renegotiations occur, which.
for me, makes this proposed text less clear.

Tom Petch

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 18:53:56 +0100 (MET)

> 1.Introduction using 'Injected Data' and found it easier to follow)

IMHO the splicing fully applies only to attack scenario (3), where both
TLS peers see a renegotiation, but for different enclosing TLS sessions.

> injection into a TLS session with a different set of security parameters?

I think it would be better do define the terminology "TLS session"
"TLS connection" rather than trying to avoid the word "session" and
refer to the connection state instead (that is terminology carried
over from the SSLv3 spec into TLSv1.2/RFC-5246).

On quick glance, the removal of terminology session/connection
from draft-ietf-tls-ssl-version3.txt 5.1 Session and connection states
to rfc-5246 6.1 Connection States appear to _me_ more confusing
than helpful.

> handshake/(re-)negotiation'. Nico's use of channel, with which I concur,
> is the channel stays the same no matter how many renegotiations occur,
> which, for me, makes this proposed text less clear.

I fully agree.  After having read draft-altman-tls-channel-bindings-07.txt
Sections 3. and 3.1 I think that referencing that draft will do more
harm than good, because it is obviously _NOT_ the same -- during
the processing of the finished messages of the renegotiation, the
previous Finished.verify_data will be overwritten and gone.

Implementations of draft-altman-tls-channel-bindings-07.txt will
require additional session state for TLS implementations to be added
(if the TLS implementation supports renegotiation).

>From a conceptual standpoint, secure TLS renegotiation should
better bind to the previous handshake, not to the initial one on
a communication channel.

The concept of retroactively considering all data authenticated
that came through previous TLS sessions is an application concept,
_not_ one of TLS.  It might be OK for some applications to make
such assumptions, provided they get their part of the identity
change during renegotiation properly managed, but it is definitely
something that TLS should buy into _in_general_. IMHO.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Dec 2009 19:11:49 +0100 (MET)

(partially obvious) typo in last line of my previous posting.

> change during renegotiation properly managed, but it is definitely
- something that TLS should buy into _in_general_. IMHO.
+ something that TLS should _not_ buy into _in_general_. IMHO.

-Martin