Subject: [TLS] simplistic renego protection

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 01:36:55 +0100 (MET)

The most simplistic approch to renego protection is

   1. the client signals that it is patched through a fake
      ciphersuite ID in each ClientHello

   2. the client only supports secure renegotiation and
      secure renegotiation is specified to change the definition
      of the handshake message hash for renegotiation handshakes
      to include the verify_data of the client.finished and
      server.finished after the ServerHello.

Everything else is options for vendors and users.

If we do not provide a standardized signaling Server->Client in the
client hello, then it is not possible for the clients to offer
the option for insecure renegotiation (I have no idea whether such
a desire exists, but it might easily exist during transition).

With this simplistic approach, an MITM can not proxy a clients
initial handshake into an updated servers renegotiation, even
when the server still allows insecure renegotiation (e.g. during
the transition period).  

I really like to hear convincing arguments why we need the 
TLS extension in the renegotiation handshake, and why changing
the definition for the handshake message hash instead is not
a superior alternative.  In particular one that will grow
naturally into future TLS revisions.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 17:13:06 -0800

>       server.finished after the ServerHello.

No, this does not plug the hole.  The magic ciphersuite in (1)
requires that the server recognize it, i.e. it is patched.
Therefore it will not perform insecure renegotiation even
without seeing the ciphersuite (especially without seeing it).

And again the client's INITIAL handshake is the one that the
server sees as a renegotiation in Marsh's attack, so the fact
that the client won't REnegotiate (2) is unhelpful; the attack
has already completed.

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 22:31:10 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Rex
> Sent: Sunday, November 15, 2009 4:37 PM
> To: [email-masked]
> Subject: [TLS] simplistic renego protection
> 
> If we do not provide a standardized signaling Server->Client 
> in the client hello, then it is not possible for the clients 
> to offer the option for insecure renegotiation (I have no 
> idea whether such a desire exists, but it might easily exist 
> during transition).
> 
> With this simplistic approach, an MITM can not proxy a 
> clients initial handshake into an updated servers 
> renegotiation, even when the server still allows insecure 
> renegotiation (e.g. during the transition period).  
> 
> 
> TLS extension in the renegotiation handshake, and why 
> changing the definition for the handshake message hash 
> instead is not a superior alternative.  In particular one 
> that will grow naturally into future TLS revisions.
> 
[Joe] TLS Extensions is the standard way to extend the protocol.  Using
the ciphersuite field as a means to change the base protocol is a new
extension mechanism.  I don't think this is a particularly good thing
for TLS to grow into.  I don't see a reason to define a new extension
mechanism when we can achieve what is necessary using the existing
mechanism.   When TLS 1.2+x is defined in the future then it can address
the renegotiation problem as necessary and the version field will signal
the underlying changes.   

> -Martin
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 11:29:08 +0100 (MET)

> without seeing the ciphersuite (especially without seeing it).

Of course the server needs to implement secure renegotiation as well.

If the server doesn't want to support old style renegotiation,
it doesn't need to look for the ciphersuite ID at all, it can also
just perform the new handshake message hash for ever renegotiation
handshake.

The fake ciphersuite ID is only for the signaling, and the server
wants to signal back, re-puposing an existing protocol field of a
vanilla ServerHello, then it needs to check whether the client
will get the hint and not choke on it.

> that the client won't REnegotiate (2) is unhelpful; the attack

Bugs of the server must be fixed at the server.  You can not expect
from end users that they will have every piece of TLS client software
that they might be using reviewed before the dare touching it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 11:53:00 +0100 (MET)

> the renegotiation problem as necessary and the version field will signal

You do not seem to understand the TLS renegotiation problem at all.

We are NOT supposed to extend TLSv1.2, we are supposed to FIX
all protocol versions of TLS out there SSLv3->TLSv1.2.

The TLS extensions mechanism is completely irrelevant to the problem
and completely unnecessary for the fix.

Requiring people to implement generic TLS extensions, something
that was completely undefined even for TLSv1.0 and is still optional
in TLSv1.2, only to fix something that has nothing to do with
TLS extensions and can be fixed much more easily without TLS extensions
is a pretty bad idea and poor engineering.

Think about the lines of code for a client:

minimum:

1  Memorizing the verify_data from the last finished messages
   (extend the session structure to keep a copy)
   2x memcpy()
   one after creating client.finished and after verifying server.finished.

2  add the verify_data to the handshake message hash for renego
   1x if ()  plus 2x  add_to_handshake_message_hash(previous.verify_data)
   after processing server hello

extra: the handshake

3  add the fake ciphersuite ID to the clients ciphersuite list
   can be as simple as adding an entry to a statically comiled structure,
   but 5 statements to add it dynamically is still ok

4  check the ServerHello for the server-signal to decide wether to abort
   talking to an unpatched server
   1x if  ( ... server_version ...)  {  send_alert( ) ; goto error }

more extra: still talk to old servers if config permits it

5  config parsing

6  put a second condition into the if() in (2)

The TLS extensions stuff requires at least 3x the amount of code,
is a complete waste for the code and for the network bandwidth.

Just dump the completely unnecessary TLS extension gift wrapping
for the fix and get over it.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 13:28:45 +0200

At Mon, 16 Nov 2009 01:36:55 +0100 (MET),
> Everything else is options for vendors and users.

This is an interesting suggestion, but I think it has some problematic
aspects.

As has been noted several times, if the client desires to guarantee
that it does not form connections to unpatched servers, then servers
need to behave differently only on the initial connection. Your
proposal doesn't accomodate this.

Obviously this could be fixed--the natural approach is to modify
the server's Finished even on the initial negotiation, but this
requires conditional behavior in the Finished processor, which
is sort of distressing. The problem becomes even more complicated
when we consider resumption. 

We could use other mechanisms, such as ServerRandom signalling, but
we're now at the point where we're generating a lame version of
extension signalling using other mechanisms. Absent some evidence that
there is a real SSLv3 compatibility issue, I'm not sure why that's a
good idea.

On an aesthetic level, the TLS handshake hashes are just that,
handshake hashes. Injecting new data into that computation doesn't
strike me as really that architecturally fantastic an idea. If we
were to go down that road, I suspect that Rob Dugal's suggestion
of just continuing the handshake hashes would be superior.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 13:34:24 +0200

At Mon, 16 Nov 2009 11:53:00 +0100 (MET),
> all protocol versions of TLS out there SSLv3->TLSv1.2.

Perhaps you should consider that other people have a different view of
the problem than you do. In particular, I don't think there is 
anything like consensus that we need to fix SSLv3, a protocol
which was never controlled by IETF--and in fact wasn't even
published by it as informational.

> in TLSv1.2, 

Not that it matters, but his is incorrect. TLS 1.2 requires extension
processing. See S 7.4.1 of RFC 5246:

   Servers MUST NOT send this extension.  TLS servers MUST support
   receiving this extension.

> only to fix something that has nothing to do with

You're entitled to your opinion, of course, but I'm unconvinced.

> Think about the lines of code for a client:

I don't agree with your analysis of code complexity, but even if
you were correct the implementation effort is in any case so
minimal compared to the size of the deployment problem
that it strikes me as largely irrelevant. Moreover, we already
have implementations of RI, so the marginal implementation
effort is even lower compared to doing something new.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 15:05:31 +0100 (MET)

>    receiving this extension.

You're refering to the signature algorithms extensions, which
clients MUST NOT send if they're offering to talk TLSv1.1?
OK, I wasn't aware of that.  Count the servers on the Internet
that support TLSv1.2 today with your left hand and substract
them for the rest of the servers out there.

Do you realize how much implementation and testing is involved when
shipping the fix as a TLS extension.

If someone with an old server, who doesn't implement renegotiation and
TLS extensions wants to add this patch, he will need to add the entire
TLS extensions handling in a generic fashion and require a significantly
larger interop testing scenario to make sure that it acutally works:

1.  client without Extensions
2.  client with 1 Extension   no RI

3.  client with 1 Extension   RI
4a. client with 2 Extensions  RI as first
4b. client with 2 Extensions  RI as 2nd
5a. client with 3 Extensions  RI as first
5b. client with 3 Extensions  RI as 2nd
5c. client with 3 Extensions  RI as 3rd

So that means that poor server maintainer will also have to build
a client with all that stuff in order to test whether the server
implementation is correct.

Compare this to the extension less approach:

1.  client without patch
2.  client with    patch

and all he needs to check is whether the signaling works.

> effort is even lower compared to doing something new.

You're going to waste network bandwith eternally in a completely
useless fashion.

So you want the IETF to rubber-stamp an obviously inferior approach
because you prefered to come up with a solution in secret?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 15:20:00 +0100 (MET)

> effort is even lower compared to doing something new.

There is obviously no surprise that those who have already implemented
this proposal in secret have a bias towards using it.  Most of them
are actually affected by the problem, because they offered TLS
renegotiation on the server side.

Please consider that you are asking a lot of other implementors,
who do not have an implementation yet, and many of which are not
actually vulnerable to the problem, to implement this.
For them, the difference between a TLS extension RI and a much
smaller and more efficient extension-less solution can be
very significant -- in particular when it comes to testing
the server-side of the generic extensions handling.

The amount of code changes for the extension-less solution is
rather small, this is _NOT_ going to be a burden for the
implementors that have experimenting with TLS extension RI.
It will be LESS than a day of work for each codeline.

Offering UIs or APIs to configure policy is more than 10x
the effort than implementing the actual protocol fix
(which, as I said, is basically the same as the TLS extension RI,
just without the superfluous TLS extension wrapping).
And that policy configuration stuff will work equally well
for both.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 16:32:24 +0200

