Subject: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 16:57:18 +0100 (MET)

I have just submitted my proposal (I-D) to the IETF datatracker.

http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Nov 2009 10:42:12 +0200

Hi Martin.

I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header.

Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Nov 2009 12:21:44 +0100

> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm…

Presumably RI has the same concern: a deep-packet inspector may check
for "unknown" extensions (similar to checking for "unknown" TLS
versions) and reject the connection.

I don't think this is a good argument to decide between the two
proposals.  IDSs will simply need to be upgraded to support one (or
both) of the new proposals, and fortunately that is already required for
other reasons, so it seems like a small concern to me.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Nov 2009 14:02:14 +0200

> other reasons, so it seems like a small concern to me.

I've said several times that I prefer Martin's approach. It's just that I'd prefer a more subtle way for the S->C signalling (like something in the random or GMT)

An unknown ciphersuite is weird, but in a world with GOST and Camelia, you can't drop TLS handshakes based on that.

A magic timestamp is weird, but we already have implementations randomizing this field, so IDSs are already "trained" to ignore this.

Unknown extensions are a new kind of weirdness, but since they're allowed by the protocol, I don't expect much trouble there either.

Replying with version 131.1 to a request from version 3.1 is a clear protocol violation that may get noticed. Again, I'd be much more worried if this was in the record header, but I'm a little bit worried like this.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Nov 2009 13:27:05 +0100

Yoav Nir <[email-masked]> writes:

> I've said several times that I prefer Martin's approach. It's just
> that I'd prefer a more subtle way for the S->C signalling (like
> something in the random or GMT)

Here is another idea: use one bit of the ciphersuite space.  So if the
server would have selected TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = {
0x00,0x13 } if the server would support the renegotiation protocol it
would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead.

It is an ugly solution, but I haven't seen it mentioned.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Nov 2009 15:50:15 +0200

> It is an ugly solution, but I haven't seen it mentioned.

Actually, it's not that ugly, as a new ciphersuite can dictate some changes to the Finished message. This also takes care of both C->S and S->C signalling.

OTOH, it doubles the amount of defined ciphersuites

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 24 Nov 2009 14:09:06 +0000

> It is an ugly solution, but I haven't seen it mentioned.

Could use one bit of the compression_method field in ServerHello. Since there
are only two actually defined since it first appeared in SSLv3 I don't think
we'll run out any time soon.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 15:17:25 +0100 (MET)

> It is an ugly solution, but I haven't seen it mentioned.

I briefly thought about it, but didn't like it myself.

The cipher suite value is partitioned into ranges,
and part of that is for private use, so we may have accidental
collisions.

There is much less contention on the server_version.major,
that hasn't seen a lot of change for a while.  :)

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 15:28:51 +0100 (MET)

> we'll run out any time soon.

You mean for S->C  signaling in ServerHello?

Should be doable.  The confusion about unknown compression
algs is only in the ClientHello.  On the way back, we can specify
what we want to do.

The normal math on the cipher_suites and the compression_algs
is that the server is going to return a value from the _explicit_ set
proposed by the client. 

With the server_version there is acutally no set, only the highest
value desired by the client is sent in ClientHello.server_version
and the server is supposed to select an interoperable protocol
version (that should not be newer than the version proposed 
by the client).

If the server sends back  0x83,0x01  instead of 0x03,0x01
then it is still talking TLSv1.0 (0x03,0x01), but will authenticate
the previously exchanged Finished messages as if they were part
of the current handshake in order to create a cryptographic binding
from the enclosing TLS session to the renegotiation handshake.

That is somewhat of an orthogonal protocol change in order to
fix a security vulnerability in the original renegotiation.

Personally, I prefer to use the server_version.major,
but it is certainly not that my life would depend on this choice.
I'm still open to suggestions.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 17:34:43 +0100 (MET)

Yoav Nir wrote:
> 
> I see that you use the protocol field for the S->C signaling, but at
> least it's on the ServerHello rather than the handshake record header.

We need to transfer just one single bit of information within ServerHello.

> 
> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect
> protocols. A server answering with the wrong SSL version may just
> be "weird" enough for the middlebox to drop the connection.
> I'm not at that side of Check Point, but I know that much of the
> protection code is not targeted at a particular attack, but just
> performs a sanity check on the protocols.

We are already facing sufficient challenges with TLS server
that do not like protocol version numbers above {03,01} in
ClientHello.client_version.

I hope that builders of deep-inspecting firewalls are not
going to cause additional headaches by doing something
obviously unwise like restricting the TLS protocol version
from evolving.

If those firewalls are concerned about security, they should
be adding filters for traditional renegotiation--and when
doing that, they could fix such obvious flaws on the way.

