Subject: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

From: Yair Elharrar <[email-masked]>
Date: Mon, 9 Nov 2009 14:17:24 +0200

The proposed draft is intended to resolve an MITM attack scenario, but is the new extension tamper-resistant?

Since the MITM handles all traffic between the real client and real server, it could add a fake extension to the 2nd ClientHello with its original verify_data, and empty the returned extension in the ServerHello.

In addition, until such time that all clients in the world start supporting this extension (e.g. kiosks in airports), servers will have to support backward compatibility. The MITM can downgrade every client by simply removing the extension from the ClientHello.

        Yair

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: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2009 14:36:47 +0200

Below

On Nov 9, 2009, at 2:17 PM, Yair Elharrar wrote:

> The proposed draft is intended to resolve an MITM attack scenario,  
> but is the new extension tamper-resistant?

It's as resistant as TLS is.

> Since the MITM handles all traffic between the real client and real  
> server, it could add a fake extension to the 2nd ClientHello with  
> its original verify_data, and empty the returned extension in the  
> ServerHello.

The Finished messaged at the end of the TLS handshake signs all the  
previous data. Unless the MITM can replicate the server's calculation  
of the opaque_verify_data field, the client will notice that the  
finished message is wrong (it signs an extension that the client did  
not send).

To calculate the opaque_verify_data field, the MITM would need the  
(pre_)master_secret, and that is encrypted using the server's public  
key. So no, the MITM cannot mess with the extensions.

>
> In addition, until such time that all clients in the world start  
> supporting this extension (e.g. kiosks in airports), servers will  
> have to support backward compatibility. The MITM can downgrade every  
> client by simply removing the extension from the ClientHello.

They can't downgrade the client, but the client can't expect any  
server to support the extension. Maybe the browser vendors can disable  
the green EV indication for servers that don't support the extension.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 07:45:35 -0600

Yair Elharrar wrote:
> server, it could add a fake extension to the 2nd ClientHello with its
> original verify_data, and empty the returned extension in the
> ServerHello.

A valid concern, which I believe is addressed by the fact that the
'Finished' message in TLS contains a MAC which covers extensions present
on the Client and Server Hellos.

IIRC, earlier SSLs did not cover extensions with a MAC.

> have to support backward compatibility.

It will be a trade-off for each server admin to weigh and decide their
policy. I suspect many admins will prefer not to allow insecure
connections from unpatched airport kiosks.

> The MITM can downgrade every

I think that is not the case with modern versions of TLS.

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

Eeek!

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

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2009 15:53:21 +0200

> IIRC, earlier SSLs did not cover extensions with a MAC.

I think SSLv3 did not allow for client extensions at all, and TLSv1.0  
already covered everything.

> connections from unpatched airport kiosks.

I suspect you have a way too optimistic view of administrators.  
Currently exactly 0% of browsers are patched. It will be years before  
even 50% or browsers are patched.

Yoav

---

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

> already covered everything.

I think that SSLv3 did allow additional arbitrary data to be added after a
ClientHello without specifying the format (meaning that technically extensions
could be included) and that this additional data was included in MACs.

However testing has shown that many implementations (including one ancient
version of OpenSSL) didn't handle this properly meaning that including
extensions in SSLv3 can result in handshake failure.

OpenSSL did include extensions in SSLv3 but the resulting failures have meant we
don't do this any more.

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

---

From: Yair Elharrar <[email-masked]>
Date: Mon, 9 Nov 2009 16:44:11 +0200

>> 3. The MITM stops passing data to the client, and sends a ClientHello to the server.

This ClientHello should be encrypted with the initial session's keys.

--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2009 17:01:41 +0200

Oh. OK. Thanks.

---

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

> >> but is the new extension tamper-resistant?

It is tamper resistent in the same fashion as the rest of SSL/TLS.
No more, but also no less!

> > IIRC, earlier SSLs did not cover extensions with a MAC.

Those that have this problem are not interoperable with a
TLS+extensions handshake (which might be why some browsers added
a handshake retry mechanism for a naked SSLv3 ClientHello.

> already covered everything.

The problem with SSLv3 is, that the spec was finalized after the
implementations had been shipped.  :-|

If I refer to SSLv3, I always base my assuption on the
SSLv3 internet draft document from Nov 18, 1996 document, which was
the starting point for TLS v1.0.  It contains the following note
at the top of page 24 (5.6.1.2. ClientHello):

   Forward compatibility note:
                  In the interests of forward compatibility, it is
                  permitted for a client hello message to include
                  extra data after the compression methods.  This data
                  must be included in the handshake hashes, but must
                  otherwise be ignored.

Which means in principle that SSLv3 allows extensions to be used,
and the extra data will be integrity protected by the finished messages
of the handshake.

If you look at the TLSv1.0 spec (rfc2246) and TLSv1.1 spec (rfc4346),
neither contains extension data in the ServerHello in the base spec.

Is there a reason why TLS extensions should _NOT_ be applicable
to SSLv3 in just the same way they're applicable to TLSv1.0 and TLSv1.1 ?

There may be SSLv3 servers out there that choke on extension data
in the ClientHello.  But that doesn't mean that one could not
upgrade SSLv3 servers to support TLS extensions.  The more interesting
question is IMHO -- which TLS clients will choke when an SSLv3 server
returns a ServerHello extension?  spec-wise, a ServerHello extension
is as unusual to SSLv3 as it is to TLSv1.0.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Nov 2009 18:20:11 +0100 (MET)

Hmmm, I think I can answer this myself:

> is as unusual to SSLv3 as it is to TLSv1.0.

Since such an SSLv3 server will only be returning extensions in
an extended ServerHello that the TLS client asserted, and in our
specific situation here, the new extension for secure renegotiation
that we're just defining, then the answer is:  Test the update
before shipping it, and all TLS clients with the secure renegotiation
update ought to interoperate smoothly with SSLv3 servers that implement
this TLS extension.

Adding support for other/existing TLS extensions might eventually
confuse or upset installed base TLS clients, so I wouldn't try those
this time. :) 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 12:21:21 -0600