At Mon, 16 Nov 2009 15:05:31 +0100 (MET),
> You're going to waste network bandwith eternally in a completely

This strikes me as a fairly unconvincing objection. The average TLS
handshake consumes something like 1+ KB. This extension consumes
something like 45 bytes. Given that when we did TLS 1.1 added
16 bytes to every single CBC datagram, I'm having trouble getting
worked up about the additional overhead.

> because you prefered to come up with a solution in secret?

No, thats not what I want.

(1) It's your opinion that this is "obviously inferior". I don't
    agree, for reasons I've already indicated.

(2) I didn't prefer to come up with a solution in secret. I was
    informed of this issue in secret, worked with others to
    develop a fix, and then submitted it to the IETF for public
    review and comment. What, exactly, is it you think I did
    that was inappropriate, bearing in mind that I was informed
    of the issue under NDA?

More generally, I appreciate that you feel that you're technically
right and others are wrong, but I'd ask you to remember that
others may have come to other conclusions and that it doesn't
really help to imply as you do above that they're acting in bad
faith.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 16:37:09 +0200

At Mon, 16 Nov 2009 15:20:00 +0100 (MET),
> renegotiation on the server side.

Well, I don't know who "most of them" you're talking about is. I did
the original cut of the OpenSSL implementation and it's not like I 
operate a service that relies on TLS server-side renegotiation. I
just thought it would be a public service to write the code. I'm
sorry if that offends you.

> actually vulnerable to the problem, to implement this.

I'm not saying any such thing. If you're not willing to do 
server side renegotiation I think it's perfectly appropriate
to make no changes to your implementation.

> It will be LESS than a day of work for each codeline.

Yes, as I said above I consider the entire implementation effort
issue to be a complete red herring. I was merely observing
that if one takes it seriously it's not clear that it actually
cuts in the direction you are arguing.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Nov 2009 11:03:20 -0600

> because you prefered to come up with a solution in secret?

That is being unfair.

It was not EKR's decision to work on a fix in secret, it was mine and
Steve Dispensa's. We thought that we would have a better chance at
presenting a good fix for the bug along side its disclosure if we
brought some of the relevant engineering types together at the beginning
of the process.

We did tentatively agree on a proposal for an Internet Draft in secret,
and now we are seeing the limitations of that approach. It would not
have been anyone's first choice, least of all EKR's.

- Marsh

---

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

> have been anyone's first choice, least of all EKR's.

It is _not_ my intention to critizise that people develop ideas or
protocols outside of the IETF (open or closed group) and then come
to the IETF for standardization.  That's actually quite common and
not a problem.

But when a proposal enters the IETF process, the IETF and the
working group should discuss it based on its technical merits.

I'm getting the impression that the technical merit is not getting
the attention that it deserves.  TLS extensions are evidently largely
untested in the installed base.  The majority of the installed clients
does _NOT_ send it, and those clients that have started sending it,
apparently didn't dare to do this without an automatic fallback.

Having to retrofit the TLS extensions in a generic fashion into
SSLv3 and TLSv1.0 servers is a completely unnecessary and trivially
avoidable roadblock for maintainers.

And it doesn't seem to be to leave the fallbacks or SSLv3-compatibility
options that exist in current Browsers completely out in the rain,
where we could also trivially cover those scenarious with the
smaller and easier-to-implement extension-less approach.

Considering the urgency of the problem, now is a particularly
bad time to begin gathering interop experience with TLS extensions,
given that TLS WG didn't care about them for years.

To me, it looks like the REAL problems with the installed base described
in draft-pettersen-tls-interop-experience-00.txt (June 2006 !) didn't
result in any significant actions by the TLS WG to improve this, let
alone determine the scope and severity of the problems.

Quoting Section 6. of  draft-pettersen-tls-interop-experience-00.txt

   6.  Consequences

   As a consequence of the problems detailed above, many mass-market
   client vendors have had to deploy SSL/TLS implementations that
   disable protocol features if the server does not understand it.  In
   particular, this was necessary both for the move to TLS 1.0, and to
   TLS 1.1, but it has also become necessary for TLS Extensions.

-Martin

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Mon, 16 Nov 2009 12:12:10 -0500

I thought it was the preferred IETF approach to implement a proposal before
moving it forward? 

-- 
Regards,
Uri
<Disclaimer>

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 09:56:15 -0800

> that they might be using reviewed before the dare touching it.

I don't know where you got the idea I was talking about buggy servers.

The attack requires that there be a man-in-the-middle between the
client and server.  The MITM handshakes once with the server.  The
client then handshakes with the server via the MITM, so:

   - the client sees the handshake as its initial handshake
   - the server sees the handshake as a renegotiation

This is the point: the client is attacked on its *initial* handshake.

Therefore the client needs to be protected on its *initial* handshake.

It doesn't matter what happens after that.  If the client has completed
its initial handshake and there was no MITM, it is impossible for a MITM
to insert itself in the next handshake (i.e. a renegotiation).  So from
the client's point of view the only handshake it needs to be concerned
with (in terms of security not mechanics) is the initial one.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Nov 2009 12:04:36 -0600

> with (in terms of security not mechanics) is the initial one.

I hear this often enough that I don't argue with it every time,
nevertheless...

There is another attack which is a mirror-image of this one, where the
client sees a renegotiation but the server only sees one session.

One may dismiss this attack with the reasoning that "well it's the
client's fault for not checking the cert at the right point". Perhaps
for some specific protocol on TLS that may be true, but there doesn't
appear to be anything the TLS protocol itself that requires clients to
authenticate (rather than the other way round).

I strongly suspect many actual client applications are vulnerable to
this attack.

For these reasons, I suggest that we are unsafe in concluding that all
vulnerabilities can be fixed at the server.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 10:36:55 -0800

If a client doesn't check the server's certificate, it is subject to
any man-in-the-middle attack.  One of the requirements is that a client
verify the certificate.  If a client doesn't do that, how can we
possibly protect it???

I'm interested in providing the best defense to a client that is aware
of the MITM renegotiation problem when faced with having to interact
with possibly-unpatched servers.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Nov 2009 13:06:51 -0600

Michael D'Errico wrote:
> any man-in-the-middle attack.

I was going to give the example of an anonymous server and an
authenticated client, but it seems prohibited by the spec: "Anonymous
servers cannot authenticate clients".

Nevertheless, it could be done with anonymous connections in which the
client retro-actively authenticates the server. One sees this kind of
thing in sample code all the time.

> One of the requirements is that a client
> verify the certificate.

Read closely:
>  If the server is authenticated,
>    its certificate message must provide a valid certificate chain
>    leading to an acceptable certificate authority.  Similarly,
>    authenticated clients must supply an acceptable certificate to the
>    server. Each party is responsible for verifying that the other's
>    certificate is valid and has not expired or been revoked.

It requires that the endpoints _validate_ the cert chain. I haven't
found where the spec says the certs have to be the right ones.

Indeed it seems that a common application error is to hand the TLS
library an open socket and let it validate whatever cert shows up from
the server. Another form of "authentication gap" perhaps?

> If a client doesn't do that, how can we
> possibly protect it???

By restoring the application-API guarantee that was lost when
renegotition was added to ssl: both ends know they are talking to the
same part during the entire connection, even if some of the sessions
have one or more anonymous endpoints.

> with possibly-unpatched servers.

Definitely. Also the best defense to patched servers talking to
unpatched clients, with or without renegotiation.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 20:12:22 +0100 (MET)

> This is an interesting suggestion, but I think it has some problematic

The other options you're looking for are described in
<[email-masked]> 
Date: Mon, 16 Nov 2009 11:53:00 +0100

> there is a real SSLv3 compatibility issue, I'm not sure why that's a

I really don't see this fix as an extension.  It should have been
an integral part of the SSLv3 protocol from the beginning.

This situation is really special.  So far it is a one in 14 years event.
I do not expect that it is going to reoccur on a regular basis
that we have to go back several protocol revisions to fix such
a comparably significant shortcoming the TLS base protocol.

> of just continuing the handshake hashes would be superior.

I only mind the TLS extension wrapping and sending the finished
messages unnecessarily over the wire.  Otherwise I'm very open.

Continuing the handshake messages creates one little theoretical
problem.  In theory a client could send out a new ClientHello
right after the client.finished message and not wait for Server.finished.
(SSLv3 explicitly says this, but I think this text was removed
in TLS). 

In discussions about cutting down the number of round-trips
I had also suggested such an optimization (which is similar
to piggy-back data on the last security context token of
a gssapi security context establishment with an odd number
of context-level tokens for security context establishment).

For that scenario, continuing the handshake message hash would
not work, I believe.

During the past, people who asked for client identity protection
in TLS client cert authentication were given the advise to
immediately renegotiate.  There, where such an optimization
springs to mind, simply continuing with the handshake message
hash before ClientHello would interfere with starting
renegotiating without waiting for the server.finished.

This is why I suggested adding the verify_data of the previous
finished messages always directly after ServerHello.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 19:30:58 +0000

> shipping the fix as a TLS extension.

Yes. Are you suggesting that a fix that uses some other ad hoc signalling
mechanism does not need to undergo thorough interoperability testing?

> larger interop testing scenario to make sure that it acutally works:

If a server doesn't implement renegotiation, then it is already as secure
as it can be with respect to this attack. The server only needs to be
patched so that strict clients will recognize it as patched.

To achieve that, the server clearly must signal something in a message
that it sends. If that is not done using an extension, then it must be
done using another mechanism such as recognizing a magic ciphersuite and
stuffing its response in some covert channel (which I cannot believe we
are even seriously discussing, frankly).