-Martin

---

From: "Rob P Williams" <[email-masked]>
Date: Tue, 24 Nov 2009 11:41:09 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Rex
> Sent: Tuesday, November 24, 2009 11:35 AM
> To: Yoav Nir
> Cc: [email-masked]
> Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt
submitted
> doing that, they could fix such obvious flaws on the way.

I hope those firewalls cannot read our encrypted renegotiation taking
place to filter it.

---------------------------------------------------------------------
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: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 17:46:09 +0100 (MET)

> I hope those firewalls cannot read our encrypted renegotiation taking

The content_types are visible in the clear at the record layer,
so the firewalls will see handshake blobs flying by, and they
can recognize the ChangeCipherSpec message by their ContentType,
because it is not a handshake message (only sent within a handshake).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 18:04:49 +0100 (MET)

Yoav Nir wrote:
> 
> I've said several times that I prefer Martin's approach.
> It's just that I'd prefer a more subtle way for the S->C
> signalling (like something in the random or GMT)

I realized that my description of the details of the change
is "a little confusing" to put it mildly.

I'm going to clean up the description my I-D to make it
consitent and much more readable.

It's strange.  Seems I was slightly tired when I submitted the
document, because I didn't notice this myself that day.

> 
> An unknown ciphersuite is weird, but in a world with GOST and Camelia,
> you can't drop TLS handshakes based on that.
> 
> A magic timestamp is weird, but we already have implementations
> randomizing this field, so IDSs are already "trained" to ignore this.
> 
> Unknown extensions are a new kind of weirdness, but since they're
> allowed by the protocol, I don't expect much trouble there either.
> 
> Replying with version 131.1 to a request from version 3.1 is a
> clear protocol violation that may get noticed.

I beg to differ!  the meaning of a server_version value of  131,1
is undefined for implementations of RFC2246, RFC4346 and RFC5246.
So is the modified renegotiation handshake that we are defining.
Same applies to the semantics of TLS extension RI.

For the purpose of security, we have to make a backwards-incompatible
breaking change in order to tell the peer that an implementation
does not contain the vulnerability that is in RFC2246, RFC4346 and
RFC5246.

Which clients will get to see this change?
only those, that have explicitly asked for it by including
the special cipher suite ID in the ClientHello.

plus those that are under attack from an MitM (but there's little
we can do for them anyway, the attacker may feed them arbitrary
data of his choice.

-Martin

---

From: "Rob P Williams" <[email-masked]>
Date: Tue, 24 Nov 2009 12:09:06 -0500

'hope' was the wrong word. I meant 'wish'.

Perhaps wish is also the wrong word.

Why the record type was left exposed? As you say, you can see what is
going past. You can see alerts.

Why wasn't there a record type 'encrypted record'?

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2009 11:46 AM
To: Rob P Williams
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt submitted

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 18:30:28 +0100 (MET)

Rob P Williams wrote:
> 
> Why the record type was left exposed?
> 

*I* don't know the history and rationale behind this.
It was part of Netscape's SSLv3.

>
> As you say, you can see what is going past. You can see alerts.

You can see the ContentTypes of the records, even when the contents
are encrypted.  You can see the ContentType alert, you can not
see the alert itself (in wireshark traces, it shows up as
encrypted alert if the alert happens after the first ChangeCipherSpec).

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 13:59:22 -0600

> that hasn't seen a lot of change for a while.  :)

How about you set the highest bit in the version minor field?

I have seen lots of code over the years programmed to break when the
major version changes but tolerate increases in the minor version. A
change to the major version of a protocol is sometimes meant to signal
that the changes are non-backwards-compatible, but bumping the minor
version means they are.

I suspect you might break less packet inspection code by manipulating
the minor version rather than the major version.

- Marsh

---

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

> How about you set the highest bit in the version minor field?

If that would make the proposal more acceptable, *I* would not
have a problem with it.

I know that Mike prefers the highest bit of the minor.

> that the changes are non-backwards-compatible, but bumping the minor

Frankly, this is exactly why I'm advocating the use of the major.

I don't want the code to make version arithmetic when the signal
bit is still on.  And I know code that uses ==SSL_VERSION_MAJOR
in several places.  As it would be easier if they shaved the
version number off when parsing ServerHello on the client,
they are more likely to do so rather have to change a dozen
==SSL_VERSION_MAJOR.

I'm much less sure about server_version.minor.  They might be
much more tempted to leave the bit on and then it starts 
appearing in a lot of other places of the code that are not
reallly prepared to handle it.

> the minor version rather than the major version.

As I've previously pointed out, I much more concerned about breaking
apps on top of TLS and interoperability with the installed base
that of breaking the packet inspecting stuff.  The latter is going
to adapt much more quickly then the internet will deploy our fix.

We have significantly more 6-year old SSL/TLS implementations around
than 6-year old AV- and Packet-Insepecting-Firewall equipment--that
stuff doesn't make much sense if it is not constantly updated to
the most recent threats.

-Martin

---

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

Dear TLS WG,

> we'll run out any time soon.

I would like to get an idea about the acceptability of using
ServerHello.compression_method for S->C signaling instead of
the ServerHello.server_version that I currently use in my proposal.

Since the value range of compression methods is partitioned,
shaving a single bit is IMHO not an option.

We would have to get a single compression_method assigned,
and then relocate the real "common compression_method"
that the server selected to a different location --
Server.Random.

There seems to be an issue with some hardware/chips that may
have an issue with TLS version changing (and its happened
before with TLSv1.1...)

Sending a personal reply to me rather to the list
with just "no problem" or "rather not" would be sufficient.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 25 Nov 2009 01:23:26 +0000

> versions) and reject the connection.