> finished message is wrong (it signs an extension that the client did  

Indeed, the Finished message is the key.

Note that there's no real need for the channel binding to actually be
sent, as in EKR's proposed fix: there's only a need to include it as an
extra input to the PRF call used to construct the Finished messages.
However, by sending the channel binding data as a Hello extension, this
proposal does the least amount of violence to existing implementations.

Nico
--

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 09 Nov 2009 19:34:55 +0000

> connections from unpatched airport kiosks.

To prevent this attack, they don't have to disallow connections, only
renegotiations in which the extension is not used.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 09 Nov 2009 19:37:46 +0000

> is as unusual to SSLv3 as it is to TLSv1.0.

Why would that situation arise? For that to happen, an SSL server
library would have to be upgraded to support extensions but not to
support TLS. Are there any SSL-only libraries being actively
maintained?

---

From: Yair Elharrar <[email-masked]>
Date: Mon, 9 Nov 2009 21:47:42 +0200

> renegotiations in which the extension is not used.

That's a very good point. Perhaps the draft could be changed to reflect that?
I can't see any reason why an airport kiosk would need to renegotiate an HTTPS connection (these devices rarely have client certificates installed); however it should be allowed to connect to secure web sites.

           Yair

--

---

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

> support TLS. Are there any SSL-only libraries being actively

Yes, there are.

But the issues do also affect TLS-capable servers and clients that
talk to peers which are limited to SSLv3 only (through either
configuration or implementation constraints).

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 09 Nov 2009 21:22:29 +0100

> support TLS. Are there any SSL-only libraries being actively

This is unlikely to work, because at least some clients (Opera being one)  
will never send Extensions to SSL v3 server. In fact, Opera will not  
attempt Extensions to a server until it knows it is dealing with a TLS  
1.0+ server, because we know there are TLS 1.0 servers that does not  
accept Extensions (see  
http://tools.ietf.org/html/draft-ietf-tls-interoperability-00 ).

-- 
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: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 14:26:17 -0600

Yair Elharrar wrote:
>> To prevent this attack, they don't have to disallow connections,
>> only renegotiations in which the extension is not used.
>> 
> 
> That's a very good point. Perhaps the draft could be changed to
> reflect that? I can't see any reason why an airport kiosk would need
> to renegotiate an HTTPS connection (these devices rarely have client
> certificates installed); however it should be allowed to connect to
> secure web sites.

Here are some reasons to strongly encourage it:

A variation of the attack involves the client seeing the renegotiation
with MITM and the server sees just a single session. I believe but have
not proven that this bug is not uncommon among typical clients. If TLS
allows connections with anonymous servers (and possibly authenticated
clients), then it violates the same identity guarantee implied by the spec.

At some point in the future it will be a good indication that the client
software is poorly-maintained. Some admins will prefer not to exchange
confidential data with such systems.

Absence of the extension will also raise flags on network monitoring
equipment. Consistent usage will make detection more reliable.

Here are some reasons not to encourage it so strongly:

The attack in which the renegotiation is only seen on the client side
usually requires a logic error on the client's part, so it might not be
a concern of the TLS spec.

Somewhere, someone is doing something over TLS that is not vulnerable
because neither side ever will ever allow renegotiation. Unfortuantely,
this can only be determined by direct inspection of the code at both ends.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2009 23:05:59 +0200

> renegotiations in which the extension is not used.

Even that can be further refined. You can freely renegotiate an authenticated session, as long as the renegotiation does not involve an identity change.

Obviously, if the first handshake include client authentication, any renegotiation that includes the same client cert is fine.

If the session is authenticated by the application (as in an HTTPS login page) it's also possible to renegotiate with impunity, but the interaction here between the application and the TLS layer may be too sensitive an bug prone to specify in the draft. For example, if an SSTP server renegotiates after the client has authenticated (through PPP), I don't think there's a security risk in not implementing the extension.

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Nov 2009 22:52:31 +0100 (MET)

Yoav Nir wrote:
> Even that can be further refined. You can freely renegotiate an
> authenticated session, as long as the renegotiation does not involve
> an identity change.
> 
> Obviously, if the first handshake include client authentication,
> any renegotiation that includes the same client cert is fine.

I whish there was a constraint that an identity/certificate that has
been established for a party during the TLS handshake MUST not change
during re-negotiation, but _none_ of the current SSL&TLS specs has
such a constraint, so the issue of identity change is currently
dumped as a responsibility onto the application.

I am certainly in favour of locking this down for the renegotiation.
I believe it is irresponsible to leave this un(der)specified as it is.

We can be lucky if the application performs an authentication at all.
since there currently is absolutely no signalling defined that would
tell an application reliably at which point of the stream a
renegotiation was completed, the app doesn't know (a) when to
perform an additional authentication and (b) where the data
from the previous session ends and where the next starts.

As previously described in another message, the current spec has a
requirement that additonal application data may be arbitrarily
interleaved with a renegotiation handshake.  I think this requirement
makes a security assessment of the protocol impossible for changing
identities.

There are software architectures where the server certificate is checked
in a callback style when processing the ServerCertificate handshake
message (both: PKI-verification and server endpoint identification),
Application data protected under the old encryption could be exchanged
after the processing of the ServerCertificate and before the
ChangeCipherSpec (i.e. protected under the old session), and
also between ChangeCipherSpec and Finished messages (protected
under the new session, but before the finished messages have verified).

The semantics for the initial TLS handshake on a connection are
*MUCH* cleaner (both full TLS handshake and session resume):
no application data may be exchanged before the finished messages
have been verified.

Personally, I would it find much cleaner if the semantics for the
renegotiation would require the TLS peers to suspend transmission
of application data while performing TLS renegotiation,
i.e.

   the client must not send any application data between
   ClientHello and the client's Finished message

   the server must not send any application data between
   ServerHello and either no_renegotiation alert or
   the server's Finished message 

   the client must drop all application data received
   between ServerHello and either no_renegotiation alert
   or the server's Finished message

   the server must drop all application data received
   between the ClientHello and the client's Finished message

Since the original streams in both directions could have been used
in completely asynchronous fashion, both peers may have to get back
in sync for the renegotiation, recognizing that they're in sync by
receiving the first handshake message (ClientHello/ServerHello).

Are there currently applications that actively abuse the possibility
provided by the spec to interleave application data and handshake
messages of a TLS renegotiation handshake (provided that the
TLS implementation that (a) they're using and (b) they're talking
to actually allow this.  The fact that the spec says so, doesn't
mean that everyone has implemented it in this fashion (since it
is complex,difficult and possibly insecure)?

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 16:09:41 -0600

> authenticated session, as long as the renegotiation does not involve

Maybe. What about cases where the sessions are "authenticated" from the
perspective of TLS, but the higher-layer protocols stack on additional
notions of identity?

I seem to recall systems (MS Terminal Services Gateway perhaps?) where a
common client cert is used simply to grant basic access, then some form
of HTTP authentication is used to authenticate which user it is.

TLS does not necessarily know the full extent of "identity" attributed
by higher layers, so you would be allowing any party that can pass the
TLS level auth to MITM the others.

For example, a browser may have several connections to the same set of
servers behind https://ecommerce.example.com/, but you still wouldn't
want to allow a bad guy on one to splice channels between them.

> Obviously, if the first handshake include client authentication, any
> renegotiation that includes the same client cert is fine.

I disagree, I think it subtly violates the assumption of continuity over
the TCP connection.

> If the session is authenticated by the application (as in an HTTPS
> login page) it's also possible to renegotiate with impunity,

Renegotiation (in the absence of draft-rescorla-tls-renegotiate) offers
a point which allows anyone who can pose as one of the parties (perhaps
an anon) to splice in a connection from a third party to the one he is
posing.

This is bad, the HTTPS client-cert renego case.
   A---+---B
   C---+
A-Anonymous Alice
B-Bob
C-Client cert authenticated

These are also bad:

   A---+---B  C---+---B      +---A2 (requires buggy client)
   A---+      C---+      A---+---B

This violates core assumptions even if the same name or "anonymous"
appears at each end of the multiple sessions at play.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 16:34:18 -0600

> I believe it is irresponsible to leave this un(der)specified as it is.

+1

This is the right time to add such a constraint.

I wouldn't be surprised if there are clients (for IMAP? LDAP?) that take
advantage of this to allow the user to switch "hats" without
reconnecting though.

> makes a security assessment of the protocol impossible for changing

Or at least really difficult.

> of application data while performing TLS renegotiation,

+1

This is the right time to add such a constraint.

Unlike a "authenticated identities can't change" constraint, this could
be implemented without conceivable app protocols being broken, I think,
but it may require API changes for some implementations, and that it may
put this change out of reach.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 22:08:53 -0600

Nicolas Williams wrote:
>> during re-negotiation,

Hmm, few questions about that plan:

Is this currently a defined concept in TLS: equivalence of identity?

Isn't that one of the major uses of renegotiation? To change identity?
That seems to be the entire point of the observed cases of renegotiation
in https. Even if the only case we know of is a transition from an
anonymous identity to a client-certified one, such a new constraint
seems a bit pointless and likely to break someone.

Perhaps you want to allow identities to be "strengthened" but not
"weakened". Is this another new concept in TLS: are identities required
to be partially- or fully-ordered?

It's starting to sound like that question about ciphersuites being
ordered according to strength.

Would that make it illegal to resume a previous session over the same
underlying connection if it could not be proven it was "the same" identity?

What if the session's identity were strengthened? Could you end up in a
situation where a session could be resumed on any of several other
connections except the one on which it originated!

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 04:15:39 +0000

Yoav Nir wrote:
> authenticated session, as long as the renegotiation does not involve an
> identity change.

I don't agree. In order for the security properties that are supposed
to be provided by TLS to be preserved, the client in the renegotiated
session must be able to prove cryptographically that it knows some secret
that was associated with the previous session, *and* that it intends this
session to be a continuation of that one. The only practical way to do
that is with the extension.

In particular, "any renegotiation that includes the same client cert" is
not fine. If the private key to a given client cert is compromised, that
should only allow an attacker who knows it to authenticate with that cert;
it should not allow them to attack the sessions of the original cert
holder.

---

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

> makes a security assessment of the protocol impossible for changing

If your TLS API was able to tell you exactly where in the application
data stream a renegotiation has completed successfully, you would
be able to apply the original security parameters to the data received
prior to the renegotiation, and then switch to the new parameters for
the data received after the renegotiation.

That would catch the MITM attack being discussed now.

>    between the ClientHello and the client's Finished message

When I first implemented TLS, the only reason I could envision for
renegotiation was to refresh the symmetric keys, so I made it work
asynchronously.  I wrote about it in this message:

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

With this design, application data can flow at nearly full speed while
a renegotiation is taking place.  Requiring all data to stop flowing
during a renegotiation, may be unnecessary in some situations.  I do
see however, that data probably needs to stop flowing after sending
a Finished message until receiving the peer's Finished message, but
that affects only one direction and last for one round trip, not two.

When you add changing client credentials to the mix, then data flow
probably has to stop, but that is really an application-level decision.
Also silently dropping data never seems like the right thing to do IMHO.

> is complex,difficult and possibly insecure)?

Yes, see the above referenced message.  But I don't agree that it's
abuse since that is what the spec. says to do.

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 10:46:09 -0600

> Is this currently a defined concept in TLS: equivalence of identity?

TLS connections are not so long lived that we should worry about issues
such as, for example, public key rollover or certificate expiration
during a connection's lifetime.  Therefore a simple Certificate octet-
for-octet comparison will do for identity comparison.  Anything more
complicated than that (and anon->non-anon) would make Martin's proposal
too unqieldy to consider at this point, and possibly ever.

> Isn't that one of the major uses of renegotiation? To change identity?

But only from anonymous to non-anonymous, right?  That's also easy to
specify.

> ordered according to strength.

No, I don't think so.  Ordering cipher suites by strength is a complex
topic that I'd rather avoid for the specific enhancement that Martin
proposes.

> underlying connection if it could not be proven it was "the same" identity?

There's no authentication during session resumption handshakes --
there's only proving that both peers remember the relevant state,
including master secret.

> connections except the one on which it originated!

I'm not sure I follow.  See above.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 10 Nov 2009 12:02:06 -0600

Nicolas Williams wrote:
> TLS connections are not so long lived

But there is no defined upper limit.

> that we should worry about issues
> during a connection's lifetime.

I agree, but we should probably check that it's documented somewhere.

> Therefore a simple Certificate octet-

So this restriction would not apply when another auth type is used?

> But only from anonymous to non-anonymous, right?  That's also easy to

One subtlety is that apps (https servers) are still expecting the
transition to preserve some guarantees about identity. Even though the
first session is "anonymous" it still has an identity, namely it has to
be the same party as all previous non-anonymous sessions on the same
connection.

The proposed Renegotiation Indication extension attempts to enforce
those guarantees, but I'm not sure it's so easy to specify that it
shouldn't be given a lot of thought. (Consider what happens when you add
various combinations of resumption into the mix.)

> Ordering cipher suites by strength is a complex

Perhaps ordering levels of authentication is equally complex.

> there's only proving that both peers remember the relevant state,

Isn't proving "I'm the same as that other guy" a form of authentication?

Surely this will be allowed:

  |--- session A anon ---||-- resumed A --|

Is this allowed?

  |--- session A anon ---|
  |--- session B anon ---||-- resumed A --|

I have heard that browsers may do this.

> I'm not sure I follow.  See above.

1  |--- session A anon ---||-- session B client cert auth --|
2  |--- session C anon -----|
3  |--- session D anon -----------|
4  |--- session E anon -----|

Would an effect of the proposal be that session A can be resumed on
connections (2, 3, 4) but not 1?

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 12:15:45 -0600

> But there is no defined upper limit.

True, and indeed, IMAP depends on that.  Are there IMAP/other servers
the request re-negotiation when a client's cert reaches/nears
expiration?

If so then my assertion that we don't have to worry about key rollover/
cert expiration would be wrong.  Indeed, it's safer to assume that that
assertion was wrong as finding out for sure would be hard.

However, this is a constraint that _applications_ could enforce, or
request be enforced by the TLS implementation (oh dear, back to APIs).

> I agree, but we should probably check that it's documented somewhere.

It probably isn't.

> So this restriction would not apply when another auth type is used?

I suppose non-anon->anon re-negotiation, but with the new inner->outer
connection binding should be OK once too (to allow for re-keying without
having to bother with authentication).

Yes, I see your point: this is now getting too complex.

Applications can always enforce that identities don't change around
re-negotiation, by asking the TLS implementation what the IDs were
before and after re-negotiation, and by sticking to simple rules (e.g.,
cert octet-wise comparison) even if those defeat key/cert rollover.  But
if we're going to let apps do ths (and I think now only apps should)
then there's no place in EKR's I-D for text about it, except, maybe, in
the Security Considerations section (since TLS defines no APIs).

> various combinations of resumption into the mix.)