Remember, complicated kludges such as fallback to accomodate broken server
implementations are only needed, if they are needed at all, on the client
side. Implementing extensions on the server side is completely trivial.
Many server implementors have already done that work, whereas *no* server
implementors have done the work to support any newly invented signalling
mechanism.

> You're going to waste network bandwith eternally in a completely

The bandwidth usage is completely insignificant, even for highly constrained
environments. If I've calculated correctly, the size of the extension is
5 bytes in each direction in the most common, non-renegotiating case
(17 or 29 bytes when renegotiating), and it adds no round-trips. Compare
that to X.509 certificate sizes, which are typically at least 1 KiB each.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 20:39:13 +0000

> verify the certificate.  If a client doesn't do that, how can we

The important case here is where client certificates are involved.
Normally, a MITM would not be able to authenticate its connection to
the server using a client cert held by the actual client -- that cert
authenticates only the connection from client to MITM, and replaying
the CertificateVerify message (in the case of a client cert with
signing ability) does not work.

Therefore, the form of the attack described by Marsh does break a
security property that TLS is intended to guarantee, independent of
any checking by the client of the server certificate.

Does anyone use "fixed_dh" client certs that lack signing ability, BTW?

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 23:50:31 +0000

> to make no changes to your implementation.

Note that if a server makes no changes, then strict clients will
refuse to connect to it, even on an initial handshake. So *all*
servers that need to be interoperable with strict clients necessarily
have to be changed. This applies to any possible fix that supports
the strict client policy.

(Attempting to detect whether a server supports renegotiation by
trying to renegotiate, doesn't work, because:
 - an attacker can force a renegotiation failure;
 - the server might only reject unsolicited renegotiations;
 - if the client detects a non-renegotiating server and then
   reconnects, it has no assurance that the server it reconnects
   to is the same one -- consider wildcard certificates for instance.)

> cuts in the direction you are arguing.

I agree completely; the implementation effort for approaches
using extensions is not significantly greater than for any other
signalling mechanism. For the subset of implementations that
already support extensions, it is less.

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Nov 2009 01:08:37 +0100 (MET)

> already support extensions, it is less.

Looking at the code for TLS extensions in openssl-0.9.8g
your statement seems wrong.  It's more.

And if a codebase doesn't have extensions yet, it is significantly
more, because extensions is a generic container and there may
be more than one.

The latter is also a reason why interop testing becomes a magnitude
more complex, because you need to interop-test a huger number of
possible combinations.  Not necessarily for existing extensions code,
but definitely for extensions code that needs to be implemented first
time just for this fix.

It is extremely unwise to ask especially the maintainers of _old_ code,
who are most likely not even vulnerable (lacking server-side renegotiation
entirely), to add generic TLS extensions code and build themselves a
test client that can simulate all the various combinations possible
with TLS extensions in order to test they're processing it correctly.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Nov 2009 01:49:32 +0100 (MET)

> mechanism does not need to undergo thorough interoperability testing?

For the ad-hoc signaling a patched browser will be perfectly
sufficient for testing.

For TLS extensions, you will need to develop yourself a whole test client
that is able to generate a certain number of test-scenarios.

See here: http://www.ietf.org/mail-archive/web/tls/current/msg04351.html

> are even seriously discussing, frankly).

Huh?

If the client is signaling that it is updated and will understand
whatever the spec says the server should indicate in return,
then this is just fine.  The spec could even go as far as completely
redesigning the ServerHello, completely different from TLS.

We could also invent a new handshake message to be sent just after
ServerHello, if people prefer this instead of re-purposing
an existing element of ServerHello in a well-defined situation.
(it would need to be a handshake message, alerts are invisible
to the handshake message hash and finished mac).

> implementors have done the work to support any newly invented signalling

I have seriously thought about how to implement my ideas in OpenSSL,
and there your assumption about TLS extensions being easier do _not_ apply.

> that to X.509 certificate sizes, which are typically at least 1 KiB each.

It is still pure waste, any way you look at it.

-Martin

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Nov 2009 20:05:29 -0800

> working group should discuss it based on its technical merits.

The IETF is about rough consensus and running code.  Technical merit is one 
aspect of that.  Time to market can be important.  Technical maturity of 
the specification can be important.  The best or perfect proposal often 
takes longer to develop than the good enough proposal and thus loses.  Just 
look at how badly HTTP is designed when it comes to authentication -- but 
it was good enough to standardize.  The HTTP Next-Generation working group 
failed because HTTP is good enough.

draft-rescorla-tls-renegotiation-00 already has lots of running code; and 
that's a traditional IETF litmus test that correctly makes alternative 
proposals far less attractive.

If you want your alternative proposal to be considered, submit an Internet 
draft and get some running code and feedback from implementations showing 
your proposal would deploy protection to more users than 
draft-rescorla-tls-renegotiation-00.  Then you may sway people to your 
viewpoint.

But time-to-market is __very__ important for this particular problem.  I 
think you have already spent too much time arguing on the list and not 
enough time writing specs and gathering implementation experience to make a 
viable alternative proposal.

		- Chris

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 16 Nov 2009 20:35:50 -0800

> proposals far less attractive.

Could we get a show of hands for working implementations of that draft?

