Subject: [TLS] I-D Action:draft-ietf-tls-renegotiation-00.txt

From: [email-masked]
Date: Thu, 19 Nov 2009 16:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title           : Transport Layer Security (TLS) Renegotiation Indication Extension
	Author(s)       : E. Rescorla, et al.
	Filename        : draft-ietf-tls-renegotiation-00.txt
	Pages           : 10
	Date            : 2009-11-19

SSL and TLS renegotiation are vulnerable to an attack in which the
attacker forms a TLS connection with the target server, injects
content of his choice, and then splices in a new TLS connection from
a client.  The server treats the client's initial TLS handshake as a
renegotiation and thus believes that the initial data transmitted by
the attacker is from the same entity as the subsequent client data.
This draft defines a TLS extension to cryptographically tie
renegotiations to the TLS connections they are being performed over,
thus preventing this attack.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Stone <[email-masked]>
Date: Sat, 21 Nov 2009 20:11:36 -0500

Dear TLS Working Group members,

My colleagues and I at Akamai have pooled our experience serving a large
fraction of the web's traffic to identify several novel considerations
affecting your proposals, notably concerning unforeseen social constraints on
ciphersuites, the need to live with our decisions for many years, and the risk
of combinatorial explosion of protocols. I hope you find them helpful in
reaching a prompt and effective consensus.

Kind regards,

Michael Stone

...........

New Ciphersuites
----------------

We foresee some adoption hazards facing new "ciphersuites" which have not been
mentioned so far.

In particular, while additional ciphersuite identifiers may be very
*technically* interoperable among SSL and TLS implementations, they are
regularly the subject of contractual language or technical guidance which may
make them socially expensive to adopt.

For example, the "Client Browser Requirements" section of the US DISA's
guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that must
be enabled and disabled. Similarly, it seems likely that many contracts have
been written which mandate the use of FIPS 140-2-approved ciphers, e.g., in
order to establish compliance with the vague PCI-DSS "strong cryptography"
requirement.

Thus, care should be taken to find out how much social infrastructure will need
to be updated in order to permit the use of this signalling mechanism.

Protocol versioning and support
-------------------------------

Due to customer demand, we currently expect to need to support unmodified
versions of all of SSL3, TLS 1.0, 1.1, 1.2, and even (against our
recommendations) SSL2, for many years. This brings up three sub-points:

First, because we're going to have to support legacy protocols for the
indefinite future, we would prefer to see a single new protocol with safe
renegotiation semantics (e.g. TLS 1.3) over seeing many new protocols branched
from all the old protocols. We are particularly interested in heading off the
combinatorial explosion of new TLS protocols that might result from the future
discovery of new vulnerabilities if "protocol branching" is adopted.

Second, we believe that changing the definition of the Finished message should
not be done without increasing the protocol version number.

Third, we believe the proposed solution of "upgrade all SSL3 clients to TLS"
to be unrealistic in general. 

That is, while "upgrade all SSL3 clients to TLS" may be good advice for
browsers and for many other SSL3 clients on the public internet, we are
sensitive to the enormous variety of circumstances in which SSL3 is deployed
and would be saddened to see the this working group leave behind end-users who
require renegotiation and who are unable to upgrade to TLS but who could
nevertheless manage to apply a minimally invasive change to their legacy SSL3
implementation. 

In this vein, legacy embedded systems such as cell phones, game consoles, TV
set top boxes, old PDAs, and other such devices particularly concern us: we
expect them to be difficult and time-consuming to update if updating is even
possible. The current draft-ietf-tls-renegotiation-00 specification seems to
largely ignore the prevalence of these devices, to the detriment of vulnerable
end-users and of the server operators who must cater to them.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Nov 2009 18:19:12 -0800

Hi Michael,

Thanks for this valuable feedback.

I'm having difficulty trying to understand your recommendations which
appear to be contradictory:

You say that you'd prefer that safe renegotiation be implemented only
in a new version, i.e. TLS 1.3, especially if the Finished message
calculation changes.