Certainly channel binding is _always_ easier than identity equivalence.

That's the main reason I have been pushing channel binding.  There are a
number of protocols where the only way to ensure there's no MITM is to
ensure that one sees the same server identity on the server end of two
channels -- that's asking for trouble.

> Perhaps ordering levels of authentication is equally complex.

If you're willing to make certain simplifying assumptions (e.g., no need
for key/cert rollover), then authenticated ID equivalence can be simple.
If you're not willing to make those assumptions then yes, it becomes as
complex as cipher suite strength ordering.

> Isn't proving "I'm the same as that other guy" a form of authentication?

I.e., channel binding.  It doesn't authenticate identities, but it does
"authenticate" that two end-points are logically the same entity.

>   |--- session A anon ---||-- resumed A --|

I.e., negotiate an anonymous session, then re-negotiate where the
re-negotiation is just a resumption of the anon session?  Ick.

> I have heard that browsers may do this.

I think session resumption in a re-negotiation should probably be out,
yes.

Nico
--

---

From: Steve Dispensa <[email-masked]>
Date: Tue, 10 Nov 2009 13:21:46 -0600

> the request re-negotiation when a client's cert reaches/nears

Has anyone considered SSL VPN's and/or things like GoToMyPC?

> assertion was wrong as finding out for sure would be hard.