- I have one in NSS (used in Mozilla clients and Sun servers).
- Michael D'Errico has one. I've successfully i18y tested with it.
- Microsoft has one.        I've done very limited I18y testing with it.
- OpenSSL has one, IINM.    (Haven't done a test with it yet)
- RSA claims to have one, IINM.  (Haven't tried it yet, Either.)

Are there others?

> But time-to-market is __very__ important for this particular problem.  

I agree.

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 21:03:55 -0800

> If you want your alternative proposal to be considered, submit an 
> Internet draft and get some running code and feedback from 
> implementations showing your proposal would deploy protection to more 
> users than draft-rescorla-tls-renegotiation-00.  Then you may sway 
> people to your viewpoint.

Here is how draft-rescorla-tls-renegotiation-00 fails to protect the
most people:

   - there are so many interoperability problems with TLS extensions
     that even the author of the draft suggests that a "lenient"[*]
     client not send the extension on its initial connection

   - there will be a transition period where some servers absolutely
     need to continue allowing unpatched clients to perform the current
     vulnerable renegotiation.

   - a lenient client's handshake without the RI extension looks just
     like an unpatched client that these unfortunate servers need to
     continue supporting

   - a man-in-the-middle can take advantage of these three points to
     victimize a patched client talking to a patched server!

Just today many of us have converged on an alternate solution that does
not have this serious problem.  Instead of using extensions with all
the myriad problems, the only bits-on-the-wire change is to include a
single special cipher suite that signals to the server that the client
wishes to use a new calculation of the Finished messages that includes
the verify_data from the previous handshake.  I suggested that an alert
message could be used for the server to acknowledge back to the client.

This uses only features that are present in SSLv3, so it is much more
likely to be implemented quickly and correctly, and it does not require
implementations to add any code for extension processing if they don't
already support extensions.  It also protects the lenient client and
unfortunate servers above since there is no reason not to include the
magic cipher suite in ALL handshakes.

Here is a pointer to a summary of the proposal:

   http://www.ietf.org/mail-archive/web/tls/current/msg04393.html

I am not a spec. writer, so someone else should write it up.  If it is
adopted I will implement it in my test server in short order for anyone
to test against.

Mike

[*] a lenient client is one that would connect to any server regardless
of whether it is patched or not.  Since there is a not-insignificant
chance that a server will barf on the use of extensions, and the lenient
client wouldn't abort the handshake even if the extension is not
returned by the server, it is less painful to just do what's always
been done.

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 21:16:22 -0800

>> But time-to-market is __very__ important for this particular problem.  

Time is important, absolutely.  But the important measure of time is not
how fast we publish a spec.  It is how quickly that spec. is implemented
by the rest of the world!

If extensions are required in our published spec, there will be a hurdle
for some that is entirely unnecessary.  The responsible thing for us is
to use features available in the SSLv3 spec.  I have summarized a
proposal that contains ideas from many people on this list which uses only
SSLv3-compatible features:

I can implement this very quickly, and it will be less code than what it
took to implement the current draft (even though I already supported
extensions).

Mike

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 02:19:51 -0500

>- RSA claims to have one, IINM.  (Haven't tried it yet, Either.)

Pre-release versions of the following products support the extension: RSA 
BSAFE(R) SSL-J, RSA BSAFE(R) Share for JavaTM Platform, RSA BSAFE(R) MES, RSA 
BSAFE(R) Share for C/C++. RSA BSAFE(R) SSL-C and RSA BSAFE(R) SSL-C ME will 
follow in the coming weeks.

If anyone would like to test interoperability with our products please send me 
an email. As per my earlier post:

RSA, The Security Division of EMC, has created a TLS Interoperability Server 
to allow inter-op testing of TLS.

The static content of the server is here http://203.166.62.199/

Please email me the following information so I can have your IP address added 
to a white list so you can access the inter-op servers themselves.

* Contact Information Name Organization or Company name and Business
  Unit Address Phone Number Email address
* IP Address(es) which you  will be connecting from.
* Product(s) and version(s) you will be testing.
* TLS protocol versions, cipher suites and curves you wish to test.

------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 17 Nov 2009 11:39:11 +0100

> - RSA claims to have one, IINM.  (Haven't tried it yet, Either.)

Opera have an implementation, which is currently being polished with  
warning and error messages, and a kill-switch.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2009 13:09:24 +0000

Chris Newman wrote:
> The IETF is about rough consensus and running code.  Technical merit is
> one aspect of that.  Time to market can be important.  Technical
> maturity of the specification can be important.  The best or perfect
> proposal often takes longer to develop than the good enough proposal and
> thus loses.  Just look at how badly HTTP is designed when it comes to
> authentication -- but it was good enough to standardize.  The HTTP
> Next-Generation working group failed because HTTP is good enough.
> 
> draft-rescorla-tls-renegotiation-00 already has lots of running code;
> and that's a traditional IETF litmus test that correctly makes
> alternative proposals far less attractive.

Having watched the recent list traffic I find the above convincing.
I'd love to see a -01 of the above containing the changes EKR has
mentioned already, and then a WGLC on that.

S.

---

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

OK.  I'm going to write an I-D.

I've not done this before -- it'll take me at least one day.

In my previous IETF participation, document authors were always
quite open minded to improvements, so I never had to actually
write a counterproposal.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 08:25:37 -0800

> mentioned already, and then a WGLC on that.

I went back and re-read all his messages and the only change EKR
suggested was to use a magic cipher suite *only as a fallback* if
an initial attempt to use RI failed.  All other suggestions did not
convince him to make any changes.  I could be wrong, but that is
how the messages read.

Plus I've pointed out that RI does not protect the combination of a
lenient client and lenient server!  This is a severe drawback since
patched peers are still vulnerable during the transition period
where some servers remain lenient (allow current insecure
renegotiation).  The following fixes that since there is no fallback
needed and no reason for a client to not signal its support in every
handshake.

The whole point of RI is to get the previous handshake's verify_data
into the handshake messages of the current session.  This can be
done without extensions and does not require any fallback logic.

You just need three things:

   1) a client-to-server signal
   2) a server-to-client signal
   3) somehow incorporate the previous verify_data in the handshake

(1) can be achieved by simply incorporating a magic cipher suite in
the ClientHello.  Since that is the *only* change to the handshake,
it has zero possible interoperability problems.  Extensions are
known to be problematic; web browsers have extremely complicated
logic including reconnecting and falling back to not using extensions
to try to accommodate the various server implementations.  This magic
cipher suite signal would be used in all handshakes since it can not
cause any problems.  Existing browser fallback logic would not get
any more complicated.

(2) can be done many ways but I think Martin came up with a better
idea than the alert message I proposed.  It is to toggle the upper
bit of the low-order byte of the version in the ServerHello.  For
SSLv3, 0x0300 would become 0x0380; TLS 1.0, 0x0301 would become 0x0381,
etc.  This is forward-compatible too; the next version of TLS would
be 4.0, 0x0400.  This signal would be used in all handshakes from
SSLv3 through TLS 1.2.  The version in the record layer would NOT
change.

(3) can be done in a variety of ways.  RI sends the data over the
wire, but this is unnecessary since both the client and server know
it already.  EKR doesn't like the idea of a "virtual" handshake
message, but this is an easier way to incorporate the data than
requiring changes to three PRF computations (SSLv3, TLS 1.0/1.1, and
TLS 1.2).

I'm open to suggestions for a better (3) or even better (1) and (2),
though those seem sufficiently simple.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2009 07:07:47 +0200

At Mon, 16 Nov 2009 20:35:50 -0800,
> - OpenSSL has one, IINM.    (Haven't done a test with it yet)

Yes, there is one in the OpenSSL tree on the OpenSSL_0_9_8-stable
branch.

-Ekr

---

From: Nasko Oskov <[email-masked]>
Date: Tue, 17 Nov 2009 16:38:09 +0000

Michael D'Errico wrote:
>The whole point of RI is to get the previous handshake's verify_data into
>the handshake messages of the current session.  This can be done without
>extensions and does not require any fallback logic.
>
>(1) can be achieved by simply incorporating a magic cipher suite in the
>ClientHello.  Since that is the *only* change to the handshake, it has zero
>possible interoperability problems.  Extensions are known to be
>problematic; web browsers have extremely complicated logic including
>reconnecting and falling back to not using extensions to try to accommodate
>the various server implementations.  This magic cipher suite signal would
>be used in all handshakes since it can not cause any problems.  Existing
>browser fallback logic would not get any more complicated.
>
>(2) can be done many ways but I think Martin came up with a better idea
>than the alert message I proposed.  It is to toggle the upper bit of the
>low-order byte of the version in the ServerHello.  For SSLv3, 0x0300 would
>become 0x0380; TLS 1.0, 0x0301 would become 0x0381, etc.  This is
>forward-compatible too; the next version of TLS would be 4.0, 0x0400.  This
>signal would be used in all handshakes from
>SSLv3 through TLS 1.2.  The version in the record layer would NOT change.
>
>(3) can be done in a variety of ways.  RI sends the data over the wire, but
>this is unnecessary since both the client and server know it already.  EKR
>doesn't like the idea of a "virtual" handshake message, but this is an
>easier way to incorporate the data than requiring changes to three PRF
>computations (SSLv3, TLS 1.0/1.1, and TLS 1.2).
>
>I'm open to suggestions for a better (3) or even better (1) and (2), though
>those seem sufficiently simple.

It was indicated that some implementations use random value for the
timestamp part of the random values exchanged. If this is correct and there
are no interop issues with it, then we can use the timestamp as place to
include a few bits as well. If we reserve the top 4 bit of the most
significant byte, we can set them to predefined values to signal what we
want. The side effect will be forwarding time enough in the future to allow
us to move a newer version of the protocol:

$ date -d @`echo "ibase=16; F0000000" | bc`
Mon Aug  5 01:04:00 PST 2097
$ date -d @`echo "ibase=16; E0000000" | bc`
Tue Feb  1 03:39:44 PST 2089

The benefit of using the timestamp is that it will be the same signal both
ways. We don't have to alternate between cipher suites and other methods on
the other way. I believe this will also be easier to implement, since new
alert messages and unexpected server extensions will requre a lot more code
change and case specific logic.

Using two values allows both client and server to maintain the calculation
of the finished message intact, but have knowledge if the handshake is
expected to be initial or renegotiated. If expectations don't match,
handshaking is terminated.

Just an idea for signaling, since we are enumerating ideas.

Nasko

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Tue, 17 Nov 2009 11:44:52 -0500

On 11/17/09  11:38 , "Nasko Oskov" <[email-masked]> wrote:

> Michael D'Errico wrote:
>> ........You just need three things:
>> 
> include a few bits as well.

>From cryptographic point of view I hate seeing "timestamp" part of a random
value filled with yet another random. If your [P]RNG quality is less than
perfect you're seeking trouble.  (And if your RNG is perfect - why did you
need to put a timestamp there anyway?)
-- 
Regards,
Uri
<Disclaimer>

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 09:16:33 -0800

> Just an idea for signaling, since we are enumerating ideas.

Since there are implementations that randomize the timestamp, then with only
4 bits, there is a 1-in-16 chance that these implementations will randomly
generate one of the patterns.  If the full 32 bits were used, the odds go
down considerably.  Two specific dates could be used, one for client and one
for the server.

Though personally I prefer using the cipher suite and server version (just an
opinion).

Mike

---

From: Yair Elharrar <[email-masked]>
Date: Tue, 17 Nov 2009 19:28:11 +0200

> down considerably.  Two specific dates could be used, one for client and one

A few days ago I suggested using 'INIT' and 'RNEG' as fake timestamps for server-to-client signaling of the current session state. Both [fake] dates have passed so it's highly unlikely that they'll ever be used for anything else.

--

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

---

From: Steve Dispensa <[email-masked]>
Date: Tue, 17 Nov 2009 11:35:58 -0600

> Yes, there is one in the OpenSSL tree on the OpenSSL_0_9_8-stable

There is a working GNUTLS implementation, although I'm in the process of
porting it forward to the latest dev branch.

  -Steve

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2009 17:50:00 +0000

At Tue, 17 Nov 2009 13:09:24 +0000,
> mentioned already, and then a WGLC on that.

I just submitted an -01 version of the draft. This includes the
following changes:

1. Clarification of the encoding of the extension per the issue
   by Eric Young and Nelson Bolyard.
2. A bunch of discussion of fallback and the downgrade issue.
3. A SHOULD level requirement that implementations which simply
   reject negotiation still provide an empty extension when
   requested by the client, thus signalling that they have
   been updated.
4. A new section 4.3.1 that describes a magic cipher suite
   to be used to prevent downgrade attack on implementations
   which fall back to no extensions on handshake failure.
   
I've left point (4) as an OPEN ISSUE because it wasn't clear to me
what the WG feeling was. My general feeling is that it's not necesary:
SSLv3 servers which upgrade to fix this issue by refusing
renegotiation can easily arrange to simply ignore the extension, at
which point no downgrade attack is possible. Servers which don't do
even this can be presumed to be vulnerable and it doesn't seem that
bad to simply fail in this small number of cases. That said, I don't
have a problem with this feature f the WG wants to since it's not
being used by negotiation but merely as a failsafe, and I thought
it was important to get a concrete proposal for this mechanism
on the table.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2009 17:51:46 +0000

At Tue, 17 Nov 2009 08:25:37 -0800,
> convince him to make any changes.  I could be wrong, but that is

Well, the other changes I've seen suggested pretty much amount to
discarding RI in favor of another approach, so I don't think
it's really surprising I didn't incorporate them into RI.

> renegotiation).

I don't think this is entirely accurate.

It doesn't protect the combination of a lenient server and a client
which falls back to not using the extension at all, i.e., a client
which tolerates non-compliant servers which do not properly ignore
unknown extensions. Given that that's going to be a fairly small
fraction of servers and that those servers are pretty much by
definition unpatched (more or less the one case where you can
accurately detect vulnerability without a huge number of false positives)
I'm not seeing that it's a crisis to fail negotiation at this point.

With that said, the extra cipher suite solves this problem AFAICT
and I have no problem with adding that if it's WG consensus.

> SSLv3 through TLS 1.2.  The version in the record layer would NOT