But then you also say that it is unreasonable to expect SSLv3 clients
to upgrade to TLS, and that you will be supporting old versions for
many years to come (all of which would remain vulnerable based on the
fact that only TLS 1.3 would be fixed).

I would add that it would be difficult for even TLS 1.0 code to be
upgraded all the way to TLS 1.3 -- you would need to implement TLS 1.1,
1.2, and 1.3.  I've implemented them all and it requires many hundreds,
or even thousands of lines of code.  The problem is that you can't skip
versions (if you're the client) because the server might select one
that you skipped, and thus you would have an interoperability problem.

If we don't patch the existing versions, many will remain vulnerable
due to the effort required to get all the way to TLS 1.3.

Can you please clarify your recommendations?

Thanks,

Mike

---

From: Martin Rex <[email-masked]>
Date: Sun, 22 Nov 2009 03:58:30 +0100 (MET)

Michael Stone wrote:
> 
> New Ciphersuites
> ----------------
> 
> We foresee some adoption hazards facing new "ciphersuites" which
> have not been mentioned so far.
> 
> regularly the subject of contractual language or technical guidance
> which may make them socially expensive to adopt.
> 
> Thus, care should be taken to find out how much social infrastructure will
> need to be updated in order to permit the use of this signalling mechanism.

There seems to be a serious misunderstanding!

We are definitely _not_ talking about enabling new ciphersuites.

What we are talking about is magic ciphersuite IDs to steer protocol
behaviour.  There will be a SHOULD in the spec that this magic ciphersuite ID
should NOT be configurable and neither reported at normal ciphersuite
configuration APIs and UIs, only visible in the network encoding
of the ClientHello handshake message, and there will be a requirement
in the spec that the Server MUST NOT select this magic cipher suite ID
as the common cipher suite -- because it is not a cipher suite.

> Protocol versioning and support

Another misunderstanding.  We are not branching any protocols.
We are fixing a security vulnerability in an existing protocol.

Just like service packs or hotfixes does not convert your Windows OS
into new products, this fix for a security vulnerability will not
create a different protocol--only a patched/fixed version of it.

But of course, should we find another security vulnerability
in the protocol then we would have to think once again how to fix it.

The difference between an implementation bug and a protocol defect is,
that unless you can live with disabling the affected protocol feature
entirely, you will have to change the protocol that will usually change
some bits-on-the-wire.

> 
> Second, we believe that changing the definition of the Finished message
> should not be done without increasing the protocol version number.

Yet another misunderstanding.
I haven't seen anyone talking about changing the definition of the
Finished message.

What we have been discussing is how to get an authentication of
the current session included in the authentication performed by
the Finished message of the renegotiation.

The only way to do that is to get the verify_data from the Finished
messages of the current session included in the handshake message
hash.  What we are fighting about is the exact API calls that
we are going to use to achieve that, and whether we should also
change and add some fairly static bytes in two handshake messages
on the way or prefer a simpler, straightforward and failSAFE fashion.

> to be unrealistic in general. 

Wow, that sounds challenging.  What about the all new TLSv1.3
you're looking for -- what would be the purpose of that if
you are going to leave most of the installed base as it is?

The creation of a TLSv1.3 spec is not going to magically heal
old implementations that do not want to or can not get upgraded. 

> end-users and of the server operators who must cater to them.

Personally, I do care a lot about the installed base, including the
stuff that is likely not to be updated at all.  Not all of that will
be vulnerable.  But those that are, there's nothing TLS WG can do to
protect them unless there is a way to patch their implementations.

Firewalling that stuff might sometimes be an option.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 05:04:48 +0000

Michael Stone wrote:
> recommendations) SSL2, for many years.

Note that SSLv2 is vulnerable to a MITM attack that forces use of 40-bit
crypto. It is certainly not possible to fix this. So, support for SSLv2
should not be a consideration; if a client or server negotiates SSLv2,
then it is already making itself vulnerable to an attack as serious as
the renegotiation attack (since it is now easy to break 40-bit crypto).
And if a client doesn't intend to negotiate SSLv2, then there's no point
in sending an SSLv2-compatible ClientHello, so we don't need to consider
that case either.