OTOH, we could require that app-level protocols support re-establishment of
the underlying TLS session once crypto state gets stale (in the opinion of
either client or server).

 -Steve

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Nov 2009 21:12:05 +0100 (MET)

> the request re-negotiation when a client's cert reaches/nears

There is only a suggestion in the TLS spec that a TLS session ID should
not be valid for more than 24 hours.  That refers to the TLS session
cache and the possibility to resume a TLS session, not for the
lifetime of an established TLS session.

Busy Web-Servers may use significantly shorter session cache lifetimes
(our default is 15 minutes).

TLS connection lifetimes and session lifetimes, in particular for SSL-VPNs
that Steve mentioned, might be much longer.

But keep in mind, that issuer of credentials (like CAs) may have
a problem if an authenticated session can be held for several days
even though the credential may have long be expired, revoked or
the ACL may have been updated in the interim.

An application that depends on an authentication to be valid for
several days or weeks is probably a security problem all by itself.

How about recommending two recommendations instead of one:

 - TLS implementations should, by default, lock down identities during
   session renegotiation once they have been established in a TLS
   handshake, i.e. the implementation should ensure they match exactly
   (e.g. memcmp() of the certificate blob).  Identities not previously
   established in a TLS handshake can be established in a renegotiation
   for the first time.

 - TLS implementations are encouraged to offer an API to the applications
   where an application can request permission for a change in
   identities during renegotiation.  Application protocols that need
   this functionality, MUST specify the procedure how to perform
   authentication of the peer and the semantics of a change in
   identity during renegotiation.  TLS implementations must
   provide a signaling facility to such applications to distinguish
   application data received over the original TLS session from
   application data received over the newly renegotiated TLS session.