Changing the version number in response to something other than a
version number advertisement seems extremely problematic to
me.

> requiring changes to three PRF computations (SSLv3, TLS 1.0/1.1, and

Well, RI doesn't require changing the PRF or the virtual 

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Nov 2009 12:17:21 -0600

> Just an idea for signaling, since we are enumerating ideas.

My opinions:

We should use two bits in each direction:
0. "I'm patched"
1. "I'm lenient"
both default to false.

For signaling in the Client Hello I like the superfluous cipher suites
idea. Unless there are likely to be problems with advertising a new
cipher suite.

For the Server Hello I don't think there are any good options. The only
bits in there which are defined to not have any existing semantics are
the random_bytes (not the gmt_unix_time).

We should take 4 contiguous bytes from somewhere in the middle of the 28
random bytes, and interpret them as a uint32. In this new area we use
the bottom two bits as flags, and zero out the rest. These flags should
be sent regardless of whether or not the client requested it.

It is no one's first choice to destroy entropy from the random_bytes.
However, it seems there is little alternative. The remaining 24 bytes
still represent a generous amount.

Although this pattern of 30 contiguous zeros could occur randomly, it
would be a 1-in-one-billion occurrence.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 21:43:16 -0800

>    which fall back to no extensions on handshake failure.

You forgot to mention:

4.3.  SSLv3

    SSLv3 does not support extensions and thus it is not possible to
    securely renegotiate with SSLv3.  Deployments wishing to renegotiate
    securely will need to upgrade to at least TLS 1.0.

Is there some secret agenda to kill off SSLv3?  What is the point
of that?  SSLv3 accounts for more than one-in-five connections as
reported to this list.  There is an alternate proposal that does not
have this limitation, and is better in many other respects.  Why do
you keep pushing this one?

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Nov 2009 08:03:33 +0000

At Tue, 17 Nov 2009 21:43:16 -0800,
Michael D'Errico wrote:
> of that? 

Well, I don't think it's a secret that many feel that it would
be good for people to upgrade from SSLv3 to TLS. TLS includes
a number of useful security fixes and extended functionality.
So, it's not clear it's great to go out of our way to preserve
its use indefinitely.

With that said, I think that the quoted sentence is probably slightly
too strong.  There's no reason why extensions cannot be used with
SSLv3, it's just that the IETF has no change control on SSLv3 and so
it's kind of a matter of extrapolating 4366 to apply to the SSLv3
drafts. This is straightforward but undocumented.

> SSLv3 accounts for more than one-in-five connections as
> reported to this list.

Well, I've seen this claimed, but I haven't seen a citation for where
the data comes from. I'd be interested in seeing such a cite. The data
I've seen (and posted) suggests that servers support TLS very widely,
and certainly every piece of SSL/TLS-based software built on any even
remotely modern stack includes support for TLS, whatever it chooses to
negotiate.

>  There is an alternate proposal that does not

Because I feel that those other proposals are inferior in many
other respects? I'm not sure why this is so hard for you to
understand.

-Ekr

---

From: "Robert Dugal" <[email-masked]>
Date: Wed, 18 Nov 2009 07:39:20 -0500

I noticed you said this in the jabber log http://www.ietf.org/jabber/logs/tls/2009-11-12.txt 

[06:31:06] <EKR> It occurred to me the other day that there is a special case where hte server does not need to refuse renegotiation: when the client has sent no data yet.
[06:31:20] <EKR> This would allow step-up/SGC to continue to work 9assuming we cared it)

Our products do support step-up/SGC and some customers may still be using it, or at least have servers with SGC certificates.
Since there is no vulnerability is this special case, should some note be added to the draft? 

-- 
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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, November 17, 2009 12:50 PM
To: Stephen Farrell
Cc: Chris Newman; [email-masked]
Subject: Re: [TLS] simplistic renego protection

   

-Ekr

---------------------------------------------------------------------
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: <[email-masked]>
Date: Wed, 18 Nov 2009 14:40:14 +0100

It seems many of the drawbacks of tls-renegotiation-00 you mention 
are in fact addressed (to some degree) in version -01? (mainly
by including the "magic cipher suite") Compared to -01, what do
you think the main differences are?

Best regards,
Pasi
(not wearing any hats)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Michael D'Errico
> Sent: 17 November, 2009 07:04
> To: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 15:36:42 +0100 (MET)

> you keep pushing this one?

This statement about SSLv3 actually reverts history.

The fact is, that SSLv3 has THE EXACT SAME provisions for
TLS extensions as TLSv1.0.

But TLS extensions seems to exclude _itself_ from being used with SSLv3
-- which looks like a pretty bad idea, given that the extensibility
of TLSv1.0 and SSLv3 is verbatim the same.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Nov 2009 15:41:31 +0100

> you think the main differences are?

As far as I can tell, -01 does not fix (*) the problem for
clients/servers that uses

   a) a SSLv3 implementation, or
   b) a original TLSv1 implementation (e.g., RFC 2246), or
   c) a TLSv1.1 implementation without support for extensions.

Providing a solution only for the latest version of TLS is akin to ask
people to upgrade to the latest release of a particular software rather
than provide a simple fix to the existing deployed software.

I'm hoping Martin will submit a draft on his ideas soon so we can
compare the two.

(*) Where "fix" means that TLS renegotiation works and is secure.

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 Nov 2009 16:39:11 +0100

I started off thinking that the simplistic approach is too much of a quick
and dirty fix to be considered seriously, but I'm slowly beginning to like
it more and more.

I see some compelling arguments.

1) Is what has been stated before about the problems with extensions. If
there are a considerable amount of implementations where adding extension
support introduce significant problems, an extension less approach has
merit.

2) Is that we seem to agree that TLS 1.3 will have an updated finished
calculation anyway, not requiring the use of extensions. If we define that
"future" finished calculation now and use it in the simplistic approach,
then that would actually be closer to future versions of TLS, compared with
an extension approach.

If we consider the magic cipher suite signaling anyway in the extension
approach. In that case, what is the added value of using extensions over
just invoking the "future" and fixed finished calculation?

Is it necessary for the server to signal to the client that is supports the
upgraded finished calculation? It seems to me that an upgraded client could
calculate it both ways and detect the server's capability based on which
finished message the server sends. It may not be not optimal, but seems
feasible.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 Nov 2009 16:44:54 +0100

Disregard this question. It was a false thought.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Nov 2009 15:41:37 +0000

At Wed, 18 Nov 2009 15:36:42 +0100 (MET),
> of TLSv1.0 and SSLv3 is verbatim the same.

Well, I'm not taking any responsibility for that. I didn't write
the original TLS extensions doc. That said, I suspect the feeling
was that the IETF didn't have any control of SSLv3, and so couldn't
mandate anything about it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Nov 2009 15:43:53 +0000

At Wed, 18 Nov 2009 15:41:31 +0100,
> than provide a simple fix to the existing deployed software.

I really don't understand this argument. Extensions are completely
compatible with TLS 1.0, 1.1, and as has been observed by
Martin, compatible in principle with SSLv3. Any fix will require
some changes to people's software. I don't see how that consists
at all of providing a solution only for the latest version of
TLS.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 08:05:51 -0800

> So, it's not clear it's great to go out of our way to preserve

The alternate method that does not use extensions is fairly complete.
People seem to have a problem with putting the server bit in the
version.  I can understand that, and am open to other ideas.  I've
suggested using a checksum within the server random for this, but
nobody has commented on it.

Thus you can not say we need to "go out of our way", the work is
already done, just needs some polish.

> remotely modern stack includes support for TLS, whatever it chooses to

Does it really matter what the exact numbers are for SSL vs. TLS?
If there are two proposals, one that supports both SSL and TLS, and
another that only supports TLS, why would you want to choose the
latter?

> other respects? I'm not sure why this is so hard for you to

You never give concrete reasons for your dislike of alternate ideas,
just that you don't like them.  That is your opinion and you are
entitled to it, but since you don't give constructive suggestions
for improvement, it is unhelpful.  If you gave suggestions they would
be considered and incorporated into an updated proposal.

Personally I like extensions.  A lot.  But they are not needed for
this, and because they are not widely implemented, forcing them on
the population is ill-considered.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 08:20:41 -0800

> you think the main differences are?

If you include a magic cipher suite, then you don't need to send
*anything* else from client to server.  This is what the alternative
does that I implemented yesterday.  The contents of the extension do
not need to be transmitted over the wire since both peers know what
it should contain.  As long as that information gets added to the
Finished message calculation (true in both proposals), the security
hole is patched.

Plus I believe the magic cipher suite in RI-01 is only for fallback
behavior.  The very fact that fallback behavior needs to be even
considered in RI is a showstopper in my opinion.  The alternative
does not require any of that.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 08:33:20 -0800

> support introduce significant problems, an extension less approach has

Agreed.

> then that would actually be closer to future versions of TLS, compared with

This is one of the reasons I so dislike RI.  The alternative presented
modifies the Finished calculation in a way that is forward-compatible;
it can be the default for future TLS versions, and that is the way it
is implemented in my code now.  If people don't like adding the previous
verify_data to the stream of handshake messages so it gets hashed along
with the rest, then please suggest a better way.

One note: at first I didn't like the idea of inserting the verify_data
immediately after the ServerHello, but when I implemented it, that was
actually the most natural place to put it.

> just invoking the "future" and fixed finished calculation?

None as far as I can tell.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 19:37:33 +0100 (MET)

> actually the most natural place to put it.