If it does then it's nonconformant to TLS.

(In general, protocol specifications impose requirements on any
non-transparent middlebox, just as they do on the endpoints.)

A middlebox that rejected an unexpected protocol version (i.e. one
that is inconsistent with the record version in later messages),
OTOH, would not be nonconformant to TLS, or at least that case is
certainly not as clear-cut.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 25 Nov 2009 01:27:30 +0000

> Yoav Nir <[email-masked]> writes:
[...]
> would return { 0x70, 0x13 } or { 0x00, 0x13 | 0x70 } or similar instead.

That's even more likely to upset an IDS, since it has a legitimate reason
to kill connections that it sees as using a ciphersuite that is not on
a list of known-secure ciphersuites.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 25 Nov 2009 01:29:43 +0000

> I hope those firewalls cannot read our encrypted renegotiation taking

They can detect a renegotiation because the handshake message types
are not encrypted.

(Yes, that's arguably a design flaw.)

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Nov 2009 09:13:56 +0100

> If it does then it's nonconformant to TLS.

Well, TLS extensions are not conformant to SSLv3 either.  Even for TLS,
it doesn't seem unreasonable to assume that if some middlebox reject
unknown server versions it may just as well reject unknown TLS
extensions, on the basis of "don't allow what we don't know about".

I remain unconvinced that this is an important issue though.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Nov 2009 10:36:10 +0200

> we'll run out any time soon.

Well, since we're adding information without increasing the size of the messages, I guess it really is a compression method.

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:18:03 +0100

> shaving a single bit is IMHO not an option.

I guess this depends on (a) whether anyone is actually using values
from the "private use" range 224-255, and (b) if someone is, whether 
the renegotiation fix has to be compatible with using "private use"
compression algorithms.

If we e.g. "borrowed" the most significant bit of the compression
algorithm for S->C signalling, we could just require that a client
that supports secure renegotiation MUST NOT include any compression
methods in current private use range (224-255) in the ClientHello.

I doubt anyone is using those currently; TLS compression in general
is rarely used, and AFAIK those implementations that use it use the
publicly defined algorithms (all of which have 0 in the most significant 
bit).  So this wouldn't be a code change for implementations...

And we would need to update the IANA registration rules for this
registry, and probably create a new private use range (e.g., 120-127),
but that's just paperwork, not implementation work.

> There seems to be an issue with some hardware/chips that may have an
> issue with TLS version changing (and its happened before with
> TLSv1.1...)

I'd be very interested in any concrete data (even without 
mentioning product names) about this...

Best regards,
Pasi
(not wearing any hats)

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 15:09:49 +0100 (MET)

Yoav Nir wrote:
> Dr. Stephen Henson wrote:
> > 
> > Could use one bit of the compression_method field in ServerHello.
> > Since there are only two actually defined since it first appeared
> > in SSLv3 I don't think we'll run out any time soon.
>
> Well, since we're adding information without increasing the size of
> the messages, I guess it really is a compression method.

I like this rationale! :-)

> > shaving a single bit is IMHO not an option.

For reference what I'm referring to:
http://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml

> but that's just paperwork, not implementation work.

Using ServerHello.compression_method ServerHello.server_version
for S->C signaling would be fine with me if it improves the acceptance
of the extension-less approach.

I'm also not generally opposed to shaving a bit, but considering
the existing allocation rules, it is not my first choice.

Again, consensus is much more important than personal taste for me.

What I would really appreciate is feedback from _implementors_ on
the alternatives, because they're the ones who will put the fix
into code an interoperate.

There may be hardware (implementing or supporting TLS at endpoints)
affected as well, which might be much more difficult to patch
than software.  So feedback from those would be helpful!

-Martin