> having to bother with authentication).

I do not like that idea.

If renegotiation is performed and the identity is maintained, this
can be detected with a memcmp() on the certificate blob, and then
one can skip that authentication.

If the identity changes, a re-authentication ought to be performed.

Usually the issuer of a certificate assumes that it can no longer
be used once it is expired, but if you allow renegotiations to

Renegotiation creates a new session, that servers will usually add to
their session caches.  If such a session is resumed from the cache
on a new connection, you can _not_ perform an authentication.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 10 Nov 2009 20:16:27 +0000

> I have heard that browsers may do this.

Ouch -- I thought that I understood the attack, and now you've just given
me another headache ;-)

Do servers support a renegotiation that resumes a different session?
That seems like a really bad idea.

Since a resumption may always be refused, clients can't be relying on
this behaviour. So we could compatibly specify that servers MUST NOT
accept such a resumption.

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Nov 2009 21:34:45 +0100 (MET)

> Is this currently a defined concept in TLS: equivalence of identity?

blob_compare(current-cert-blob,new-cert-blob)

Everything more complicated should be an apps issue--provided that
the apps has provided "convincing arguments" to the TLS implementation
(i.e. correctly instrumented the relevant APIs)
that it is competent to perform such a re-authentication as a result
of an identity change during renegotiation.

> Isn't that one of the major uses of renegotiation? To change identity?