For the client, it is _the_ position where it reliably is in the posession
of the Server.Finished from the previous TLS handshake. (Think of
optimizing an renegotiation in order to protect the client identity,
where one wants to piggy back the ClientHello of the immediate
renegotiation onto the Client.Finished message.

Does anyone remeber that the TLS WG gave the advice to people asking
for identity protection to perform an initial client-anonymous
TLS handshake directly followed by a renegotiation with client-cert
authentication?

(a related discussion what about gss-api authentication
 around 20-dec-2006, Subject: [TLS] Comments on TLS identity protection)

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Nov 2009 12:51:47 -0600

> at all of providing a solution only for the latest version of

It appears that many SSLv3 servers and some "TLS1.0" do not correctly
ignore unrecognized extensions.

Therefore, it represents a breaking protocol change for the owners of
such systems.

Most admins are responsible for a variety of systems and no tools seem
readily available to even determine one's status.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 21:00:26 +0100 (MET)

Eric Rescorla wrote:
> at all of providing a solution only for the latest version of TLS.

We've been through this a few times.

There are going to be components out there that will not get
patched.  They might not implement renegotiation (or have it
disabled) and they're therefore not even vulnerable.

But we can not simply brick them (deny to talk SSL to them
in the future).

So Browsers will likely have to continue to offer an fallback
to extension-less ClientHello.

As long as Browsers do that, we can not protect them from
a downgrade attack -- unless we change the signaling for the
protected renegotiation into something that is going to be
interoperable with those old, unpatched and some even non-vulnerable
servers that are going to be with us for quite a while.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 22:22:48 +0100 (MET)

Robert Dugal wrote:
> [06:31:06] <EKR> It occurred to me the other day that there is
> a special case where hte server does not need to refuse renegotiation:
> when the client has sent no data yet.
> [06:31:20] <EKR> This would allow step-up/SGC to continue to work
> assuming we cared it)

Define "client has sent no data yet" ?

There is an implementors note in TLSv1.2, section about "Fragmentation"
that is as old as SSLv3 which requires that application can be
arbitrarily interleaved with a renegotiation handshake.

So the MitM can inject the data before forwarding the ChangeCipherSpec
message.  So whenever you implement something for this special case,
make sure that your TLS implementation checks "client has sent no data yet"
concurrently with verifying the finished message (unless it fails
reliably when receiving application data during the renegotiation
handshake).

> 
> Our products do support step-up/SGC and some customers may still be
> using it, or at least have servers with SGC certificates.

You mean like enumerating conceivable usage scenarios that
TLS extension RI is very likely to break?

Maybe a spec where that section is very small or empty
would be more appreciated by the community.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 01:59:48 +0000

> of TLSv1.0 and SSLv3 is verbatim the same.

Neither RFC 3546 nor RFC 4366 mention SSL at all. They do not exclude
the extension mechanism from being used with SSL. That usage is not
standardized by IETF because SSL is not described in any non-draft IETF
document (a decision that I disagree with; I think that SSLv3 should have
been documented in an informational RFC).

---

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

> to extension-less ClientHello.

This is a non-sequitur. Lenient clients don't need to send the
extension in the ClientHello of an initial handshake. Strict clients
must not be able to talk to unpatched servers, by definition.

Unpatched servers *will* eventually be "bricked", as you put it,
if they stay unpatched as an increasing proportion of clients
adopt a strict policy. There is no possible solution to that other
than patching all servers, including those that don't support
renegotiation. This is true also for the proposed alternatives
to RI.

---

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

> mandate anything about it.

Actually, the main argument in the WG at the time was about whether
extensions should be delayed until TLS 1.1, or supported for TLS 1.0:

<http://www.imc.org/ietf-tls/mail-archive/msg02053.html>
<http://www.imc.org/ietf-tls/mail-archive/msg02058.html>
<http://www.imc.org/ietf-tls/mail-archive/msg02082.html>

(The 'Thread Index' links in each article are busted.
The archive by thread is currently at
<http://www.imc.org/ietf-tls/mail-archive/thrd17.html>,
although that link will become incorrect because older index
pages are renamed when the current page becomes full.)

I was arguing for extensions to be supported for SSLv3:

# Also note that the dns_name attribute is useful for SSL v3.0 as
# well, and there's no particular reason to exclude it from being
# used in that case (i.e. as a minimal change to servers to allow
# them to support virtual hosting without having to implement TLS).

but another author of the draft responded with

# Re: SSLv3.0, I never intended the dns_name extension to be excluded
# from there.  However, since this is the TLS working group and since
# there is no living specification of SSLv3.0 the point seems moot
# and/or out of scope.

and there was no dissent to that position.

(Note that the "criticality flag" mentioned in that thread was
dropped. I think RI would have been the first extension to be
"critical" in that sense, when used by strict clients.)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 04:48:03 +0000

> [06:31:06] <EKR> It occurred to me the other day that there is a special case where hte server does not need to refuse renegotiation: when the client has sent no data yet.

and the session is not resumed, and the server has sent no data.

Many application protocols have the client sending a command or
"hello" message before the server sends any data, but some don't,
and TLS doesn't depend on that. If the server thinks it has already
sent some data, then it may not send it again in the renegotiated
session, which could confuse the client in that session.

> Since there is no vulnerability is this special case, should some note be added to the draft? 

SGC is not relevant here; it does not use renegotiation.

AFAIK, the only clients that use Step-Up are international versions of
Netscape Communicator 4.02 to 4.72 inclusive [*], and possibly some
very early versions of Mozilla Suite before its official release.
Netscape 4.72 was released in February 2000. Those browsers are completely
insecure and no-one should still be using them, least of all if they
actually need 128-bit encryption.

The fact that a server uses a Step-Up certificate does not cause any
interoperability problem for other clients.

[*] <http://www.verisign.com/static/016585.pdf>

Technical documentation of Step-Up:
<http://marc.info/?l=apache-modssl&m=102520283911746&w=2>

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 04:53:47 +0000

> would be more appreciated by the community.

The reason why the fix breaks Step-Up has nothing to do with the use of
extensions, and the other proposals that have been made so far would
break Step-Up as well. It might be possible to avoid that, but only by
adding significant complexity and introducing greater risk of making
a mistake that might be exploitable. I'm opposed to adding that
complexity and risk.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 19:05:58 +0000

Nasko Oskov wrote:
>>> There are going to be components out there that will not get patched.  
>>> They might not implement renegotiation (or have it
>>> But we can not simply brick them (deny to talk SSL to them in the 
>>> future).
>>>
>>> So Browsers will likely have to continue to offer an fallback to 
>>> extension-less ClientHello.
>> 
>> This is a non-sequitur. Lenient clients don't need to send the extension in the
>> ClientHello of an initial handshake. Strict clients must not be able to talk to
>> unpatched servers, by definition.
> 
> I must be misunderstanding the attack. Why is the attack not possible
> even when client doesn't send the RI extension on initial handshake?

Because the server knows that the connection is a renegotiation from its
point of view, and therefore it rejects any handshake that doesn't
contain the extension.

> If the MiTM sends a client hello to the server that has no extension, then
> the server has no way to drop the connection. This will require a strict
> server to prevent the attack and strict server config will not be reality
> for a long time. What am I missing?

That, in the RI approach, strict server config is essential from the start.

We haven't yet established whether the ability to support lenient servers
is a requirement. Eric has argued against allowing that; so have I.
If lenient servers are allowed, then I think it will take *much* longer
until the vulnerability is eliminated from most connections.

Remember, rejecting a renegotiating ClientHello does not necessarily lead
to an interoperability failure; it only does so if the client will not
reconnect.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Nov 2009 13:19:42 -0600

> until the vulnerability is eliminated from most connections.

If lenient servers are not allowed, a server admin cannot patch his
server until all clients have patched. The world will have long given up
on renegotiation by then and just patched to disable it entirely.

If lenient servers are allowed, the servers can patch right away and
immediately begin protecting connections made with patched clients.

This group has to quit thinking it can dictate limits on functionality
in order to compel the consumers of the technology to do things your
way. The world isn't exactly leaping at the chance to upgrade to each
new TLS RFC you know. Trying to do that on a security fix is going to
leave a particularly bad taste in people's mouths.

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 19:20:00 +0000

> That, in the RI approach, strict server config is essential from the start.

Point of clarification: "strict server" here means that the server does
not accept *renegotiations* with an unpatched client. It still accepts
initial handshakes.

A "strict client", OTOH, will refuse to make even initial connections to
an unpatched server. So support for lenient (as well as strict) clients
is certainly necessary, but whether support for lenient servers is needed
is much less clear.

---

From: Nasko Oskov <[email-masked]>
Date: Thu, 19 Nov 2009 20:54:17 +0000

David-Sarah Hopwood wrote:
>> Because the server knows that the connection is a renegotiation from 
>> its point of view, and therefore it rejects any handshake that doesn't 
>> contain the extension.
>> 
>>> If the MiTM sends a client hello to the server that has no extension, 
>>> then the server has no way to drop the connection. This will require 
>>> a strict server to prevent the attack and strict server config will 
>>> not be reality for a long time. What am I missing?
>> 
>Point of clarification: "strict server" here means that the server does not
>accept *renegotiations* with an unpatched client. It still accepts initial
>handshakes.

Thanks for the clarification. We seem to differ in the definition of strict
server config. This clarifies it.

You are assuming then that admins will have to upgrade any clients that do
renegotiation before they upgrade their servers, otherwise there will be
interop problem. Am I correct?
This will mean that admins for sites that require client authentication will
not be upgrading their servers until their entire set of clients have
patched browsers. There is an option to rearchitect the site, but that 
might not be possible.

>A "strict client", OTOH, will refuse to make even initial connections to an
>unpatched server. So support for lenient (as well as strict) clients is
>certainly necessary, but whether support for lenient servers is needed is
>much less clear.

Great! We are in consensus on the client definition of lenient and the need
to support that.

>> We haven't yet established whether the ability to support lenient 
>> servers is a requirement. Eric has argued against allowing that; so have I.
>> If lenient servers are allowed, then I think it will take *much* 
>> longer until the vulnerability is eliminated from most connections.

There seems to be 3 different ways to define the server behavior:
* allow anyone
* don't allow renegotiation from unpatched clients
* don't allow initial negotiation from unpatched clients

We should be clear on which ones we call strict and lenient.

Nasko

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 19 Nov 2009 19:01:27 -0800

> until the vulnerability is eliminated from most connections.

I must have missed the message wherein "lenient server" was defined.
Is it a server that accepts client hellos without any signal that the
client has been upgraded, but merely refuses to renegotiate with such a
client?

IOW, is it the kind of server that numerous vendors are shipping now,
that recent patches to open source have just created, one that refuses to
renegotiate at all but still accepts old style client hellos?

Is someone proposing to abolish them already?

> to an interoperability failure; it only does so if the client will not

By definition, the alert that rejects a renegotiating client auth
(no_renegotiation) is a warning alert.  It leaves the previous TLS
connection and session state intact and able to continue.  So IINM, it does
not lead to an interoperability failure unless the client chooses to treat
that alert as fatal, despite being a warning, AND refuses to reconnect.
Right?

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 19 Nov 2009 19:37:06 -0800

> not accept *renegotiations* with an unpatched client. It still accepts 

If that is a "strict server", then what is a "lenient server"?
Is it a vulnerable server?

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 04:54:17 +0100 (MET)

> renegotiate at all but still accepts old style client hellos?

The type of (old) servers that are going to be with us for
quite some time are those that either never did renegotiate
where it was recently disabled.

Problem is, that they leave the clients in the dark if they don't update.
There is no assurance/confirmation at the protocol level that they
can't be abused.

> Is someone proposing to abolish them already?

I must have missed the widespread availability of patches for
secure renegotiation -- or are they taking down the entire internet
until further notice?   ;-)