> not be done without increasing the protocol version number.

I disagree. This is imposing an artificial requirement that over-constrains
the solution. If the solution must support several existing versions (and
I don't think anyone disagrees that it must support at least TLS 1.0, 1.1
and 1.2), and changing the Finished message should not be done without
increasing the version number, then this is just saying that the Finished
message computation can't be changed. Note that the only approach put
forward so far that does not explicitly change the Finished computation
is the RI draft.

> to be unrealistic in general. 

Since the RI draft requires the client to send a TLS ClientHello, the client
must support TLS (or break the widespread and justified assumption made by
servers that a client sending a TLS ClientHello is able to negotiate TLS).
So, your second and third points together exclude *every* proposal so far,
and it is not obvious that any solution under these constraints is possible.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 05:30:40 +0000

> in the protocol then we would have to think once again how to fix it.

Note that, even if additional vulnerabilities were found, that would not
lead to any combinatorial explosion of variants. That's because the fix
for any version-independent flaw can and should require implementation
of all the fixes for previously discovered version-independent flaws.
In that case, the number of variants is at most
(number of SSL/TLS versions) * (number of flaws + 1).

A combinatorial explosion would be something like
(number of SSL/TLS versions) * 2^(number of flaws), but that would only
occur if implementation of each fix was independent, and there's no
reason to allow that.

> I haven't seen anyone talking about changing the definition of the

I think that's a perfectly reasonable option, for example:

  verify_data =
    PRF(master_secret, finished_label, Hash(handshake_messages),
        previous_verify_data)
      [0..verify_data_length-1];

and I see no reason to exclude this option from consideration. Note that
this would obviate any confusion about where the previous_verify_data
goes in the handshake messages, or how it is encoded. More importantly,
it guarantees that that the input to the PRF for the modified Finished
computation cannot coincide with any possible input for the unmodified
computation, which is a useful property that simplifies the security
analysis.

> hash.

No, it isn't, as shown above.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 05:38:15 +0000

> (number of SSL/TLS versions) * (number of flaws + 1).

<pedantic>
Actually, if you consider each implementation to support a contiguous
range of versions, then the number of variants is

  N*(N+1)/2 * (number of flaws + 1).

where N is the number of SSL/TLS versions.
</pedantic>

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 06:29:10 +0000

>       [0..verify_data_length-1];

Minor notational error -- that should be

    verify_data =
      PRF(master_secret, finished_label, Hash(handshake_messages)
                                         + previous_verify_data)
        [0..verify_data_length-1];

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Nov 2009 10:40:40 +0200

On Nov 22, 2009, at 3:11 AM, Michael Stone wrote:

<snip/>
> Protocol versioning and support

I agree with both points, but the semantics of the SSLv3/TLS handshake are such, that you can't declare that you support SSLv3 or TLS 1.3 only. Many implementations (OpenSSL comes to mind) only have SSLv2, SSLv3 and TLS 1.0.  Updating them to support TLS 1.3 would require adding support for TLS 1.1 and TLS 1.2 as well. That would take longer to implement and much longer for acceptance tests. Also, a new version of TLS may affect all those contracts you mentioned earlier even more than a new ciphersuite.

> nevertheless manage to apply a minimally invasive change to their legacy SSL3

Agree, but you can't change any client from vulnerable to not-vulnerable, unless you do one of three things:
 - implement the new binding (new Finished message)
 - receive a signal that the gateway is patched, and won't renegotiate with you, and failing that... 
 - not connect to un-patched servers.

> end-users and of the server operators who must cater to them.

But what can we do?  They are vulnerable. If they don't require reneg, a good server will protect them by not renegotiating at all. If they do, they're just vulnerable, and it's the server's choice as to whether to protect them or not.

---

From: Bill Frantz <[email-masked]>
Date: Sun, 22 Nov 2009 11:49:24 -0800