I simply don't know.  Our server doesn't support renegotiation.
And I learned our client to do it several years ago since it was
used in certain configurations of MS IIS to ask for a client
certificate after having seen the request.

> seems a bit pointless and likely to break someone.

This might not accurately describe the situation you have in mind.

A client that has not sent a certificate (usually because the server
didn't send a CertificateRequest) is definitely not an "established
anonymous identity".  It is simply the absence of an identity.

The use of a DH_anon ciphersuite, on the other hand, might be considered
to establish an anonymous identity for the server.  I do not like the
DH_anon ciphersuites and I'm wondering what TLS implementations do
that provide applications a callback for verification of the server
cert which is usually called while processing the ServerCertificate
handshake message when the server selects a DH_anon ciphersuite
(in which case there is no ServerCertificate handshake message).

-Martin

---

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

> the data received after the renegotiation.

What about the application data sent between the ChangeCipherSpec
and the Finished messages?  It certainly must be encrypted by
the crypto parameters of the new session.  But it can not be
considered authentic before the finished messages have been
verified.  And when the finished messages verify, then I consider
it inappropriate to associate that data with the _previously_
authenticated session&identity.

Since the current SSL&TLS specs are completely ambiguous, you can
not claim "if your TLS API was able to tell you exactly where in
the application data stream", because currently no such semantics
exist!  Two independent implementations of TLS that claim to
tell you exactly where the position is may identify entirely
different positions -- and with the current spec, it is impossible
to decide where the position should be.

> That would catch the MITM attack being discussed now.

We're going to plug that MITM attack with secure renegotiation.

But that will not affect the miserable ambiguity for where the
original session ends and the new session starts if we do allow
established identities to change during renegotiation.

To fix that, we will have to spell out the precise semantics
in a specification.  IMHO, the cleanest would be to disallow
application data transfer during a renegotiation handshake.

> during a renegotiation, may be unnecessary in some situations.

If you lock down established identites, then I do not see a problem with this.

For a delayed TLS client-cert authentication, this implies the semantics
that the newly established identity assumes responsibility for everything
that has been sent over the previous session.  (The assumption that
is currently a problem for servers doing renegotiation without a
cryptographic binding between previous and renegotiated session.

> I do see however, that data probably needs to stop flowing after sending

Why Finished?  I think its everything following the ChangeCipherSpec.

> Also silently dropping data never seems like the right thing to do IMHO.

_I_ did not write _silent_ dropping.  Dropping and aborting is fine.
Dropping in the sense of "MUST NOT make it available to the application".

I said "drop" after having previously specified that the other
side MUST NOT send during the handshake.  That MUST NOT send app data
directly translates to a requirement for the receiver to drop that
data.  Sending an alert when that happens and closing the connection
is fine with me.

> abuse since that is what the spec. says to do.

I certainly didn't not want to blame you for implementing exactly
what the TLS spec says in your TLS implementation.

I'm sorry if I wrote it that way.

I'm wondering whether there are application that actively abuse
this feature and would break if the TLS implementation would exhibit
semantics similar to those I outlined above and fail with an error
if the TLS implementation would reject application data while
performing the renegotiation handshake.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Nov 2009 06:09:08 +0900

> request be enforced by the TLS implementation (oh dear, back to APIs).

IMHO this is the responsibility of the application. For example in XMPP
we use long-lived TCP connections and, on top of those, long-lived XML
streams that can be TLS-protected. In practice, for server-to-server
federation (and even for client-to-server communication) those
connections might be up for days, weeks, even months. At this point the
handling of long-lived XML streams is unspecified, but I would expect
most XMPP servers to terminate the connection and force the other party
to reconnect. I'll bring this up on the XMPP WG list...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Marsh Ray <[email-masked]>
Date: Tue, 10 Nov 2009 15:42:24 -0600

> If you lock down established identites, then I do not see a problem with this.

Really, it's the upper layers that define how 'identity' is to be
interpreted. TLS may know that the certs on one end or the other is the
same, but that is not the same as saying that the actual app-layer
identities are interchangeable.

> Why Finished?  I think its everything following the ChangeCipherSpec.

For all the reasons that the Finished message was added to the protocol?

Hmmm, is app data allowed prior to the first finished message? No way,
couldn't happen.

> Sending an alert when that happens and closing the connection
> is fine with me.

Certainly preferable to passing something unexpected.

> performing the renegotiation handshake.

I believe that there are TLS library implementations that conduct
renegotiation transparently to the application code unless the app
specifically requests it.

Really there are a few missing letters in the plaintext alphabet.

Handshake - A marker, encodes identity info.
0x00 - 0xFF traditional data byte values.
EOD - End of data, like EOF.

Without that 'handshake' value actually there in the middle of the
plaintext buffered data coming out of the API, I don't know how
application code can get this right.

I haven't seen a TLS library API that defines things that way though.
Many provide a callback for the identity change, but it's unclear
what happens to buffered plaintext at the time it's called.

> and the Finished messages?

Possibly Handshake is really two messages, HandshakeCCS and
HandshakeFinished.

If app data is prohibited before the first Finished, and the RI ext
strongly ties the sessions together, does this issue go away?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2009 23:53:51 +0200

> of an identity change during renegotiation.

I think it's enough to blob-compare the subject DN. As long as both certificates validate, and the subjects are the same, it's enough for "equivalence of identity". I guess applications may introduce more relaxed rules of identity equivalence (such as matching CN), but matching DN should be enough even for the TLS protocol.

An API for the application to determine if old identity is equivalent to the new identity sounds good, but I don't think it would be used correctly in practice. The rule for matching two different certificates for the same EE may not be product-specific or implementation-specific, but may be specific for the installation. A certain organization gave everyone one certificate for their identity, and another for their job.  Matching the two certificates involved querying a directory to find our whether this individual actually had that position. It's an abuse of PKIX, and no product would be ready to employ such logic, unless it was written locally by the IT department of that organization. 

So I think as much of the logic as possible should be in the TLS layer, rather than the application.

---

From: Bill Frantz <[email-masked]>
Date: Tue, 10 Nov 2009 14:32:15 -0800

I would like to add a voice in favor of considering abstract APIs in TLS. I
see abstract APIs as a series of statements like, "The API SHOULD provide a
way for the application to validate and approve the public key of the other
end."

Background: For many years the E language project <http://www.erights.org>,
has been considering moving from our home-brew protocol VatTP
<http://www.erights.org/elib/distrib/vattp/index.html> to TLS. The last
coherent thing I wrote discussing the issue was:

I think the attributes we want to preserve from the existing VatTP are:

   Perfect forward security - Symmetric encryption and MAC keys exist only
   for the duration of the connection. They can not be recovered after the
   endpoints have removed them from memory.

   Distributed public key authentication - The sturdy-refs held by a vat
   contain enough information to authentic the public key sent by the
   remote vat, so additional mechanisms should be avoided.

   The system uses only known-secure algorithms, modes, and protocols.

When I wrote <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>,
there was confusion in my mind between supporting SSL and using SSL. In our
case, we want to use SSL/TLS, and do not need to worry about any of the
many CipherSuites (for example TLS_NULL_WITH_NULL_NULL), which are not
applicable to our use. The CipherSuites (from RFC 4346 and RFC 3268) which
seem most applicable to VatTP are:

  TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same
  algorithms as the current VatTP. All are somewhat dated.

  TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA -
  These update 3DES to the spiffy new AES.

When two vats connect, they exchange public keys. The vats check the public
key they receive against the SHA1 hash in any sturdy refs to be used,
providing assurance that the remote vat is indeed the correct vat. This
procedure is quite different from the certificate authority procedure used
by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have
the user-exits to support this form of authentication. It may be necessary
to adopt an new approach to provide distributed public key authentication.

It would help this process if an RFC gave an idea of what interfaces one
should expect from a library API.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Nov 2009 23:58:06 +0100 (MET)

> identities are interchangeable.

One can not blindly rely on apps to do authentication, let alone
do it consistently multiple times.  Therefore the default should
be exact identity match.

I think that an administrative change to the identity ought to have
an effect on TLS communication established with that identity/credentials,
or it is (a) a security problem and (b) a support nightmare.

If an apps protocol is so broken that it keeps running for weeks after
an administrative change but will fail a reboot, then this is a support
nightmare.

Similarly, if an application wants TLS to use OCSP and also wants
TLS to keep established session running for days or weeks ignoring
certificate expiration and revocation status, then something about
such an apps security requirements is fundamentally flawed.

> Hmmm, is app data allowed prior to the first finished message? No way,

We're talking about renegotiation, not the initial handshake.
The current TLS spec contains a requirement that application data
can be arbitrarily interleaved with handshake message during
renegotiation.

Application data uses a different record type at the SSL/TLS record layer
than handshake messages.  The MAC for the finished messages covers
only the handshake messages, it entirely ignores all interleaved
application data records.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Nov 2009 15:59:10 -0800

> and the Finished messages?

I don't think application data should be (allowed to be) sent between
ChangeCipherSpec and Finished.  Should it be required for a fatal alert
to be sent if such data is received?  That would make sense.

> to decide where the position should be.

I disagree.  When you receive the ChangeCipherSpec, the new parameters
take effect; the Finished message has to immediately follow to verify
the handshake succeeded.  Verification of the Finished message signals
the end of the old session and the beginning of the new.

This would require no application data be sent between CCS and Finished,
but that should be a requirement anyway.  And it would be surprising
to learn about an implementation that doesn't generate Finished
immediately after generating the CCS.

> We're going to plug that MITM attack with secure renegotiation.

Sure, but my point was that if these semantics had existed, this MITM
attack might not have been possible.  Or rather, it would have been
easier to see the problem of applying the new credentials to the old
request retroactively.  I think it would be valuable for an API to add
these semantics even with the addition of secure renegotiation.

> established identities to change during renegotiation.

The CCS/Finished tells you where to draw the line.

> application data transfer during a renegotiation handshake.

This should be up to the particular application.  If rekeying is the
reason for the renegotiation, you want to keep data flowing as much
as possible.  For changing identities, an application might forbid
data flow, or it may not.

> Dropping in the sense of "MUST NOT make it available to the application".

OK, but I would advocate MUST make available to the application and
provide an indication of where the renegotiation finished.

The problem with HTTPS is that the request line is sent before the
handshake even starts, and then once completed, that request line is
reused under the new credentials.  HTTP(S) needs a way to ask the
client to resend its entire request.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Nov 2009 02:39:29 +0100 (MET)

> the end of the old session and the beginning of the new.

Correct.  This is what rfc5246 (TLS 1.2) specified in 7.4.9 Finished
message when describing the handshake protocol.

Unfortunately there is a slightly confusing disagreement with the
description of the SSL Record protocol (which is a logically seperate
thing and often also a seperate sofwarer layer).  As mentionend in
a previous message, the final paragraph of 6.2.1 Fragmentation
in the description of the Record Layer Protocol says this to
implementors:

   Note: Data of different TLS record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

If a company subscribes to agile software development with Scrum and assigns
the implementation of the TLS record layer and of the TLS handshake protocol
to different Scrum teams, you may be surprised with the result on this
point of the spec. :-/

> The CCS/Finished tells you where to draw the line.

If the server implementation that you're looking at uses a
callback scheme similar to OpenSSL, then the application might
have hardwired the update of the client authentication state
(as seen by the app) to the callback that is called when processing
the clients certificate verify message.  At that point, the
session is still in the clear for an attacking MITM, and that
MITM might start inserting application records that the server
will receive at a point where it thinks the client is authenticated
(which it is, just that the client authentication is tied to
an encrypted channel that is still being negotiated and has
not yet been confirmed for the current session yet...

Does OpenSSL offer a callback for the finished messsage of
a renegotiation, and which OpenSSL-based server is using that callback?

I would be OK with interleaving application data with handshake
message for the case where TLS enforces a lockdown of the communicating
identities. 

I really don't like to allow both, change of identities during
renegotiation _and_ arbitrary interleaving of application data
with the renegotiation handshake messages.  Applications
may get this wrong easily.

For earthbound TLS connections a rekeying of a TLS connection
through renegotiation while application data continues to flow
is probably not an issue.  It might become an issue for a link to
a space vehicle further out (like a moon of jupiter),
where one might want to continue transfering a few gigabytes of data
while the TLS renegotiation (for the purpose of rekeying) is performed...

-Martin

---

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

Peter Saint-Andre wrote:
>                                            ...  For example in XMPP
> to reconnect.

There was a discussion around long-lived SSL connections and
reasons for rekeying, e.g. using TLS renegotiation on mogul-open.

If you're using ciphersuites with RC4 or 3DES encryption algorithms,
you probably should not use such connections for prolonged times
or huge amounts of data without rekeying (see below).

The other issue: if you're authenticating such a connection once
based on X.509 certificates and leave it open for month, you might
want to talk to the PKIX folks about this.

They might feel uneasy if you happily continue to communicate
based on an authentication that was weeks or months in the past
and do not care at all the authentication cert may have long
expired or been revoked in the meantime.

(I'm not a crypto-guy, so I'm just quoting this:)

: Subject: Re: DES & renegotiation
: Date:    Thu, 19 Nov 2009 17:08:36 -0800
: From:    Geoff Keating <[email-masked]>
:
:
: For an 64-bit block cipher, at 2^32 blocks (32Gbytes), there's about a
: 40% chance of a collision.  If you prefer your cryptosystems to have
: more like a 1-in-a-million chance of leaking information, you'd need to
: re-key every 48Mbytes or so.  (For 128-bit blocks a 1-in-a-million
: chance requires petabytes of data.)
:
: Most web servers on the visible Internet do support AES; in fact, well
: over half support TLS_DHE_RSA_WITH_AES_256_CBC_SHA (although among the
: most popular servers, the non-DHE AES variants are chosen more often).
: When asking servers to negotiate a cipher out of a fairly long list,
: I found:
:
: 71% AES
: 25% RC4
: 4% 3DES
: (values add to 100% only because of rounding)
:
: A quick survey of 30 randomly-chosen servers that chose 3DES indicated
: that most were running Apache 1.3.x with a variety of older OpenSSL
: versions, the most recent being 0.9.6i.  A few were running IIS/6.0.

-Martin

PS: WinXP and Win2K3 do not support AES ciphersuites.
    Btw. WinXP was shipped with new NetBooks well into 2009.

---

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

> or huge amounts of data without rekeying (see below).

As far as I know, RC4 as used in TLS does not have a significant
problem with encrypting large amounts of data. There are small
statistical biases in the RC4 keystream but they're not a serious
threat in most situations.

If you're worried about the information leakage in using 3DES for
long-lived connections, then it's probably a better option to disable
3DES ciphersuites, than to use renegotiation to rekey. I think that
disabling 3DES should not cause significant interoperability problems
provided you continue to offer both RC4 and AES ciphersuites.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Nov 2009 11:38:35 -0700

> or huge amounts of data without rekeying (see below).

Thanks for the tip. We'll do some research about this in the XMPP WG.

> expired or been revoked in the meantime.

That's why draft-ietf-xmpp-3920bis-04 (section 14.2.2.3) talks about the
need to (1) close the stream if the expiration date occurs during the
life of the stream and (2) periodically check the OCSP responder.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/