> that alert as fatal, despite being a warning, AND refuses to reconnect.

In theory "no_renegotiation" alert is a warning alert.

In theory a server that wants to obtain a client certificate
and send a HelloRequest should treat a resulting 'no_renegotiation' alert
similar to a no_certificate alert (SSLv3) or empty Certificate message.

but it is probably not that simple.

If the server chokes when the client denies the HelloRequest
with a no_renegotiation alert and the app on top re-connects,
repeating the request, then this could result in a deadly
embrace.  I hope the app uses a retry-counter.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Nov 2009 20:24:46 -0800

Nelson B Bolyard wrote:
> 
> ... what is a "lenient server"?

Yes.

Some servers apparently cannot function without renegotiation.
They will need to continue providing service to unpatched
clients for some amount of time and thus remain vulnerable.

The solution we publish must make it impossible for a lenient-
but-patched client and a lenient-but-patched server to be
successfully attacked by a MitM using the renegotiation bug.

Mike

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 19 Nov 2009 20:49:33 -0800

> successfully attacked by a MitM using the renegotiation bug.

Based on your respective most recent messages in this thread,
I think you and Martin have different definitions of "lenient server".
Please establish a common set of definitions.

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 05:57:19 +0100 (MET)

> Please establish a common set of definitions.

I'm sorry -- my fault.

I was commenting your post (about the non-renego or renego-disabled
servers that are going to be with us for a while leaving clients
in the dark) but quoting the lenient stuff as well.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 20 Nov 2009 05:17:45 +0000

> Is it a vulnerable server?

A server that does accept initial handshakes with an unpatched client
(which obviously makes it vulnerable in that case). However, a lenient
server, unlike an unpatched server, will detect an attack on connections
with a patched client.

I believe this is not enough to consider the server to have been "fixed",
and I think it's a bad idea to end up with a subset of servers that
appear to be patched, but are still vulnerable on some connections.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 20 Nov 2009 05:40:50 +0000

> I must have missed the message wherein "lenient server" was defined.

See my other followup.

> renegotiate at all but still accepts old style client hellos?

No, those are strict servers.

> (no_renegotiation) is a warning alert.

Yes.

> It leaves the previous TLS

Right, although if renegotiation is being used to tell the client to use
a client cert, then a client that continues with the connection will
probably receive an authorization error in the application protocol,
which is an interoperability failure if the client would have had the
needed cert.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 20 Nov 2009 05:53:00 +0000

David-Sarah Hopwood wrote:
> (which obviously makes it vulnerable in that case).

Gack, sorry, typo.

A lenient server is a server that does accept *renegotiating* handshakes
with an unpatched client (which obviously makes it vulnerable in that case).

Both lenient and strict servers accept initial handshakes from any client.

I don't think there is ever a reason to reject initial handshakes where no
client certificate is used. There might be a reason to reject initial
handshakes where a client cert is used, in order to prevent the variant
of an attack where the client sees the renegotiation, and is unpatched.

> However, a lenient

That is, on any connection with a patched client.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 20 Nov 2009 07:49:29 +0100

I fully agree,

However, just because a server accepts renegotiation with an unpatched
client, does not necessarily mean that the service provided over TLS is
vulnerable.

One example is if authentication is performed with proper channel binding in
a layer above TLS and the service is provided under that security context.

I second that lenient server - unpatched client must work while ensuring
that lenient server - lenient client can't be abused using downgrade
attacks.

/Stefan

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 20 Nov 2009 18:41:27 +0000

> a layer above TLS and the service is provided under that security context.

I'm skeptical. How can "proper channel binding" be done correctly in a
layer above TLS, if the TLS library merges renegotiated sessions?
Since the session merging will result in the client and server's state
at the higher layer(s) being out of sync, nothing can be assumed about
the correct functioning of those layers.

> that lenient server - lenient client can't be abused using downgrade

Obviously *if* lenient servers are supported, then we need to make sure
that lenient patched server - lenient patched client connections are
secure. But I remain unconvinced that lenient servers need to be supported.

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 09:28:14 +0100

> the correct functioning of those layers.

The problem occurs on the clients initial handshake, being done in the
clear, while the MITM is feeding this into a renegotiation with the server.

As this attack has been described, once the client and server has concluded
an end-to-end handshake, the window for the attacker to do bad stuff is
closed. All renegotiations are safe from this point on.

The very act of channel binding, binds authentication of the client to
unique properties of the TLS channel. Thus,  successful channel binding
ensures that the client has concluded its first handshake (or it would not
have anything to bind to). It also ensures that the TLS channel is carried
end-to-end (or else channel binding would fail).

So according to the logic above, successful channel binding would prove that
the window for the attacker to do bad stuff is gone.

/Stefan

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 21 Nov 2009 19:00:52 +0000

> closed. All renegotiations are safe from this point on.

That's an oversimplification.

The attacker is able to add a prefix to the server's view of the session.
This changes the server's state from what it would have been on an
initial connection. How far the attacker's influence on the server's
state extends into that session, is dependent on the application protocol.

> end-to-end (or else channel binding would fail).

This is assuming away the problem. I said:

# How can "proper channel binding" be done correctly in a layer above
# TLS, if the TLS library merges renegotiated sessions?

The attack has already disrupted the functioning of the layer above TLS.
If any channel binding is done *at that layer* (or above), without
knowledge of the TLS renegotiation boundaries and taking specific account
of the vulnerability in TLS, then it can't be assumed to be reliable.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 21 Nov 2009 11:47:35 -0800

> the correct functioning of those layers.

The depends on those layers. If, for example, clients and servers simply
numbered their requests/responses, they would be immune to the attack.

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 21:46:58 +0100

> state extends into that session, is dependent on the application protocol.

So we are saying the same thing.

As you say, it depends on the application. What I claim is that it is
possible to design an application that use channel binding to keep itself
safe from this attack. All it needs to do is to make sure that it's state is
reset after completed channel binding.

The fact that it is possible to be safe despite this vulnerability is an
argument that lenient servers should be supported in the solution.

If I analyze my application and determine that it is safe from the attack,
then I could just allow gradual upgrades and stay lenient.

Or do you mean that it is impossible to design an application to be safe?

/Stefan

---

From: Bill Frantz <[email-masked]>
Date: Sat, 21 Nov 2009 14:04:33 -0800

>Or do you mean that it is impossible to design an application to be safe?

While it is possible to design an application protocol which is safe, it
isn't easy. For example, both the server and the client have to be using
the same <begin request> <end request> brackets. An attack on HTTP depends
on allowing the MITM to cause the server to process a different GET/POST
request from the one the client sent.

This bracketing issue affects even protocols like the Waterken
<http://waterken.sourceforge.net/> web-key protocol, where each request is
self-authorizing. If the MITM has a resource on the server addressable with
a web key, he can cause the client to pass parameter web-keys to that
resource rather than the resource the client thought it was addressing.

As a proof of concept that it is possible to design a safe protocol, if
each request is digitally signed by the sender, and verified by the
receiver, the MITM can not introduce superfluous data into the
conversation. If the brackets are different, the signatures don't verify.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 21 Nov 2009 22:09:14 +0000

> reset after completed channel binding.

That's not correct; it needs to know that the client's state is reset as
well (see below). But suppose for the sake of argument, that both the client
and server's state is reset when a renegotiation occurs. In that case,
channel binding is a red herring. Resetting the client and server states
prevents the attack regardless of channel binding. But then, why use
renegotiation (and unnecessarily risk interoperability problems) if you're
going to use it in a way that is completely equivalent to making a new
connection?

> argument that lenient servers should be supported in the solution.