> - not connect to un-patched servers.

Marsh Ray has referred to a possible defect where the MITM causes the
client to renegotiate while the server does not. If I understand the
situation correctly, for a client to be safe from this attack, the above
would become:

Agree, but you can't change any client from vulnerable to not-vulnerable,
unless you do one of two things:
 - implement the new binding (new Finished message) in both directions.
 - receive a signal that the server is patched which means it won't renegotiate
   with you, and not renegotiate with the server yourself.

The client MUST NOT connect with a server unless one of these two
conditions holds.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, CA 95032

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 21:35:05 +0000

> The client MUST NOT connect with a server unless one of these two

As far as I'm aware, the variant of the attack Marsh Ray referred to is
only relevant to connections where TLS-level client authentication (client
certificates or PSK) is used. That's because, in the conditions under which
this variant will work, a more straightforward MITM attack not involving
renegotiation could achieve the same effect when TLS-level client
authentication is not used.

So, if a patched client's policy is to allow initial handshakes to an
unpatched server, it is not reducing security any further by allowing
renegotiations with an unpatched server where the client is unauthenticated
at the TLS level, for both the original and renegotiated connections.
I think.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Nov 2009 18:03:10 +1300

Michael Stone <[email-masked]> writes:

>guidance document "UNIX STIG V5R1" mandates an exact list of ciphers that
>must be enabled and disabled. Similarly, it seems likely that many contracts
>have been written which mandate the use of FIPS 140-2-approved ciphers, e.g.,
>in order to establish compliance with the vague PCI-DSS "strong cryptography"
>requirement.

Does it say "ciphers" or "cipher suites"?  This isn't enabling (or disabling)
any ciphers at all, so it would seem to be excluded from the restrictions.

(In any case if cipher suites really are explicitly restricted, you could
always signal via compression algorithms).

Peter.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 Nov 2009 07:28:54 +0000

> order to establish compliance with the vague PCI-DSS "strong cryptography"

But it turned out that all those cipher suites were not as secure as
expected.  You need to invoke the flaw remediation procedures.  For
UNIX STIG V5R1, this appears to require an IAVM.  While this may take
some time, I don't think this is an argument against magic cipher
suites.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 Nov 2009 07:35:07 +0000

> any ciphers at all, so it would seem to be excluded from the restrictions.

Cipher suites, as far as I can tell.  Both SSLv2 and SSLv3 are
mandatory, and TLS is not allowed (if you view the list of protocols
as exhaustive).

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 23 Nov 2009 07:49:04 +0000

> mandatory, and TLS is not allowed (if you view the list of protocols

Then it's mandating insecurity. Why would you want to follow this guidance?

---

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

> any ciphers at all, so it would seem to be excluded from the restrictions.

The use of a "special cipher suite ID" for signaling is entirely
independent from cipher suites that are enabled or disabled
on clients and servers.

It is only an ID, it does not represent a real cipher suites,
is assigned from the managed number space of cipher suite IDs
so that it can not be confused with real cipher suites, is
recommended to be not configurable by and not be visible to
the regular ciphersuite configuration APIs and UIs, and
ist MUST NOT be selected by the server as a common cipher suite.

> always signal via compression algorithms).

*I* don't know the interoperability of compressions with the installed
base, but since that field had used with only a single element and
value for several years, there might be a problem.

Pasi's comment on compression algorithm identifiers is here:
http://www.ietf.org/mail-archive/web/tls/current/msg04140.html

-Martin

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 23 Nov 2009 17:50:02 +0000

> value for several years, there might be a problem.

They can't be used with SSLv2 compatible client hellos btw.

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: Mon, 23 Nov 2009 20:49:29 +0100 (MET)

> Then it's mandating insecurity. Why would you want to follow this guidance?

Maybe because you are a government agency and that "guidance"
is not a suggestion, but a mandatory-to-comply regulation?

http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf

They allow only ciphersuites with RC4-128 or 3DES, so does not
seem to be a downgrade attack involved, even with SSLv2.

-Martin