Suppose that an unpatched client performs a renegotiation. The server
doesn't know whether this is an intended renegotiation or an attack; so,
it must reset its state, as though the client had made a new connection.
But with most application protocols, that won't work, because the client
hasn't reset its state.

It might work in some special cases, where the application protocol is
stateless between requests (like HTTP) and the renegotiation occurred
at a request boundary. But then, there is absolutely no advantage to
using renegotiation; it's unnecessary complexity.

One might argue: OK, renegotiation is unnecessary, but what if we want to
retain interoperability with clients that do it anyway (between stateless
requests, since that's the only case that would work)? However, in practice
clients don't renegotiate just for the fun of it; we need to consider how
renegotiation is actually used. I have not yet seen any plausible use case
for continuing to support renegotiation with unpatched clients, where it
wouldn't be simpler and more secure to do something else (given that you're
suggesting that we modify how the server uses the application protocol in
any case). For instance, when using renegotiation to prompt the client to
present a client cert, it's easier to have it make such requests on a
different port.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 21 Nov 2009 22:18:58 +0000

Ben Laurie wrote:
>>> One example is if authentication is performed with proper channel binding
>>> in a layer above TLS and the service is provided under that security
>>> context.
>>

That's not sufficient. They'd also have to make sure that renegotiation
boundaries coincide with request/response boundaries. That requires that
the app be notified by the TLS library precisely when a renegotiation
occurs, and that individual reads and writes cannot extend across a
renegotiation boundary. This contradicts the assumption that I stated
explicitly above: "if the TLS library merges renegotiated sessions".
It's also rather prone to application error even in cases where it would
theoretically work.

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 23:58:45 +0100

I don't think this discussion is critical to selecting a solution, but one
more go in-line;

On 09-11-21 11:09 PM, "David-Sarah Hopwood" <[email-masked]>
wrote:

> well (see below).

Frankly, I can't see why it isn't enough for the server to reset it's state
regardless of the client. The server will simply regard the first message
after channel-binding as the first legitimate message from the client.

> But suppose for the sake of argument, that both the client
> prevents the attack regardless of channel binding.

The difference is that channel binding offers a safe point in time when you
can do this reset.

> But then, why use

I agree, you have a point here. The point is more that you don't need to
take action to turn re-negotiation off if you are safe from the attack.

> it must reset its state,

No. If the renegotiation occurs after a successful channel binding, the
server can be assured that this is not an attack.

So the server will reset it's state after channel binding but not on
following renegotiations.

> as though the client had made a new connection.

You might be absolutely right here. However, I think the burden of proof
should be reversed. Lenient servers should be supported unless we know for
sure that there is no legitimate use case. It should be the choice of the
local administrator to be strict, not the choice of the protocol designer.

IMO, if one solution can support of lenient servers, and the other proposal
can't then the one that can has merit.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Sat, 21 Nov 2009 17:04:54 -0600

Ben Laurie wrote:
> 
> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

MitM may be able to prep the client to match the sequence number of the
server at the point of splicing.

- Marsh

---

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

Stefan Santesson wrote:
> 
> What I claim is that it is possible to design an application that
> use channel binding to keep itself safe from this attack.
> All it needs to do is to make sure that it's state is reset
> after completed channel binding.
> 

If it just was that easy.

In addition to the TLS renegotiation vulnerability there may
be unexpected consequences of the architecture of the API
that is used between the TLS implementation and the application.

The particular problem with HTTP is, that it does not authenticate
the request as first thing in the protocol when Cookie-based
or basic authentication is used, which makes that particular
attack successful.

When TLS client-certs are used it may actually become _a_lot_worse_
because the TLS authentication is not tied to a specific
request, but instead is supposed to authenticate the entire channel
and all data that travels it.  Here is where HTTP 1.1
Connection: Keep-alive significantly expands an attackers options.

If no client-certs are used and the authentication is performed
inside the application data as the first thing in the request,
then this app might not be vulnerable.

I can't comment on the "application that use channel binding" though,
because I don't understand that concept yet.  If the app uses
some crypto stuff outside of regular TLS to digitally sign or
protect each request with a keyed hash based on cryptographic
properties of the TLS channel (like the finished messages),
then this could work.

But the problem that I see there is the layering.  TLS is supposed
to go directly on top of TCP.  If the application several layers
above TLS uses properties such as a finished message for
a keyed hash on individual requests, then I don't see how this
could work well in a distributed environment, where the
original TLS channel might be terminated at the perimeter of
the distributed backend system (server farm), while the
backend application runs on some backend machine far away from the
endpoint of the TLS channel.

A layering violation of that kind puts significant constraints
on the (absence of compexity of) the infrastructure where it
might be used.

-Martin

---

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

> after channel-binding as the first legitimate message from the client.

The data sent on the channel is only split into "messages" at the
application protocol layer (if at all). At the upper interface of the
TLS layer, it is just a duplex byte stream, so the client may have sent a
partial application message. The server will then receive the rest of that
message after having reset its state, so it will be out of sync with the
client. This situation would break the application protocol regardless of
any attack.

> take action to turn re-negotiation off if you are safe from the attack.

But you do have to take action to ensure that the server resets its state,
and/or perform channel binding. Given that you have to take action, it's
not at all clear that these particular actions are simpler than the
alternatives; in they are definitely more complex than some alternatives.

> server can be assured that this is not an attack.

Your suggestion was that channel binding could be done above the TLS layer.
As far as I can see, any channel binding that occurs above the TLS layer
cannot work to prevent the attack unless it is aware of the TLS
renegotiation boundaries. If you think that it can, please give more detail
of the protocol you're proposing; "successful channel binding" is not a
specific enough description.

[...]
> can't then the one that can has merit.

Well, I've previously proposed a solution that supported lenient servers
(changing the Finished hashes unconditionally on a renegotiation, but using
extensions for signalling). That doesn't change my mind that a lenient
server policy is a bad idea.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 22 Nov 2009 11:07:46 -0800

> It's also rather prone to application error even in cases where it would

I don't believe your argument. For example, if each byte were numbered, then
the application would not care one whit about boundaries (other than
reconnections, which it manages anyway).

---

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

Ben Laurie wrote:
>>>>> One example is if authentication is performed with proper channel
>>>>> binding in a layer above TLS and the service is provided under that
>>>>> security context.
>>>>

Numbering each byte is not what you suggested above. You haven't given
enough detail to tell whether this could work, but if for the sake of
argument it could, it would require incompatible changes to the application
protocol. Therefore, it's not an argument that justifies the original
point by Stefan Santesson above, about servers that accept renegotiations
with unpatched clients not necessarily being vulnerable. In practice, such
servers will be vulnerable for existing protocols.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 22 Nov 2009 14:23:01 -0800

> servers will be vulnerable for existing protocols.

I agree. I was disputing that this was not fixable at the application layer.

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 12:19:03 +0100

Martin Rex wrote:

> for identity protection to perform an initial client-anonymous TLS
> handshake directly followed by a renegotiation with client-cert
> authentication?
> 

Yes... and as Eric noted, as long as the 2nd handshake "directly
follows" (=no application data is exchanged using the first session),
this seems to be secure already....

Best regards,
Pasi
(not wearing any hats)

---

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

> this seems to be secure already....

But you do realize that there is an attack scenario where the server
sees only an initial authentication, and the client sees a renegotiation?

The MitM could use it to perform some kind of "bouncing-attack",
where it feeds the client with a crafted request (like a form)
and then links the client with the real server.

So it is necessary for both sides to check, a check on the server
alone is not sufficient.  And if we're changing code, we could
just as well deploy the fix for the weakness (provided TLS WG
can agree on one solution).

-Martin

---

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

> sees only an initial authentication, and the client sees a

Hmm... you're right, this could happen. But only if the client is OK
with the server changing its certificate during renegotiation, and
both certificates are accepted by the client.

Having TLS endpoints change their certificates during renegotiation is
highly likely to confuse many applications (and lead to security
problems) even when the renegotiation is secure (i.e. there's no MitM,
just the two endpoints). Draft-ietf-tls-renegotiation-00 requires that
even clients/servers that do implement secure renegotiation MUST NOT
by default allow certificate changes during renegotiation (unless the
application especially asks for it, and is prepared to handle such
changes).

Best regards,
Pasi
(not wearing any hats)

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 25 Nov 2009 14:45:48 +0100

> highly likely to confuse many applications (and lead to security

Just an observation: A while back I encountered a big Asian bank whose  
loadbalanced servers were using two different Extended Validation  
certificates, and was switching between those certificates every other  
negotiation. The reason I was investigating the site was that the EV  
indication was flip-flopping on this site, which turned out to be because  
one certificate had a 1024 bit key (which qualifies for EV), the other was  
using a 1023 bit key (which does not qualify for EV). For reference,  
session resume did not work in this case.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 26 Nov 2009 14:08:41 +1300

"Yngve Nysaeter Pettersen" <[email-masked]> writes:

>The reason I was investigating the site was that the EV indication was flip-
>flopping on this site, which turned out to be because one certificate had a
>1024 bit key (which qualifies for EV), the other was using a 1023 bit key
>(which does not qualify for EV).

So the CA issued a certificate that it should never have issued?  And then the
client did more checking than the CA did?  Do other implementations perform
this level of checking of EV conditions as well, or do they just assume that
if the EV flag is set then everything must be OK because the CA says it is?
I'd be interested in feedback from on this one (private is OK if you don't feel
like making it public).

Kinda scary if it's left to the RP to do the CA's work...

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 26 Nov 2009 00:24:25 -0800

The most simple fix for a 1023-bit key is to force the high bit to
always be 1.  (This was implemented in PGP 5 for RSA keys.)

Who was the EV issuer?

-Kyle H