Subject: [TLS] TLS renegotiation issue

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2009 19:26:59 -0800

TLS WG members will want to check out this announcement of a
new attack on the TLS renegotiation logic. See here:

http://www.extendedsubset.com/

The high-level summary is that the attacker negotiates TLS with the
server and then subsequently proxies the client's negotiation *over*
that channel. This allows the attacker to inject arbitrary content of
their choice in front of data sent from the TLS client to the TLS
server. This data will be treated by the server as if it came from the
client. Once the new handshake has finished, the attacker can't
do anything else useful.

The attacker doesn't get to directly see any of the client's plaintext
messages but could potentially:

- Issue commands which would then piggyback on subsequent  
authentications
  by the client, including certificate-based authentication.
- Potentially get access to data sent by the client by issuing
  an earlier command which causes the application layer (e.g., HTTP)
  to send the client's traffic to the server.

Marsh Ray, the initial discoverer, has been working with a bunch of
people in the security community to deal with this issue and develop
a fix. Tomorrow AM I'll be posting an initial draft that describes
the obvious fix, which is to cryptographically bind negotiations
to any enclosing connection (if any). I won't be in Hiroshima but
I expect the WG will want to discuss this topic.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2009 19:31:07 -0800

On Nov 4, 2009, at 7:26 PM, Eric Rescorla <[email-masked]> wrote:

> a fix.

I should also mention his colleague from phonefactor, steve dispensa.

Ekr
> Tomorrow AM I'll be posting an initial draft that describes

---

From: Marsh Ray <[email-masked]>
Date: Wed, 04 Nov 2009 21:40:50 -0600

Just out:

http://extendedsubset.com/?p=8

> I should also mention his colleague from phonefactor, steve dispensa. 

And I should mention that EKR, as well as some others who frequent this
group, have been invaluable in this process so far.

I should mention it, but I didn't because I've deliberately left out
names where I didn't have a chance to touch base with the person first.

Anyway, I hope this info proves to be valuable and timely for the
Hiroshima meeting.

By the way, I'm available if I can help answer questions on this list,
on the phone, or direct email [email-masked] .

- - Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2009 19:41:08 -0800

Oh I should or course also mention that this is substantively similar  
to the issue Martin recently raised

Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 18:11:41 +0100 (MET)

> I expect the WG will want to discuss this topic.

One conceivable approach would be a TLS extension for secure renegotiation
with roughly the following semantics:

 - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL)
   the client that supports secure renegotiation should send the
   TLS extension in the client hello with an empty extension data
   to signal to the server that it support secure renegotation.

 - on TLS session renegotiations, the client should sent the TLS extension
   with the extension data containing the client.random and server.random
   from the existing session.

 - A server that receives a ClientHello without the TLS extension for
   secure renegotiation should NOT perform old-style renegotiation
   for that session (and get apps with flawed assumptions into trouble),
   i.e. NOT support delayed authentication for those TLS clients.

 - A server that receives a ClientHello on an initial TLS handshake
   with a TLS extension (empty data) for secure renegotiation may decide to
   delay client-cert authentication to a securely renegotiated session

 - A server that receives a ClientHello with a TLS extension for secure
   negotiation and a reference to a previous session MUST compare the
   client.random and server.random from the extension data to that of
   the current session (and abort if they do not match).  And the
   server should probably insist on doing a ChangeCipherSpec on both
   directions in the renegotiation handshake.

Since Larry is looking for a means to uniquely identify a single
TLS "connection" independent of whether its a single TLS handshake
or renegotiated, we should check whether we can carry-over some
information form the initial handshake on a connection along
with the client.random&server.random.  Technically there is no
limit on the number of renegotiations, so a simple pointer
only one TLS session into the past does not seem sufficient
for that purpose.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 05 Nov 2009 11:23:26 -0600

I expect that EKR will be posting some details soon.

Martin Rex wrote:
> Technically there is no

I agree, the concept of "first handshake on the socket" is a bit
nebulous from the perspective of the TLS spec.

The approach our proposal took was to work off of the "most recent
previous finished message" over the underlying transport.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 11:13:08 -0600

>    from the existing session.

The MITM can make sure they match.

Why not just send an extension with the tls-unique channel binding for
the first/outer connection, and then make sure that that gets fed as an
input for the PRF in the second/inner connection?  I.e., proper channel
binding.  The MITM _cannot_ make sure that the tls-unique CB of the
client<->MITM and MITM<->server outer connections match.

>    i.e. NOT support delayed authentication for those TLS clients.

Right.

>    delay client-cert authentication to a securely renegotiated session

Right.

>    directions in the renegotiation handshake.

See above.

> only one TLS session into the past does not seem sufficient

See above.  Use tls-unique.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 18:38:10 +0100 (MET)

> nebulous from the perspective of the TLS spec.

For the secure renegotiation, the pointer exactly one TLS session
into the past seems perfectly sufficient to me.

Solving the nebulous concept of "first handshake on the socket"
is something that Larry wants a solution for, and which needs
a different approach.

The "secure naming" of a TLS connection has much more to do with
API semantics than with TLS wire-protocol and TLS session state.

TLS renegotiation does IMHO also interfere with the TLS PRF
(aka TLS-extractors), so that applications can not call it
at arbitrary points in their communication with a peer when
there might be a renegotiation between the point in time
when the client app calls in and when the server app calls it.

> previous finished message" over the underlying transport.

The "secure random challenges" in a TLS handshake that protect
agains replay are the client.random and server.random.
Admittedly they're larger (2*32 octets, fixed size) than the
finished message (usually 12 octets, but depends on ciphersuite
according to rfc5246 7.4.9.)

The client.random and server.random of a connection are already
part of the official SecurityParameters (rfc5246 6.1.), but
the finished message is not.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 11:25:14 -0600

> I expect that EKR will be posting some details soon.

We await with bated breath :)

> nebulous from the perspective of the TLS spec.

Only at first glance.  The "first handshake", or, rather, "outer-most
handshake" is really one that occurs with null cipher spec, that is, not
under the protection of another TLS connection.

> previous finished message" over the underlying transport.

I recommend "the client finished, in cleartext, from the outer-most
handshake", with "first handshake" as described above.

Better yet, though equivalently, I recommend "the tls-unique channel
bindings of the outer-most handshake".  (Or at least state the
equivalence, and add a reference to draft-altman-tls-channel-bindings
and RFC5056.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 18:45:46 +0100 (MET)

> The MITM can make sure they match.

Not a problem.

If it does, that will become obvious in the verification of
the finished messages of the renegotiation handshake.

In addition to the Finished Message verification, such doctoring
will be detected in the ClientVerify verification by the server
when that is a signature over all previous handshake messages
(which is the default).

I'm usually prefer low-impact improvements, which can be added
to existing codebase with ease.  client.random | server.random
from the existing connection seems like a good candidate to me.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 11:37:31 -0600

> the finished message is not.

Guess what: the finished messages will have to become something that TLS
implementations export to applications.  There's no two ways about it
folks.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 11:50:44 -0600

> client<->MITM and MITM<->server outer connections match.

I should expand on this.

Suppose you have:

 client <-> MITM <-> server

When the client sends its outer conenction client Hello to the MITM, the
MITM sends one with the same client.random to the server and waits for
the server to send its Hello back, then the MITM sends a Hello back to
the client using the same server.random that the server sent to the
MITM.

The first exchange completes on both sides of the MITM, then the client
sends a request.  The MITM replaces the client's request with whatever
the MITM wants and sends that to the server.  The server requests a
re-negotiation, the MITM passes that on.  When the client and server
re-negotiate they will see that the client.random and server.random from
the outer TLS connection matches.  The MITM wins.

You can't use the client.random and server.random as channel bindings.

But the client's Finished message from the outer TLS connection works.

Suppose the first handshake uses an anonymous DH cipher suite.  The MITM
cannot solve the discrete logarithm problem, therefore the MITM cannot
make sure that the client and server exponentials match for both, the
client<->MITM and MITM<->server connections, therefore the MITM also
cannot cause the Finished messages to match.

Suppose the first handshake uses an RSA key transport key exchange.
This means there must be a server cert.  The MITM cannot make sure that
the server cert seen by the client in its client<->MITM TLS connection
matches that of the real server in the MITM<->server TLS connection
without either possessing the server's private key or breaking RSA.

In all cases, no matter what the TLS key exchange method used, the
Finished messages had better bind the entire handshake and the key
exchange in such a way that no MITM can force the Finished messages to
have any particular value or otherwise match another connection's
Finished messages.  This is central to the security of TLS.  If a MITM
can make the Finished messages for two connections match, then the MITM
must have broken TLS itself.  That's what makes the TLS Finished
messages such a wonderful channel binding for TLS connections.

(In all cases, if the MITM can solve the discrete logarithm problem, has
possession of the server's private key, or can break RSA, you have
bigger problems than a MITM attack.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 19:16:02 +0100 (MET)

Nicolas Williams wrote:
>  [helpful explanantion removed]

Blush -- you are correct.

The MITM can make the two previous sessions come out with the same
client.random and server.random.

So these are not a secure back pointer.

> You can't use the client.random and server.random as channel bindings.

I'm trying to use terminology that is already in the TLS specs.
The generic term "channel bindings" is a little bit to fuzzy for
my taste, and the original use of channel bindings in GSS-API
is not cryptographically secure.

> But the client's Finished message from the outer TLS connection works.

OK.

You win.  ;-)

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 10:16:11 -0800

I now have a draft extension up at:

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Comments welcome.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 12:26:26 -0600

> is not cryptographically secure.

I understand.  The spec will just have to be updated to say that the
finished messages (or at least the client one) are to be exported to
applications.

TLS implementors, know this: you must update your implementations to
export to applications, at least the client Finished message for at
least any and all "outer-most" TLS handshakes (that is, handshakes not
protected by another TLS connection's record layer).

This is just a matter of interfaces for all software implementations.
For hardware implementations it's going to be tougher -- particularly
tough for concentrator implementations.  (Provided that a concentrator
terminates both, the outer and inner TLS connections, then all other
uses of TLS channel binding can use the tls-server-end-point channel
binding type.  But really, you'll want to export the tls-unique channel
bindings.)

> > But the client's Finished message from the outer TLS connection works.

Hey, it's not about winning!  I perfectly understand, and _share_, the
desire to use existing interfaces where possible.  In this case there is
no such interface (in some TLS APIs apps could parse the TLS record
layer and heuristically find the record that contains the protected
client Finished message, but that's... not really an interface, not what
we wnat, and not reliably available everywhere).

We've looked at this problem many times before, and this is always the
conclusion that we've come to.  I really wish that TLS 1.2 had made the
client Finished messages part of the exported security parameters (I
really wish I'd thought to make sure that 1.2 did that).  But then,
making the 1.2 spec say this is not enough: installed base inertia is
what makes it hard to ensure that Finished messages are exported.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 12:28:53 -0600

> is not cryptographically secure.

Also, the term "channel bindings" is only fuzzy as used in RFCs
2743/2744.  But RFC5056 put an end to that.

If you believe that RFC5056 leaves the term too fuzzy still, then please
explain how, and then we can look at updating RFC5056 if need be.

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Nov 2009 18:40:21 +0000

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Most email addresses are incorrect. 8-)

Based on the attack description in the draft, the server can implement
a layering violation and detect a splicing which crosses an
application-layer record boundary (which should result in a hard
error).  If the splicing does not cross a boundary, there is not
really any ambiguity, just a succession of differently authenticated
application records.

What seems to happen in vulnerable applications I've created in a
previous life (but I have no longer access to them, so I can't check
for sure) is that in a HTTP context, you tend to perform a sub-request
within the server to get the authentication information which only
applies to future requests, and use that to answer the
not-really-authenticated request as if it were authenticated.  As a
result, you're still vulnerable even if you refuse to renegotiation in
the middle of an HTTP request message.

So avoiding protocol changes seems to require an API change (to expose
part of the TLS record layer to the application layer, so that
byte-exact authentication information is available) plus extensive
application code changes, potentially resulting in additional
client/server round-trips.

Therefore, I think a protocol change is less invasive (assuming that
it is essentially free-for-all-uses IPR-wise).

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 19:48:26 +0100 (MET)

Eric Rescorla wrote:
> 
> I now have a draft extension up 

Thanks Eric.

  Page 5:

  The contents of this extension are specified as follows.
   [...]
  The above rules apply even when TLS resumption is used.

I read this as meaning that the client and server should add
two elements client.verify_data and server.verify_data
to their SecurityParameters for the connection state suggested
by RFC5246 6.1. and update this data on EVERY TLS handshake,
even TLS session resume.

  4.1  Client Considerations

I can understand what it says, but I _really_ dislike it.

The root of the problem is servers that perform (or at least allow)
TLS renegotiations and make flawed assumptions about what a
successful TLS renegotiation means for the data previously received.

What you're essentially asking for, is that a client should no longer
talk TLS to _any_ Server that doesn't support the new extension.
Not even to the good ones that neither offer nor support renegotiation.

This is discriminating against servers that have been playing safe!

Essentially we are going to hold TLS clients and the installed
base of good Servers responsible for the broken Servers out there.
That feels very wrong.

-Martin

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

That URL results in a cert warning in my Firefox browser.
Following the Client considerations, I feel much safer
removing the "s" in "https" in the URL than trying to add
an exception for the servers certificate...  ;-)

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 05 Nov 2009 10:50:31 -0800

Excerpt from the PDF:

 > char *req =
 >   "GET /highsecurity/index.html HTTP/1.1\r\n"
 >   "Host: example.com\r\n"
 >   "Connection: keep-alive\r\n"
 >   "\r\n"
 >   "GET /evil/doEvil.php?evilStuff=here HTTP/1.1\r\n"
 >   "Host: example.com\r\n"
 >   "Connection: close\r\n"
 >   "X-ignore-what-comes-next: ";

The attack works because the last line is unterminated to effectively
comment out the client's GET request.

A possible counter to this attack is for the client to send two
CRLF's prior to its actual request.  This will separate the evil
request from the actual one containing the Cookie.  RFC 2616
prohibits this, but suggests that HTTP servers ignore extraneous
CRLF's due to buggy HTTP/1.0 clients.  In practice, HTTP servers
I've tested ignore them.

Mike

Marsh Ray wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Just out:
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkrySUAACgkQWChJ3x422/KR/gCfcoAZMgD4RsXVUtLinCSDYWnk
> 14YAnAmtQWE64+61Z0y5ioh/NM1DoPyz
> =YVva
> -----END PGP SIGNATURE-----

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 10:52:59 -0800

> by RFC5246 6.1. and update this data on EVERY TLS handshake,

Yes. That's what it means.

> base of good Servers responsible for the broken Servers out there.

I'm not recommending that clients do that. What I'm trying to say is that
*if* a client wants to be totally sure then all it can do is require
the extension.
I agree it's impractical (and probably unwise) to suggest that they actually
behave that way.

Do you agree that the characterization above is correct? If so, how can I
update the draft to make that clearer?

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 12:46:15 -0600

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Initial comments based on a brief skim:

 - Please add a normative reference to RFC5056.

 - There's no real need for the ServerHello to include both of the
   Finished messages from the outer TLS connection.  (I think there's no
   real need for the ServerHello to include either of them, actually,
   but I've not thought enough about that.)  But it's OK as is, of
   course.

 - You call for each TLS handshake to bind to the one immediately
   outside it.

   Would it be better to bind to the outer-most one instead?

   (In practice there's probably never more than one outer and one inner
   handshake, right?)

 - There is a way for clients to protect themselves even when servers
   don't implement this extension:

   a) clients MUST NOT ever send any application-level messages without
      TLS protection if they are willing to negotiate a TLS connection
      after sending any application-level messages,

   _and_,

   b) if a server requests re-negotiation then the client MUST ensure
      that the outer and inner TLS connection handshakes used a server
      certificate, and, specifically, the _same_ server certificate,
      otherwise the client MUST abort without ever completing the
      second/inner handshake.

   This should be stated as it is a helpful workaround that works
   without modifying the protocol.  It's not a generic solution, and
   it's a client-side-only solution, which is why it's highly desirable
   to apply the proposed channel binding solution instead.

 - Might as well update RFC5246 to indicate that the Finished messages
   for any connection MUST be exported to applications.  Better get this
   done now.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 11:09:51 -0800

>  - Please add a normative reference to RFC5056.

There's no need for a normative reference here. This mechanism is
self-contained.
I'd be happy to add an informative reference.

>   but I've not thought enough about that.)  But it's OK as is, of

The general consensus was that it was harmless and might potentially
avoid some reflection logic errors.

>   (In practice there's probably never more than one outer and one inner

Why do you think this is an improvement.

>      otherwise the client MUST abort without ever completing the

This isn't enough. If you look at the diagram you can see that the
client never experiences a renegotiation.

>   for any connection MUST be exported to applications.  Better get this

This sort of interface issue seems out of scope for the TLS spec.

-Ekr

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Nov 2009 19:09:49 +0000

* Michael D'Errico:

> request from the actual one containing the Cookie.

It's very hard to tell if this plugs the vulnerability in all cases.
I've written web applications which use an server-internal atemporal
request to access future authentication information.  While that might
seem naive in retrospect, it was the recommended way of adding client
certificate authentication without introducing additional round-trips,
so I'm probably not the only one who did that.  These applications
will likely remain vulnerable if you confine splicing to HTTP request
message boundaries.

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 20:29:28 +0100 (MET)

>  - Please add a normative reference to RFC5056.

I admit to not know what that exactly means, but it sounds wrong.

It is perfectly possible to write this document in a fashion that
an implementor does NOT NEED to read rfc5056, and therefore I
would strongly prefer to keep it that way.

>    but I've not thought enough about that.)  But it's OK as is, of

The Server should send back something different than on initial
connect in order to indicate to the client that it is convinced
this is a renegotiation rather than an initial handshake.

Sending back the verify_data from Server finished seems fair to me.

>    Would it be better to bind to the outer-most one instead?

I prefer it the way it is currently described, referencing the
predecessor.

>    (In practice there's probably never more than one outer and one inner

Technically, there can NEVER be more than two, as required by
the TLS spec (there is only one current and one pending) so technically,
the existing proposal is referencing the "outer-most" TLS session.

You were probably asking for the first TLS-handshake on a connection?

The existing proposal looks like less code to me.

>    don't implement this extension:

I would hope there is a way, but I have not seen one so far!

There are actually two different scenarios:
the one I suggested where both sides, client and server perform
a renegotiation, and the one described by Marsh, where a clients
initial TLS handshake is proxied into a renegotiation for the
server.

Without a change of the server, the client has certain difficulties
to determine whether it is participating in an initial TLS handshake
or being proxied into a renegotiation in Marsh's scenario.

There are certain safeguards a client can apply (but which are not
currently advised by the spec, so are unlikely to be implemented
in existing clients.

A TLS client could insist on a server credential to not change
during a renegotiation.  That helps for my scenario, but
not for that of Marsh.

A TLS client should probably not accept a HelloRequest and neither
a CertificateRequest message on a server-anonymous TLS session
(DH_anon).

>    for any connection MUST be exported to applications.  Better get this

I haven't sufficiently thought about this to like it.

Adding the finished messages to the renegotiation handshake
is fine, because they have originally exchanged under the protection
of the currently active ciphersuite, so this should have zero impact.

You're asking to make something available that has not been previously
available to the application.  This might be harmless, but I don't know.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 21:21:44 +0100 (MET)

> finished messages (or at least the client one) are to be exported to

Huh -- wrong topic?

Eric's proposal to make renegotiation secure does not need any
API-level changes, everything is completely internal to the
TLS protocol engine.

What you're looking for might be necessary for application-level
channel bindings, but that is a different topic.

I don't mind discussing this, but I would appreciate if you identify
the topic/solution that you're discussing.  ;-)

> 
>                                 I perfectly understand, and _share_, the

On the network, the finished messages are protected under the negotiated
ciphersuite.  Eric's proposal used the verify_data in its decrypted
form, and I thought you were asking for these as well.

> what makes it hard to ensure that Finished messages are exported.

Exported security parameters?

Your desire to get your hands on the finished message from the
App layer for channel binding purposes is an API issue.

The TLS-specs describe only bits-on-the-wire, protocol semantics
and TLS session state management.  The TLS specs are entirely
silent on API issues.  (The IETF does not do APIs, and GSS-API
is an exception.)

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 14:21:31 -0600

> I'd be happy to add an informative reference.

That's also true about draft-altman-tls-channel-bindings then, but you
have a normative reference to it.  I'm happy with an informative
reference.

> avoid some reflection logic errors.

If the server sends anything other than a mere acknowledgement, it
should send its Finished message from the outer connection -- the client
can then check that to see that the server really does understand this
-- and the doc should say that the client must check this (but I think
it does say this).  The server sending the client's Finished message
back is superfluous, but I agree that it's harmless.

> Why do you think this is an improvement.

Either way the binding would ultimately be to the outer-most connection,
therefore this way there's less state to track.  A minor point, I agree.

> client never experiences a renegotiation.

That's one diagram.  There's other cases, but even in the case you
described, if the client never experiences a re-negotiation then it will
not have authenticated itself, or, if it has authenticated itself then
it will/should also have authenticated the server to the client, in
which case the MITM can't be.  As a result the MITM gets nothing.  (My
rules cover the case where a client would send a request unprotected,
then negotiates TLS when the server requires authentication -- my rules
forbid that.)

> This sort of interface issue seems out of scope for the TLS spec.

Let me re-phrase: the finished messages should be added to
SecurityParameters (Martin evidently takes that to be something should
be exported to apps; I don't entirely agree with Martin on that point).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 14:30:45 -0600

> would strongly prefer to keep it that way.

Referencing RFC5056 wouldn't so much be to provide guidance to
implementors as to say "this document conforms to RFC5056".

> this is a renegotiation rather than an initial handshake.

Indeed, it must send something.  Even one bit will do -- that was my
point.

> Sending back the verify_data from Server finished seems fair to me.

I agree -- that allows the client to verify that the server did
something more than agree.  There's no point in the server sending back
the client's Finished message though -- that adds no value and wastes
space on the wire (very little, granted).

> Technically, there can NEVER be more than two, as required by the TLS
> spec (there is only one current and one pending) so technically, the
> existing proposal is referencing the "outer-most" TLS session.

Interesting.

> initial TLS handshake is proxied into a renegotiation for the

Ah.  I was considering only one of those attacks.  You're correct, there
is no workaround short of fixing the protocol.

> of the currently active ciphersuite, so this should have zero impact.

For an implementation like Microsoft's SSPI-based implementation TLS
that might not be true, since there each TLS connection is represented
by a separate "security context" -- for such an implementation the fix
requires that the application help the implementation link those
security contexts.

> available to the application.  This might be harmless, but I don't know.

How could it not be harmless?  What damage could ensue from making the
Finished messages of a TLS connection available to the application?
Remember: there are cipher suites that provide only integrity
protection, therefore Finished messages must not leak any information
about the master secret (and indeed, they do not, module the
cryptographic strength of the relevant algorithms used in the Finished
message construction).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 14:31:39 -0600

> That's one diagram.  There's other cases, but even in the case you

Oh, never mind.  I missed one attack scenario, the one in your doc.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 14:38:17 -0600

> > finished messages (or at least the client one) are to be exported to

Not really.

Eric's view seems to be that the TLS spec should say nothing about this.

I think it should, for the simple reason that it will help prevent this
sort of problem in the future.

> form, and I thought you were asking for these as well.

You misunderstood the parenthetical.  The point was that one might think
that apps could get at the Finished messages without help, but in
reality they could only get at the protected Finished message, and only
if the TLS API was such that the apps could see the TLS record protocol
directly, and then only by implementing a heuristic -- all of which is
something we _don't_ want.  I wrote that parenthetical to preempt anyone
saying "why don't you just do [what the text in paren. talked about]?".

> silent on API issues.  (The IETF does not do APIs, and GSS-API

Wrong.  The GSS-API is NOT the only exception.  There's also SCTP, and
probably a number of otheres (heck, even IDNA has an abstract API).

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 12:55:38 -0800

> have a normative reference to it.  I'm happy with an informative

That's an editing error. I'll add informative to both.

> then negotiates TLS when the server requires authentication -- my rules

You're assuming that certificate-based client auth is the only issue.
But the attacker can do damage just by injecting a prefix to an
ordinary cookie-authenticated request.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 12:57:23 -0800

FWIW, here's my more complete analysis.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Nov 2009 12:58:08 -0800

well, that was really complete, but the link below is even more so!

http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 05 Nov 2009 23:00:55 +0200

> client. Once the new handshake has finished, the attacker can't

 I'll become a bit pedantic and note here that this isn't really a TLS
issue. We have an initial server-authenticated only session and some
renegotiation of parameters over it to authenticate the client. However
TLS doesn't guarantee[0] that if the renegotiation is successful
authenticating the client, then the data from the initial session were
also by the same authenticated client.
 Think for example a session that it is anonymous (DH). Why one should
assume that commands over the anonymous connection are to be trusted if
a successful renegotiation follows?

So for me the issue is on HTTP's usage of the TLS protocol
renegotiation. After a TLS renegotiation for authentication the previous
command cache should have been cleared and reissued after negotiation.

I like the fix in TLS though. As I understand it is a way for the
clients and servers to keep some state between negotiations, which is a
good thing and actually seems to give the guarantee above.

regards,
Nikos

[0]. or is it mentioned somewhere I didn't notice?

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 05 Nov 2009 22:44:37 +0100

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

Does anyone have a public testserver up and running yet?

-- 
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: Martin Rex <[email-masked]>
Date: Thu, 5 Nov 2009 22:56:45 +0100 (MET)

> Eric's view seems to be that the TLS spec should say nothing about this.

I fully agree with Eric.

IMHO, this proposal should become integral part of rfc5246bis.

For the channel bindings topic, in particular when it starts
discussing API issues, I personally would prefer when it
remains in a seperate document.

> probably a number of otheres (heck, even IDNA has an abstract API).

Well, OK.

While I was actively participating IETF meeting (1995-1998) it was
pointed out several times in IETF plenaries by IESG members that
the IETF does not do APIs and GSS-API was an exception.

I seem to have missed that this has changed.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 16:06:41 -0600

> I seem to have missed that this has changed.

I don't think it was ever really true that "the IETF doesn't do APIs".
There have been many people who've said that, but I don't think it was
ever the case that the IETF explicitly said it wouldn't (i.e., there are
no RFCs, historic or otherwise, saying that).  It was always just a
canard.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 05 Nov 2009 16:28:57 -0600

> I don't think it was ever really true that "the IETF doesn't do APIs".

I would add here that if the IETF had compared the way TLS looks on the
wire with how it is presented by SSL APIs in practice, this defect could
not have gone unnoticed.

- - Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 16:31:30 -0600

> wire with how it is presented by SSL APIs in practice, this defect could

Indeed.  Larry Zhu described to me how the SSPI models TLS just a few
days ago.  I should have noticed immediately the lack of binding, but
because I wasn't also thinking of HTTPS, I didn't.

I'd go far enough to say that we must consider at least abstract APIs to
protocols such as TLS.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 17:03:44 -0600

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

More comments:

 - Consider an implementation like Windows' SSPI-based implementation.
   Or, for that matter, the old GGF (Global Grid Forum) GSS-API
   interface to TLS.

   In such an implementation each TLS connection is a distinct "security
   context".  So in the re-negotiation case there are two distinct
   negotiations, each being an application-driven API (i.e., in each
   case the application calls functions like the GSS-API
   GSS_Init_sec_context() and GSS_Accept_sec_context()).

   So how would an implementor with such an API implement your proposal?
   Like so:

   1) Add a function to extract the Finished messages from a TLS
      "security context".  This is trivial to do: it's just a new
      function, an accessor of security contexts.

   2) Add a function or input to the init/accept_sec_context functions
      by which to pass in, to a new "security context", the Finished
      messages of another TLS "security context".  This can't easily be
      done as a new accessor-type function -- it has to be a new
      function argument, which... can't be done, so that one has to
      simply add new versions of the init/accept_sec_context functions.

   But wait!  The SSPI/GSS-API already have the (2)!  And we call it a
   "channel binding" input.

   You can see where I'm going with this.  It will help keep existing
   APIs clean if you just stick to the RFC5056 model and call this
   "channel binding".

That is, I propose that you re-shape the proposal as a generic channel
binding facility for TLS.  The actual changes to the proposal are fairly
minor: a) the proposed extension needs to carry an opaque octet string
of variable length, b) the server should echo a trivial transformation
of the client-provided string.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 00:24:55 +0100 (MET)

> wire with how it is presented by SSL APIs in practice, this defect could

I would like to put this differently.

There are several different APIs and API architectures for SSL/TLS
protocol stacks.  If you really want to verify a spec, there is
no better way than implementing it.  As an implementor, you get
to see both, the TLS protocol engine as well as the API that
you make available to application callers.

And when an implementer describes to its consumers how to use
the implementation and how to architect the applications usage
of TLS, this problem should really have been noticed.

Finding problems when discussing things at an abstract level
is MUCH MUCH harder.  You notice that when people define
protocols with ASN.1 elements.  It's almost exclusively
the implementors who find the problems. 

The (OEM) SSL/TLS library that we ship does not support renegotiation
in the server implementation, so I never thought about the implications
of using renegotiation on the server side.

And when we started shipping SSL, my knowledge about the SSL/TLS protocols
was quite limited.  My expertise was mostly around GSS-API at that time.

-Martin

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 Nov 2009 16:26:25 -0700

> the IETF does not do APIs and GSS-API was an exception.

As a current member of the IESG, I think I can say that has changed at  
least a little bit. There are place where the IETF standardizing and  
API, or abstract level of an API, makes sense - and places where it  
does not. I imagine the choice to do an API or not would be handled on  
a case by case basis. I don't have any simple hard and fast advice to  
offer other than talk to the Sec ADs.

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 00:51:59 +0100 (MET)

>    Or, for that matter, the old GGF (Global Grid Forum) GSS-API

This strikes me as really odd!

Btw. does GGF really require renegotiation?  What is so impossible
about asking for a client cert in the initial TLS handshake?

I read your message to mean that applications based on architectures
like SSPI and GGF will need to modify their code INDEPENDENTLY to
how we solve the problem to avoid the security problem as well
as to adopt the solution.

Why do you insist that we make the change in a fashion that
caters a particular API?

I would not mind if those TLS implementers with the GGF and SSPI
use the terminology and function parameters they formerly called
"channel bindings" (AFAIK SSPI doesn't have channel bindings)
to pass along the finished messages described in Erics document.

I am certainly opposed to adopting one particular API's
terminology and confuse other API architectures where there
already is an established term for the piece of information
that we want to carry over between an existing TLS session
and a new TLS session.

What I definitely do NOT want here, is make that new box
(the TLS extension for secure renegotiation) officially available
to the discretion of the application caller, since those
applications just demonstrated to act based on extremely
flawed assumptions.  If you want to do that for your particular
implementation, OK.  I definitely do not want to see this
being recommended or encouraged by the TLS spec.

Once bitten, twice shy.

> of the client-provided string.

So for this particular issue we're discussing here, those APIs should
build solutions to pass down the security context handle of the
"current" TLS session to handshake operations performed by the "pending"
TLS session, so that these can retrieve and verify the relevant
verify_data structures.

For OpenSSL-style APIs the TLS session renegotiation happens
(or is denied) transparently on the same SSL session handle.

-Martin

---

From: Michael Gray <[email-masked]>
Date: Fri, 6 Nov 2009 10:00:23 +1000

> > FWIW, here's my more complete analysis.

IMHO The proposed fix looks to be also introducing the concept of
Retrospective Trust into TLS.  This being necessary due to the problem
highlighted in the HTTP protocol in that it will process messages that
arrived prior to authentication etc.  However, IMHO I would guess that once
TLS is perhaps protected, then the attacker will simply attack at some
other level as the HTTP/Web Application is still vulnerable. IMHO these
other attacks might be easier to do and perhaps at the same time harder to
detect.  My view is that implying Retrospective Trust in TLS will lure
application developers into incorrectly thinking they are now (or are
still) safe and continue the IMHO dangerous practice of Retrospective
Trust.  IMHO I would question why allowing the concept of Retrospective
Trust into TLS is not inherently dangerous.

Mick Gray

P.S. - The opinions above are my own, and not necessarily those of my
employer.

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 18:00:02 -0600

> This strikes me as really odd!

What's odd?

> about asking for a client cert in the initial TLS handshake?

Did I say that?  No.  Please don't read into what I wrote.

But note that with a GGF GSS-API-based implementation of TLS you _can_
do re-negotiation!  It's simple really.  And it shows that there's no
link between the inner and outer connections (here, security contexts),
except that the outer one protects the inner's hanshake (here, security
context token exchange).  (Well, also, the app needs to know if the
server sent a ChangeCipherSpec message, so that it can switch to using
the inner security context for all subsequent wrap tokens.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 17:56:48 -0600

> the implementors who find the problems. 

Implementors, on the other hand, may not have the experience necessary
to determine the consequences of a flaw like this, they may (and
probably did) just shrug.  More likely though, you can't really predict
who's going to find any given vulnerability.

Providing more information, more views, always helps.  In this case it
would have.  But then, too, we should keep in mind that there are many
possible TLS API designs -- Marsh is saying, I think, that the SSPI-/
GSS-API-like ones that would have made this flaw obvious, and I agree.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 18:12:59 -0600

On Fri, Nov 06, 2009 at 12:51:59AM +0100, Martin Rex wrote:
> like SSPI and GGF will need to modify their code INDEPENDENTLY to how
> we solve the problem to avoid the security problem as well as to adopt
> the solution.

Implementations clearly have to change.  Implementation with a specific
API design that I identified will require application changes to go with
the TLS implementation changes.

> Why do you insist that we make the change in a fashion that

[Overlooking you use of the ver "to insist" for a moment...]  For two
reasons:

1) If it's not onerous for any other implementors, then making a change
   that makes the fix simpler for some implementors is worth
   considering;

2) RFC5056 exists and defines channel binding.  Channel binding _is_
   what the proposed fix here actuall does, but in a way that does not
   conform to RFC5056, and in a way that does not conform to APIs that
   have support for channel vbinding work (APIs that can be interfaces
   to TLS).

Not conforming to RFC5056 is hardly fatal.  And if some implementors
have to do ugly things to their APIs and applications using them, well
too bleeping bad.  Right?

But I have a right to ask for the WG to consider making this fix conform
to RFC5056 and not force some implementors to do ugly things to their
APIs.  Not a right to demand, mind you -- the WG consensus can reject my
proposal.

Rather than cast this as me "insisting" on something or other, how about
debating the actual proposal?  Say what you like or dislike about it.
See where the chips fall.

> to pass along the finished messages described in Erics document.

Neither would I.  Except that they _can't_ with Eric's proposal, not
without violating abstractions and interpreting the contents of the
channel bindings input, which is why I object.

> that we want to carry over between an existing TLS session

Whatever.  No one asked that you, or Eric, or the WG or anyone else do
that.  There's no need to use SSPI or GSS-API terminology in the
resulting spec.  There is a desire, on _my_ part, for RFC5056
conformance.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 18:29:28 -0600

Note, there's a way to implement Eric's proposal as-is and in an
SSPI/GGF-GSS-API way that doesn't suck, but which does require a
layering violation, though one that I could live with:

 - client and server apps both extract the 'tls-unique-for-telnet'
   channel binding from the outer connection, prefix that with the
   RFC5056-required prefix, and pass that to the init/accept_sec_context
   functions.

 - The TLS init/accept_sec_context implementation checks to see if the
   channel binding input starts with "tls-unique-for-telnet:" (the
   RFC5056-required prefix when using that channel binding type), and,
   if it does, then split the rest of the channel binding input
   accordingly and use the two halfs as per-Eric's proposal.

I can live with that.  I'd like to have a generic channel binding
facility in TLS.  I'd like to not have to implement such a layering
violation.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 02:05:45 +0100 (MET)

Michael Gray wrote:
> arrived prior to authentication etc.

To some degree I share your concern.  

However, I do believe that the the proposed fix to provide secure
renegotiation primarily fixes a problem in the TLS protocol, which
does not live up to its own promises on security of a TLS session
renegotiation.

Admittedly, the momentum behind this effort is the prospective
blessing this will provide on the current awful practice in this
area, because first of all, vendors _and_ implementors are trying
to maintain the current level of look&feel / usability -- or maybe
we should call it "convenience".

If we forgive the applications today, they are going to do even
more daring things tomorrow -- and that could be things that
we cannot fix easily.

In real life, however, security is much more about risk management
than absolute security.  Bruce Schneier has written at least a dozen
good articles about that topic.  The more difficult security is to
use, the more often people will work around it.

I think we should improve on guidance, rather than be totally anal
about who goofed which part.

>
> However, IMHO I would guess that once TLS is perhaps protected,
> then the attacker will simply attack at some other level as the
> HTTP/Web Application is still vulnerable. IMHO these other
> attacks might be easier to do and perhaps at the same time harder to
> detect.

Just a second!  The problem were addressing here is _NOT_ easily
detectable.  I think it is just the opposite.

There has always been an arms race.  And I don't see how or why
this would change in the future.

What exactly do _you_ suggest?

That we _not_ fix this issue in TLS, so that the apps can keep
pointing on us and do not have to fix their other problems?
Is that really going to help?

>          My view is that implying Retrospective Trust in TLS will lure

As inidicated at the beginning, there is some truth in what you're
saying.  But looking at all aspects of the problem, I don't feel
like not fixing this is the bigger evil.

But your criticism about the Retrospective Trust is quite valid.
It is a dangerous design, and it is questionable that the risk it
brings is worth the convenience it offers.

Compare it to this real-world scenario:

Today, many companies have tight control on who enters their office
buildings, and it helps them to manage their risk and gives them
some amount of audit and accountability.

The Retrospective Trust means that you get rid of that control
at the building entrance.  Instead, you solely rely on your
own perfection to reliably check each and everyone that leaves
an office with a binder in his hands.  Either he must show his
permission or leave without the binder.  You regularly find
someone without permission, but you're not allowed to ask his
name, and a few of them constantly do this and you have no
means to keep them out of your building.

I would not describe the latter as sensible risk management.
It doesn't look very reliable or robust.  But if you implement
some convenient "permissions check" (hey, rfid is fun, isn't it),
it might feel quite convenient for the people that work
there.  Having to pass a gate one-by-one during rush hour
(morning,lunch,evening) often creates a less appealing
user experience.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 04:14:30 +0100 (MET)

> channel bindings input, which is why I object.

The security context iterators (InitializeSecurityContext
and AcceptSecurityContext  or gss_init_sec_context/gss_accept_sec_context)
are designed to exchange opaque tokens between the peers (client
and server  / initiator and acceptor ) 

What you are looking for is a token exchange between two security
contexts, old and new.  Ultimately you could create full blown
iterator calls to do this.  Or a "cheap" one-token hack like this:

GetCarryOverData ( oldsecuritycontext, &opaque_buffer );
CreateSecurityContextWithCarryOver( opaque_buffer, &newsecuritycontext );
ReleaseBuffer( &opaque_buffer );

Or with just a single call:

CreateRenegoContext(oldcontext, flags, &newcontext);

with a little modification of the init and accept iterators so that
they can start with a context handle created by this new call
instead of a NULL handle.

The latter single-call approach seems the cleanest to me,
because it is the most flexible in case we ever find another
need to transfer information between an original and renegotiated
session -- without having to change apps that use a GSS-API style
architecture.  And it is the one which is the most difficult
to break by careless applications.  :)

Limiting the evolution of the TLS protocol and the interaction
between current and pending session states seems like an
unjustified restriction to me.  If a particular API has
a problem with a useful evolutionary change of TLS,
then this might be a design shortcoming in the API
and should be fixed there.  I don't think we should deny
in a very useful way just it might have an impact on
certain esoteric API architectures.  

Comparing the amout of work to (a) technically block
the renegotiation in the TLS implementation and 
(b) replace/update the renegotion with a secure
renegotiation for the OpenSSL-style architecture
and for the SSPI architecture, it seems that
the OpenSSL architecture is not so bad after all.

I have never looked at GGF.  Does it really create two
seperate, unrelated contexts similar to what SSPI does?

A while back, a vendor had his GSS-API mechanism certified
for interoperability with out application, and he told me
that this mechanism was built on top of OpenSSL.  I don't
know whether they have implemented renegotiation (I doubt it,
since that mechanism is not wire-compatible with native SSL
due to the GSS-API token framing.  But I could conceive
a renegotiation architecture without a seperate context
handle.

Maybe apps shouldn't be sitting straight on top of SSPI?
I'm glad we have our thin gsskrb5.dll between our own apps
and SSPI, because I had to work around several bugs and
backwards incompatible changes during the last 9 years,
and that additional abstraction helped me significantly
in the logistics of getting updates or workarounds
out to the customers.  Since we provide gsskrb5.dll
as OpenSource, customers could even do that themselves...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Nov 2009 21:21:46 -0600

>    Or, for that matter, the old GGF (Global Grid Forum) GSS-API

I've thought about this some more.  I think now that what I considered a
layering violation earlier today actually isn't.  A security mechanism
that takes an input channel binding, removes the channel binding type
prefix then splits the remainder into two octet strings, with each
end-point sending one half, is actually conformant to RFC5056.

Therefore I have no further objections, and, for now, no further
comments.

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Fri, 06 Nov 2009 09:26:07 +0000

* Nikos Mavrogiannopoulos:

> issue.

I'm not sure.  We've got a middleware which provides RPC services over
TLS with certificates on both ends, and it happens that we're
vulnerable as well[1], even though we require client certificates from
the start.  Suppose that there is an RPC which is some sort of store
operation, allowing reading back the stored data by the client.  The
attacker pre-loads half of such an RFC call, triggers renegotation,
and splices this connection to an unsuspecting client.  The client
will complete the RPC call, the server will save the call contents
(including metadata) as the payload of the store request that precedes
it, associated with the attacker's certificate (because it sticks to
the certificate it saw first).  The attacker can use the service to
read back the saved call contents, gaining access to data it would not
ordinarily have access to.

Theoretically, this attack can be detected by the server, but not
using the APIs that are currently deployed.  You are right that HTTP
is worse, but based on the attack sketched above, the basic issue also
affects other services.

[1] We've got other safeguards which prevent actual exploitation in
our case, but the theoretical vulnerability is still there.

---

From: Bruno Harbulot <[email-masked]>
Date: Fri, 06 Nov 2009 15:46:54 +0000

Hello,

> command cache should have been cleared and reissued after negotiation.

I think you have a point, I'm not sure if it's HTTP as such that is to 
blame, rather the assumptions made by the frameworks implementing it.

Authentication via client-certificate in HTTPS has always been a bit at 
odds with the rest of the HTTP authentications schemes. HTTP has status 
codes for requiring authentication (401), but client-cert authentication 
doesn't fit well into this model. The need vs. want client-cert feature 
itself isn't handled particularly well by browsers. Requiring a 
client-cert (and closing the connection if one isn't presented) can be 
confusing to the user.

I think the problem comes from the fact that SSL/TLS is intended to 
behave transparently, like normal sockets, for the application using it, 
whereas this issue is clearly not the case when re-negotiation happens. 
Perhaps this should just be another special case handled by the 
application layer (the other special case I have in mind is the way 
closing the socket behaves slightly differently to normal sockets).

This attack could be prevented if the HTTP framework was notified when a 
renegotiation had happened and thus made aware that the command it just 
got may not have been made with the same credentials.
For example, this wouldn't be an issue if:
- the HTTP method sent just before the renegotiation was a safe method 
(GET/HEAD)
- the HTTP application was using safe methods correctly (no GET 
/page?action=delete for example)
- if the HTTP method isn't safe (POST, PUT, ...), then send a 401 status 
response. The problem here is that a 401 response status requires a 
challenge header according to the HTTP spec and there isn't one to 
require a client certificate; this being said, it should be possible to 
extend HTTP and have 'WWW-Authenticate: Transport' (or something 
similar) meaning that it's up to TLS to provide the required 
authentication information.

As you said, I also think handling this problem at the TLS level is 
cleaner since the assumption that TLS sockets behave transparently like 
normal sockets should still be valid in this case.

Best wishes,

Bruno.

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Fri, 6 Nov 2009 10:23:35 -0500

There's an example of using such abstract API in SNMPv3. Where it was also
debated ("IETF doesn't do API" :-), but the common sense prevailed.

-- 
Regards,
Uri         [email-masked]
<Disclaimer>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Nov 2009 09:59:11 -0700

> command cache should have been cleared and reissued after negotiation.

I tend to agree. Some folks in the XMPP community have analyzed the use
of TLS in XMPP, and their preliminary conclusion is that XMPP is not
vulnerable to this attack because the client and server are required to
clear the security context and restart the XML stream after TLS
negotiation (or renegotiation). Those who did this analysis will publish
a brief report about their findings in the near future.

Peter

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 18:13:44 +0100 (MET)

> blame, rather the assumptions made by the frameworks implementing it.

The ramification are amplificated by the HTTP 1.1 Connection:keep-alive
that allows pipelining of requests and results in asynchronous
processing of requests and replys.

For re-negotiations, the following requirement from
rfc5246 6.2.1. Fragmentation  (last paragraph):

   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.

Provides and interesting additional challenge, and documents that
at least some of the original protocol designers didn't sufficiently
reflect on the implications.

Similarly rfc-5246, 7.4.1.1. Hello Request

      Since handshake messages are intended to have transmission
      precedence over application data, it is expected that the
      negotiation will begin before no more than a few records are
      received from the client.  If the server sends a HelloRequest but
      does not receive a ClientHello in response, it may close the
      connection with a fatal alert.

I think it is underspecified what "interleaved application data
and handshake messages" and "handshake message have transmission
precedence over application data" is supposed to mean, and
what kind of signalling would be necessary between the
TLS protocol stack and the application caller in order
to convey the underspecified semantics unambiguously.

I wasn't remotely aware of the applicability for real world
scenarios beyond the command execution I suggested in my
description, when I wrote about an MITM attack scenario that
had briefly crossed my mind the night before, and for which
I had not found any indications in rfc5246 (scanning it for
about 20 minutes) that would stop it, before sending off the mail.

I had not realized that one could similarly proxy an initial TLS
handshake with a client into a renegotiate of the server and
things like the request-completion for the basic-auth based
or cookie-based authentications.

Marshs published research on the issue expanded my thinking about
susceptible scenarios significantly.  Excellent work, Marsh!
-- and thank you for all the research!

For the cookie-auth or basic-auth based scenarios depicted by
Marsh, the asynchronous processing of pipelined requests creates
interesting new opportunities.

"Clearing the command cache" might require a significant change
in some application protocol stacks.  In order to efficientl
process requests, and nowadays Connection: keep-alive pipelined
requests, there are often intermediate layers for the request
parsing that will combine and re-slice what comes out of
SSL, so that the application may efficiently process the
requests--including URL argument parsing, parsing the MIME-header,
parsing certain header fields (Host:,Cookie:,authorization)
and potentially code page translations/transformations.

When analyzing performance problems reported by a customer
3 years ago I noticed that their Apache reverse proxy 
(using SSL-reencryption into our backend software) was
tearing up the forwarded requests into pieces, forwarding
each line of the MIME-header of the request and the
empty newline into seperate SSL-records -- slowing down
the processing of the request significantly.

>From the original design, and in the two quoted paragraphs above,
it appears that SSL and its successor TLS was intended to be
_very_ transparent, and the spec contains guidance for
security-relevant signaling to the application only for
the initial TLS handshake on a connection (full initial handshake,
and session resume), but _NOT_ for the session renegotiation.

Therefore, I think, we do have a real shortcoming of the
SSL/TLS protocol, and we really should scramble to fix it.

That includes improving on the guidance for the signaling
and semantics of a TLS session renegotiate of the TLS
protocol stack to the application -- in a fashion so that
it can be folded back into rfc5246bis.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 11:23:23 -0600

This vulnerability will affect different application protocols
differently.  It certainly affects HTTP.  I think LDAP may not be
susceptible, but I'm not sure; I'm even less sure about IMAP.  Others
have indicated that there definitely exist other applications besides
HTTP which do suffer from this vulnerability though, and that's the key:
of course there may be more than one application protocol that is made
vulnerable by this TLS problem.

We must fix this problem in TLS itself.  The fix may require changes to
some applications, depending not so much on the protocol as on the TLS
API used.

Nico
--

---

From: Nathaniel W Filardo <[email-masked]>
Date: Fri, 6 Nov 2009 12:49:24 -0500

> some applications, depending not so much on the protocol as on the TLS

Forgive me if I'm mistaken, but as far as I understand (one of) the
attack(s), it relies on an application protocol (e.g. HTTP) request being
'fragmented' across the renegotiation (thus the need for, in HTTP, the
attacker-provided X-Swallow-This: header to absorb the client's GET)...

Is it in general sufficient for the server to initiate the reauthentication
only in response to a complete request?  Alternatively, in the case of HTTP,
is it sufficient to reject requests with client-provided headers (i.e.
anything except the GET/POST/... line) on the outer connection?  That is,
are there any clients which actually depend on being able to fragment
requests like this?

Just curious.  Thanks.
--nwf;

---

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

> attacker-provided X-Swallow-This: header to absorb the client's GET)...

I expect there will be others (far more skilled than I in the art of
HTTP abuse) improving on that in the coming days. Steve and I just
developed a few examples to demonstrate the severity of the problem.

This capability has been characterized as a "blind plaintext prefix
injection attack". I don't think many protocols have been designed to be
resilient against that kind of thing, those that are not vulnerable are
that way by accident. HTTP is particularly susceptible, but I'm sure
many more protocols will be found to be exploitable.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 12:59:00 -0600

> attacker-provided X-Swallow-This: header to absorb the client's GET)...

Sortof.  The problem is not that the application protocol _explicitly_
allows TLS re-negotiation in the middle of an application protocol
message.  I bet HTTP has nothing whatsoever to say about that.

The fact that HTTP does allow that folows from the fact that the
application protocol is layered atop TLS.

(I.e., this isn't about HTTP's/HTTPS' authors being bloody stupid.  Lots
of very smart people have been working in these fields without having
noticed this problem.)

> only in response to a complete request?  Alternatively, in the case of HTTP,

Necessary, but not sufficient.  You must also drop all prior context.
Alternatively you must bind the new TLS connection to the old, exactly
the proposed fix.  (Note that the proposed fix is even more independent
of application protocol design than the flaw.)

> are there any clients which actually depend on being able to fragment

The problem is that the HTTP implementation may have no knowledge of
what's going on at the TLS layer[*].  Yes, the HTTP implementation can
tell the TLS layer to re-negotiate, and it can find out what the user's
cert was afterwards.  But if the client initiates [re-]negotiation, the
HTTP server may have no idea that this is happening.  Worse, the TLS
protocol doesn't have any bits on the wire saying that "this is a
re-negotiation", so the client may merely be initiating the first
negotiation even though to the server that looks like a re-negotiation.

In an application protocol with a "starttls" style approach to TLS, this
unawareness of what's going on in the TLS layer can exist, even if it
seems inutitively less likely, but at least such an application protocol
can be constructed so that application messages that can fit in a TLS
record are never fragmented across TLS [re-]negotiations.  Not that
that's enough (see above).

[*] Look at it from a developer's point of view: the TLS API may look
    very similar to read(2) and write(2) system calls.  Applications are
    not normally aware of which reads and writes result in disk I/O (or
    TCP segments, or IP packets, or whatever).  The situation with
    respect to TLS can be quite similar, though just how similar will
    depend on each specific TLS API.

Nico
--

---

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

> update the draft to make that clearer?

Yes, unfortunately, the description is the honest and cold truth.

It's challenging to come up with something better.

Maybe the consequences of the suggestion to no longer talk to
SSL/TLS servers without that extension should be made more
explicit.

As correctly described in Marshs publication, the problem affects
all existing releases of the SSL and TLS protocol family.

I assume that this WG, the IETF, the vendors and the consumers would
appreciate if the fix could be applied to the entire installed base,
no matter what protocol level each component implements.

It's not always an option to move to a newer implementation that
also supports a more recent version of TLS, so I would appreciate
that we describe two additional things in this draft:

   - to describe how to add/implement this fix to each and
     every affected protocol version of the SSL/TLS Family.

     I just noticed that SSLv3 does _NOT_ have a "no_renegotiate" alert!
     To me, it looks like the SSLv3 spec does not specify how to
     deny performing a renegotiate.  Which is slightly odd, since
     there are SSLv3 implementations that do not implement renegotiation...

   - to describe/suggest the behaviour for implementations of SSL/TLS
     that do not support (or do not want to perform) renegotiation,
     in particular for SSLv3.

   - since we currently overload the empty extension with signaling
     to different things: 
       - I am a patched server
       - I support secure renegotiation

     we should probably explicitly describe what a TLS v1.x Server
     should do if it does not implement TLS renego in the server or
     reliably know that it will not perform renegotiation.
     Since it is against common sense that such a server responds
     with a TLS Extension "I support secure renegotiation" in
     the ServerHello, we should explicity write what we want them
     to implement.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 06 Nov 2009 11:55:06 -0800

>      there are SSLv3 implementations that do not implement renegotiation...

Even more importantly, SSLv3 does not support extensions.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 20:56:52 +0100 (MET)

> that we describe two additional things in this draft:

While the things just described do not (necessarily) change the
proposed wire-protocol, they might change semantics and
interoperability of the protocol exchange with ongoing
implementations.  Making handshakes with attackers fail
earlier during the handshake is not my concern, of course.

But aside from this proposal, I was never really happy with
the performance impact of the delayed client auth, because
a TLS renegotiation alwas incurs a full TLS handshake.

There used to be (I have not checked lately) a particularly
bad user experience when connecting a firefox (2.x) to
MS IIS6 on W2K3 configured in directory-level access permissions
(i.e. the configuration that results in delayed TLS client auth
 through renegotiation).  When MS IIS6 was configured to allow
client-cert based authentication plus HTTP-authenticate:Negotiate
or basic-auth, but the firefox browser did not have a client
cert (or the user did not want to send it), then the bug in
the MS IIS6 server-side session cache resulted in a renegotiation
on every new connection, which resulted in a certificate selection
popup.  This could result in several popups per page if you
were browsing regular web-pages in protected areas rather
than plain directories.

What I would have appreciated, and what could prevent this
nonsense, is an extension that signals from the client to
the server "You do not need to try a CertificateRequest on me,
I will not send you a certificate!".  If a browsers memorizes
the uses decision (to not send a cert, or that there is no cert),
then it would really help if it could tell this to the SSL/TLS
server right away, instead of requiring the server to wonder
and probe this information with a full blown TLS handshake
through TLS renegotiate.

I do _not_ want to get any improvement in this area get into
the way of fixing the "secure renegotiation" issue.

Well only if the implementors/vendors that are most affected
by the security problem propose/agree that we could add
such signalling here (plus TLS WG consensus, of course).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 Nov 2009 20:59:49 +0100 (MET)

> Even more importantly, SSLv3 does not support extensions.

You're correct.  SSLv3 allows extensions in the ClientHello that
are to be ignored, but it does not support them in ServerHello.

Oooops.

Suggestions?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 14:03:34 -0600

> are to be ignored, but it does not support them in ServerHello.

Stop using SSLv3.  Its end has arrived.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 13:47:09 -0600

> > arrived prior to authentication etc.

What is "Retrospective Trust"?  A search for that finds unrelated items.
A search for "Retrospective Trust security" finds restrospectives on
workshops and what not.

In any case, assuming that you mean that authenticating something said
earlier is bad, I disagree, provided that one actually does that (as
opposed, as in the case of this bug, merely thinking that one is
authenticating something already said but not really).

There are, in fact, a number of places in our protocols where we
authenticate something said earlier.  In many of those cases we have no
choice but to do that!  Consider TLS, SSHv2, IKv2, etcetera.  They all
start with an unprotected negotiation and key exchange, followed by an
exchange of messages that authenticates the unprotected negotiation
using the exchanged keys.  That's a matter of bootstrapping security,
yes, but that happens often.

> more daring things tomorrow -- and that could be things that

I don't think what the apps do, particularly HTTP, is bad at all.
What's bad is the lack of binding between the disparate TLS connections
that result.

What's so bad about deferring authentication of the user until after you
know that it's needed?  Nothing, _provided that_ you also ensure that
the request that required authentication came from the same entity that
you subsequently authenticated.

I think it's fair to say that folks using TLS expected the binding,
which we now know wasn't there, to be there -- or at least that they
intuitively expected such a binding, even if the explicit thought of it
never entered their consciousness.  They use a security tool, and as far
as they knew they used it correctly.  It is not their fault, but ours,
that we did not document the lack of this binding, or that we didn't
provide it to begin with (I'm using the royal we; I'm not to blame! :)

> use, the more often people will work around it.

What's the relevance of that here?  IIUC, you think delaying
authentication was purely for convenience, and that convenience is the
mother of all security bugs -- that convenience is almost a sin.  Right?
But if so, I don't agree.  Security features have to be convenient in
order to stand a chance of being used properly or at all.  That doesn't
mean that we should accept convenience over security, but that where we
can get both, we should.

> about who goofed which part.

In this case we need to improve the design, not the guidance.  Granted,
we could choose to not improve the design and rely only on guidance.
However, it's much better to make the problem just go away.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Fri, 06 Nov 2009 14:54:50 -0600

> A search for "Retrospective Trust security" finds restrospectives on

I think the term "retroactive authentication" is a bit better to
describe what HTTPS servers does for dynamic client certs.

> yes, but that happens often.

My feeling is that it is extra-tricky to get right, and any mistakes
seem to default to resulting in a security vulnerability. Seeing this in
some webserver code was one of the things that originally led me to the
problem.

However, I do not agree that the concept is fundamentally broken. After
all, signing a document at the bottom of a page is not worse than
signing it at the top. What you have to worry about is the possibility
that your signature on the last page may not cover all the pages in a
multi-page document. All the attacker may need in that case is a staple
remover.

> you subsequently authenticated.

That is a good point I think.

Even though the first session had an "anonymous" level of
authentication, that doesn't mean that the subsequent authenticated
session didn't need to authenticate the original request!

In this case, the client of that first anonymous session is implicitly
assigned an identity, but is not authenticated properly. He needs to be
authenticated as being "the same party as the client in this other session".

> never entered their consciousness.

The "binding" was effectively there in SSLv2 because it was guaranteed
that there was only one session. The SSLv3 spec quietly introduced the
concept of renegotiation and multiple sessions without ever addressing
the fact that this would translate into security vulnerabilities unless
every existing application changed its internal model for handling SSL
connections.

- Marsh

---

From: Robert Relyea <[email-masked]>
Date: Fri, 06 Nov 2009 13:40:21 -0800

> are to be ignored, but it does not support them in ServerHello.
In practice, there are too many servers that blow up even on extensions
in clientHellos. So many that NSS only uses extensions in TLS, not in SSL3.

There are some servers that claim to be TLS, that also fail to accept
extensions. To date we have treated those as TLS intolerant SSL 3.0
servers, since it's clearly incorrect behavior for a TLS server to just
barf on an extension.
> Suggestions?
For us, this means SSL3 would be dead in the case you require the extension.

bob

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 06 Nov 2009 14:17:53 -0800

> For us, this means SSL3 would be dead in the case you require the extension.

A server can still negotiate an SSLv3 connection as it does today.
It just can't re-negotiate that connection later.  This is true for
all TLS versions as well; you can still allow unpatched clients to
connect, just not renegotiate.  The servers impacted by this change
are those that require renegotiation to obtain client credentials.

Mike

---

From: Dean Anderson <[email-masked]>
Date: Fri, 6 Nov 2009 17:29:23 -0500 (EST)

> > I'll become a bit pedantic and note here that this isn't really a TLS

Its a TLS issue.  However I don't think we should worry too much about
https.  I've used client certificates on some websites, and let me tell
you, its really a non-starter to use renegotation because most
webservers have a 250k buffer (On apache this is a compile-time
constant) for renegotiation, which isn't big enough to complete a lot of
http transactions, anyway. As a result, one usually winds up breaking up
websites into two or more sites, with one site completely client
certificate controlled so that no renegotation necessary on that site,
and the rest of the content is on another site that also needs no
renegotiation.

> Theoretically, this attack can be detected by the server,

Theoretically, I think not. The problem (inherent to every MITM attack)
is that there is some plaintext the MITM can change or otherwise use.  
The solution is the same in every case: Eliminate the plaintext or
encrypt it in a (e.g public key) cipher so that the MITM can't alter or
read it.

That's what should happen here. We should not worry about whether this
is hard to program or not.  It simply shouldn't be plaintext.  I don't
think it ought to be too difficult to program, as the client and server
have already public exchanged keys that could be used to encrypt the
renegotiation.  

Of course, https is still as screwed as before, but like I said above,
it is of no consequence as there are already problems with renegotation
that cause renegotiation to be avoided. So we need not worry about
https.  But renegotiation should be made to work in TLS, as other
protocols that rely on TLS don't have the large, essentially unlimited
transaction size problems that https has.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494

---

From: "David Harrington" <[email-masked]>
Date: Sat, 7 Nov 2009 06:39:48 +0800

Hi,

I am one of the authors of RFC3411, and lead editor for the ISMS WG as
we added support for security protocols at lower layers. I was also
involved in the failed EOS WG (Evolution of SNMP) and SMING WG (next
generation SMI).

I was probably the strongest proponent of using abstract APIs
(actually ASIs - abstract service interfaces) to depict data flows
between parts of the system. 

Let me observe that those ASIs have made it almost impossible to
update the pieces of SNMPv3, because the ASIs act as design
constraints. The strong architectural model made it very difficult to
update the SMI without forcing changes to the ASIs. The strong
architectural model made it very difficult to update the operations
set of the SNMP protocol. Both of these efforts resulted in failed
WGs. Adding support for existing SSH security infrastructure took
three documents because we had  to modify the architecture, including
all the affected ASIs. What might have taken months to complete took
years - largely because of the use of ASIs in the architecture.

Many of the people who worked developed Netconf were involved in the
SNMPv3 architecture effort, and subsequent updates. Look at the
Netconf architecural model - it uses very simple, very nebulous
layering as the borders between portions, not ASIs. This is a
dramatically simpler and easier approach to work with.

I strongly advise you to be careful what you wish for. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Blumenthal, Uri - 0662 - MITLL
> Sent: Friday, November 06, 2009 11:24 PM
> To: Nicolas Williams; Marsh Ray
> Cc: [email-masked]
> Subject: Re: [TLS] TLS renegotiation issue
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 17:09:41 -0600

On Sat, Nov 07, 2009 at 06:39:48AM +0800, David Harrington wrote:

Of course, the issue here is not "must the IETF provide APIs?" but "can
the IETF provide APIs?".  The answer to that is a resounding "yes".

> architectural model made it very difficult to update the operations

I consider this a feature.  Not that I want to slow down development,
mind you.  Nor that I want to stay wedded to an ASI architecture that
turns out to be resistant to usefule changes.  Rather, changes to the
protocol should either be mindful of the abstract interfaces that have
been specified (i.e., the existing interfaces, possibly with extensions,
should continue to work), or they should introduce a replacement set of
interfaces.

> years - largely because of the use of ASIs in the architecture.

If the ASIs made it too hard to change the protocol in useful ways, then
the ASIs should be replaced.

> dramatically simpler and easier approach to work with.

I agree that it is dramatically simpler to write such documents.  I
don't agree that the result is necessarily better.  There's a whole
continuum of degree of formalism that we can use in our documents.  What
degree of formalism is best will depend on context (including who the
document authors and implementors are).  There will be contexts where
using XML schemas is useful, and ones where that would be overkill, for
example; replace XML with ASN.1/SDL/whatever.  There are contexts where
you want to use pseudo-code, or even actual source code to describe as
formally as possible, what must be done, while in other contexts "test
vectors", or just plain English language prose will do.

I think that abstract interfaces would be useful for TLS.  Most would
probably disagree.  If someday I get to be a TLS implementor, I may well
submit an individual submission I-D describing an abstract TLS API, and
maybe then I can convince the rest.  Until then I'm happy to be in the
minority, with some minor exceptions: I think it's important forthe base
TLS spec to speak of TLS connections, channel bindings for TLS
connections, and channel binding to TLS connections.

> I strongly advise you to be careful what you wish for. 

Thanks.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Fri, 06 Nov 2009 17:41:23 -0600

Michael D'Errico wrote:
> It just can't re-negotiate that connection later.

But on the server question:

There is a large, but unknown, group of sites that really depend on
being able to serve different requirements for client certs from the
same IP.

For example, one development tool widely used in the industry is MS
Visual Studio 2005. It provides a nice IDE for developing web apps
(among other things). It has wizards all over the place. One will
generate a "web service" project, another will make an installer for it.
This WS architecture frequently uses client cert authentication and IIS
provides features to map client certs to OS user accounts. There are
other client auth schemes in use, too, pretty much anything supported by
HTTP. Server certs are expensive (or require approval to obtain) so I
suspect it's very common to serve web service projects requiring client
cert auth from the same hostname and IP as a web site that does not.

Just making an argument for how important per-request renegotiation is
in some deployments.

My guess is that any patch introducing an (SSLv3 xor renegotiation)
requirement is likely to cause a bit of headache. Consider the
possibility that a developer has an app that he tests and works fine on
his machine. But once he installs his app on the production server, all
the sudden some mysterious subset of clients (those using SSLv3) will
stop being able to connect to some different service which shares the
same IP address. Trial-and-error troubleshooting causes puts the blame
on the developer.

We should consider the possibility that it could introduce more (and
more confusing) incompatibilities than just deprecating SSLv3 outright.

> This is true for
> connect, just not renegotiate.

I strongly suspect it also applies to many SSLv3 clients.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 17:47:58 -0600

> being able to serve different requirements for client certs from the

The simplest way to drop re-negotiation in web servers is this (based on
an idea by Nelson Bolyard):

 - start two instances of the web server, one on an alternate port
   number, with the same contents

 - the primary instance will accept TLS user authentication, but will
   not require it

 - the instance on the alternate port will always require TLS user
   authentication

 - neither instance accepts TLS re-negotiations

 - whenever the primary instance of the web server would request user
   authentication via TLS do this instead: re-direct to client to the
   same resource on the alternate port.

That's almost entirely automatic.  The only thing a webmaster must do is
pick a suitable port number for the instance that requires user
authentication.

The redirects will add some round-tripage.  They can be avoided somewhat
by re-writing URLs in contents served to point to the right server
instance.

Ugly, yes, but automatable.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 06 Nov 2009 16:20:10 -0800

> API-level changes, everything is completely internal to the

Having finished implementing the proposal, I can say that this is
a true statement.  No API changes were required.

Mike

---

From: Martin Rex <[email-masked]>
Date: Sat, 7 Nov 2009 01:28:00 +0100 (MET)

> a true statement.  No API changes were required.

Nico has drawn a raw sketch about SSPI (Microsoft schannel),
and that API will probably require a minor change.
I have not personal experiences with schannel, but from what
Nico described, I think a single new API function and slight
modification of the context iteration functions might
be sufficient (as discussed earlier postings).

CreateRenegoSecurityContext(prev_context, options, &new_context);

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 7 Nov 2009 01:40:04 +0100 (MET)

> in clientHellos. So many that NSS only uses extensions in TLS, not in SSL3.

I have no data and no experiences about interop issues with >SSLv3.

Networking or multimedia appliances might be the hardest to get
upgraded, although they're quite unlikely themselves to use
client-cert authentication, much less through renegotiation.

We shouldn't unnecessarily create interop-problems with them
(or force them to drop to plain http).

What exactly do you mean by "only uses extensions in TLS"?

TLS extensions must be asserted in the ClientHello, and a SSLv3 server
is expected to ignore them.

Are you rather referring to fallback/reconnect-heuristics in Browsers
that will automatically re-try a failed TLS-handshake with TLS extensions 
by a SSLv3 handshake without TLS extensions.  Which Browsers&Versions
do that, actually (I simply don't know)?

Such a fallback would certainly help, but is entirely an apps issue.
It is much less likely to be present in programmatic clients, I assume.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sat, 07 Nov 2009 00:00:29 -0600

Nicolas Williams wrote:
> That's almost entirely automatic.

> The only thing a webmaster must do is

Wow that does make it sound easy. All we need to do for HTTPS is get a
new port number assigned and the entire burden of the solution passes
from the TLS specs to server implementors and site admins?

Think of what this is proposing: all sites that currently depend on
renegotiation have to adjust their configuration. They have to
reconfigure their server's internal filters to allow the port. They have
to reconfigure their border firewalls to allow the new port. Every web
proxy device has to be reconfigured to support the new port. Web
applications that check for that magic number 443 will need to be
updated. We'll ignore reverse proxies and SSL offload for now.

Say only 5% of sites depend on renegotiation. OK, only 5% admins need to
reconfigure. Well, how well-tested is everything outside of those
admins' networks going to be? How well does the 5% case tend to work
end-to-end?

Every client-side filter that watches outbound connections has to know
what that new port is being used for. Non-browser client code has to be
reviewed and possibly rewritten because it doesn't necessarily follow
HTTP redirects. Same-origin policies for cookies have to be checked for
how they handle the redirect to the new port.

Suppose that some ecommerce retailer is sending free smart-cards and usb
readers to 500K of their best customers this year (I got one in the mail
a few years ago). These cards web-enabled! (I.e. they present client
certs under the hood.) Armies of young, energetic support people will
spend the best years of their careers explaining to end users how to
reconfigure their ZoneAlarm.

>  - neither instance accepts TLS re-negotiations

Oh yes, even with all that...you still need to update every web server
and client and TLS stack in the world!

> The redirects [] can be avoided somewhat

Oh my.

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 07 Nov 2009 10:01:42 +0200

> to convey the underspecified semantics unambiguously.

Actually as far as I remember this was the most tricky part of TLS (any
version) to implement in a sensible transparent way. Moreover the way I
have implemented it, although not so transparent, the application layer
cannot distinguish between the two sessions (one before renegotiation,
one after). The problem was for me that you could receive any amount of
application data even after a rehandshake was requested, thus I had to
cache them and present to the application after rehandshake was finished.

[...]

> it can be folded back into rfc5246bis.

I agree this part of TLS needs to become more clear in semantics and
more strict in specification. For example what has to be done by a
client if a handshake request was received. Currently some client may
ignore it. How long is the server going to wait to understand that it
was ignored and no reply is expected?

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Sat, 07 Nov 2009 02:30:31 -0600

Nikos Mavrogiannopoulos wrote:
> the application layer

Yes, yes!

The buffered stream IO model we all take for granted is insufficient to
represent the semantics of a TLS connection in the presence of
renegotiation!

Even with an added callback for cert validation, ambiguities linger!

I think it highly probable that real vulnerabilities exist in
applications due to this mismatch.

The draft-rescorla-tls-renegotiate extension should help quite a bit though.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 07 Nov 2009 08:59:32 -0800

> it is essentially free-for-all-uses IPR-wise).

Is there any issue with IPR?

Mike

---

From: Marsh Ray <[email-masked]>
Date: Sat, 07 Nov 2009 11:18:47 -0600

> Is there any issue with IPR?

It is my opinion that it is difficult to prove a negative statement, but:

* The proposed protocol extension is dirt-simple, possibly minimal even.

* The method used is similar to the public work on the channel bindings
(binding TLS session based on Finished message data).

* At the Sept 29 meeting, this same idea was proposed by several people
simultaneously.

* At the Sept 29 meeting, we made a clear statement of the expectation
for vendors to disclose any IP they thought might cover this. None
presented any.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 07 Nov 2009 09:52:47 -0800

> represent the semantics of a TLS connection in the presence of

My server works a bit differently; it does what I'll call "lazy
renegotiation."  If it receives a ClientHello for a renegotiation, it
calculates all of the response handshake messages and puts them into
the outbound queue for delivery to the client.  It will happily continue
sending application data to the client and also receiving and passing
application data back to the application while the pending TLS session
is in this uncompleted state.  I believe this is what the TLS spec
intended.

If the client continues with the handshake, those messages are processed
as they are received, and the pending TLS session moves closer to
completion.  It is possible for the client and/or server to end up with
two different active sessions -- one based on the renegotiation, and one
based on the original handshake.  This would happen if one side fails to
send a ChangeCipherSpec and Finished message.

So the question becomes: should this be a legal state to be in?  I could
add some logic to disallow the sending of application data over a newly-
installed renegotiated session until the peer has completed its side of
the handshake.  But it should probably be allowed to continue receiving
application data over the old session since it could have been in transit
prior to sending the Finished message.

I think a good addition to my API would be to have a callback that tells
the application when a renegotiation has completed, and to also pass back
any application data that was received under the old session, but not yet
read by the application.

There is another weird possibility that should probably be prohibited:
if for some reason a ChangeCipherSpec is received during a renegotiation,
but not followed immediately by a Finished message, the receipt of any
application data should cause a handshake failure.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 07 Nov 2009 14:00:49 -0800

> Does anyone have a public testserver up and running yet?

You can test against https://www.mikestoolbox.net or .org

If you run into problems, you can contact me off list at
mikestoolbox at pobox-dot-com.

Mike

---

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

> You can test against https://www.mikestoolbox.net or .org

I forgot to mention that in order to successfully renegotiate,
you will need to do it before sending the blank line that ends
the HTTP request.  This is because my server is not really an
HTTP server; it just spits out a diagnostic page after reading
the request.

The diagnostics will be of the last session negotiated.

Mike

---

From: Nagendra Modadugu <[email-masked]>
Date: Sun, 8 Nov 2009 12:51:58 -0800

SSL3 is still in wide use since it is not considered insecure (other than
the renegotiation issue).  Is it feasible to explicitly deprecate SSL3?  Or
state that renegotiation support for SSL3 is deprecated?

Here is the rationale.  Clients that have both SSL3/TLS1 enabled will send a
'mixed-type' SSL3/TLS1 ClientHello (i.e. Record.version = 3.0,
ClientHello.version = 3.1).  Such clients should, strictly speaking, not
include TLS extensions, which means that renegotiation should not be allowed
by the server regardless of the protocol version negotiated.  Considering
that a majority of clients will continue to support both SSL3 and TLS1 for
some time (as a practical matter), the new extension will not come into
effect unless clients (a) cease sending mixed-type ClientHello messages, or
(b) send TLS extensions even when Record.version = 3.0.

Option (a) leaves open the possibility for down-grade attacks (i.e. a MITM
blocks TLS1 connections, allowing clients to reconnect over SSL3 -- I recall
that atleast one major browser will attempt to reconnect over SSL3 if a
TLS1, or mixed-type handshake fails).  Option (b) requires extension support
to be "back-ported" to SSL3.

I suggest that the draft discourage the use of SSL3 entirely.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 8 Nov 2009 14:23:39 -0800

interesting point, but let me suggest another view:

The empty renegotiation extension used on an initial renegotiation says:

1. I support this extension.
2. This is an initial negotiation.

Now, it's not important to the server to know that the client supports the
extension. Any renegotiation without the extension is automatically
suspect. And the client can only use the lack of support to terminate
servers if it's willing to break almost all compatibility, in which case
TLS only isn't a problem.

This leaves us with the second purpose, but that's accomplished just
as well by having SSL3/TLS clients offer SSL3 client hello with the
TLS version number and then offering the extension on renegotiation
only.

Does that address your issue?
-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 8 Nov 2009 20:45:05 -0600

> it can be folded back into rfc5246bis.

"Signaling" --- sounds like an... API!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 8 Nov 2009 20:51:08 -0600

> Is there any issue with IPR?

The proposal is to, effectively, do channel binding.  Channel binding
goes back a long time, to the early 90s at least (see RFC1508, for an
example from 1993).  I know of no patents covering the technique.  Not
that I would -- I don't go looking for patents.  But so you know,
there's plenty prior art, going back a fair number of years.

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Nov 2009 07:41:46 +0000

* Dean Anderson:

> Theoretically, I think not.

I was referring to the sketched attack in the previous paragraph.  In
our case, the server could notice the changed client certificate in
the renegotiation and bail out, or disable renegotiation altogether.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 11:55:35 -0600

> from the TLS specs to server implementors and site admins?

[Complaints that new port numbers for this are not really feasible
elided.]

For services inside a firewall this would be simple enough.  For all
others one may split the public vs. for-authenticated-users services
across multiple IP addresses rather than port numbers; this is [much?]
harder to automate.

But you convince me that this is not realistic.  To properly automate
this would require... software updates, which is pretty much what we
need to fix the bug in the first place; if this workaround is not
automated, then it won't be deployed.  Must likely, as you say, the
world will sit in the vulnerable state for a long time.  Very
unfortunate, that.

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Nov 2009 15:34:49 -0800

It is likely XMPP is vulnerable.  IMAP and SMTP are vulnerable.  The only 
application protocol I've studied that I believe resists the vulnerability 
is POP3+STLS (even pops may be vulnerable).

I know of two ways to leverage the TLS re-negotiation vulnerability to 
attack applications:

1. Authenticating an otherwise un-trusted directive using credentials from 
an authorized user.  As far as I know this attack only applies to HTTP-like 
protocols (including IPP, SIP, HTTP, WebDAV, CalDAV, etc.) due to the poor 
design of HTTP authentication, cookie and client certificate mechanisms. 
Application protocols like IMAP, POP, SMTP, XMPP, BEEP with cleanly 
separate not-authenticated and authenticated states are immune to this 
attack.

2. Having one authorized and authenticated TLS session decrypt data from a 
different TLS session.  This attack is most severe for SMTP+STARTTLS+BDAT 
(since SMTP relays typically treat all senders as authenticated as long as 
the recipient is in the local domain), but impacts most application 
protocols that have a command to "send", "post", "put", "set an attribute" 
or perform any write operation that can subsequently be read back.  In the 
case of IMAP, this can be used by one authorized IMAP user (someone with an 
account on the IMAP server) to potentially steal the login password of 
another IMAP user on the same server (with some IMAP client behavior 
caveats).

It is likely that XMPP is vulnerable to attack #2.

I would recommend anyone running an SMTP relay (port 25) to turn off both 
the STARTTLS and SMTP AUTH features immediately until this is resolved.  An 
SMTP Submission server (port 587, RFC 4409, requires SMTP AUTH to submit 
mail) should keep STARTTLS enabled.  Sites that have not made the split 
between SMTP relay and SMTP submission should do so -- they have different 
security properties and this is yet another reason they should be different 
services (either on different ports or different IP addresses).

		- Chris

--On November 6, 2009 9:59:11 -0700 Peter Saint-Andre <[email-masked]> 
wrote:

> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr0Vd8ACgkQNL8k5A2w/vyeqQCgpzZakXwr62UdxAHdNyqwe4xe
> WEUAoMPGdY94w+/+oAv9oYC0I9iu7hnI
> =sjVM

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Nov 2009 15:41:11 -0800

--On November 6, 2009 11:23:23 -0600 Nicolas Williams 
<[email-masked]> wrote:
> susceptible, but I'm not sure; I'm even less sure about IMAP.

IMAP is susceptible (see my previous email).  I'm fairly certain LDAP is 
susceptible in two ways:

1. An authorized LDAP user with permission to set and read an LDAP 
attribute anywhere in the DIT can likely use the TLS renegotiation attack 
to steal another LDAP user's simple bind password.

2. If LDAP and another vulnerable service (e.g. SMTP+STARTTLS+BDAT, IMAP, 
etc) have server certificates with the same hostname, then an authorized 
user of one of those other services can steal another user's LDAP simple 
bind password.

		- Chris

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 11 Nov 2009 22:15:39 -0800

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

[= http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt]

There's pointless overhead in the following extract: Sending the  
client's verify_data to the server for verification makes sense;  
sending the server's verify_data to the client for verification makes  
less sense, but still sense; sending another copy of the client's  
verify_data to the client, however, doesn't make sense.  Using  
symmetric 12-byte values, where each party sends its own previous  
verify_data, achieves the same with fewer bytes.

Bodo

             struct {
                opaque renegotiated_connection<0..255>;
              } Renegotiation_Info;

    All TLS implementations SHOULD support this extension.  TLS clients
    SHOULD generate it with every handshake and TLS servers SHOULD
    generate it in response to any client which offers it.

    o  If this is the initial handshake for a connection, then this  
field
       is of zero length in both the ClientHello and the ServerHello.
    o  For ClientHellos which are renegotiating, this field contains the
       verify_data from the Finished message sent by the client on the
       immediately previous handshake.  For current versions of TLS,  
this
       will be a 12-byte value.  Note that this value is the "tls- 
unique"
       channel binding from [I-D.altman-tls-channel-bindings]
    o  For ServerHellos which are renegotiating, this field contains the
       concatenation of the verify_data values sent by the client and  
the
       server (in that order) on the immediately previous handshake.   
For
       current versions of TLS, this will be a 24-byte value.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 12 Nov 2009 20:44:09 +0200

Chris Newman wrote:

> 2. Having one authorized and authenticated TLS session decrypt data from
> a different TLS session.  This attack is most severe for
> SMTP+STARTTLS+BDAT (since SMTP relays typically treat all senders as
> authenticated as long as the recipient is in the local domain), but
> impacts most application protocols that have a command to "send",
> "post", "put", "set an attribute" or perform any write operation that
> can subsequently be read back.  In the case of IMAP, this can be used by
> one authorized IMAP user (someone with an account on the IMAP server) to
> potentially steal the login password of another IMAP user on the same
> server (with some IMAP client behavior caveats).

This attack is not obvious to me by this description. Can you please
elaborate?

regards,
Nikos

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Nov 2009 18:54:19 -0600

Comments:

1) The rest of this comment can be ignored if the use of protocol
   extensions in draft-rescorla-tls-renegotiate is deemed to not be a
   problem.

   I believe this problem can be fixed without using protocol extensions
   at all.  All that has to be done is this: for re-negotiations the
   Finished message computation changes from this:

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

   to:

    PRF(master_secret, finished_label,
	    Hash(handshake_messages || outer_connection_client_finished))
       [0..verify_data_length-1];

   where outer_connection_client_finished is the client Finished message
   for the previous/old/outer TLS connection

   There is no need to signal this!

   Either both, the client and the server will do this, or not do it, in
   which case the Finished messages will check out on both sides, or one
   will do it and the other won't, in which case the Finished messages
   will fail to check out on both sides.  If there's a MITM and the
   client and server both do this, then the MITM will be detected.

   I.e., channel binding is the solution, but there's no need to
   negotiate it -- the server wouldn't accept re-negotiation from
   clients that don't support the fix anyways.

   If there's no need to negotiate the fix, then there's no need to use
   Hello extensions.

   Also, this scheme allows both, the client and the server, to securely
   determine whether the other implemented the fix or not.  This is
   potentially a good or bad thing, depending on your point of view,
   since it allows for implementations to have an option to fallback on
   insecure behavior.

2) I believe the I-D, if the fix is not modified, should have the
   following INFORMATIVE text added:

   "
   This solution is akin to channel binding [RFC5056] using the
   'tls-unique-for-telnet' channel binding type
   [I-D.altman-tls-channel-bindings].  This is not a generic
   channel binding facility however.
   "

   RFC5056 and draft-altman-tls-channel-bindings-07.txt should be
   added as informative references.  (draft-altman-tls-... is currently
   listed as a normative reference.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Nov 2009 02:50:38 +0100 (MET)

>    There is no need to signal this!

If you do not signal, then your client will not be able to detect
whether it is talking to an old server, in which case the clients
initial handshake might still be proxied into the renegotiation
of that old server.

If there is a signaling in both directions available, and the
client does not receive an indicator in the ServerHello that it
is talking to an Updated Server, then it can never warn and offer
to not connect (some people seem to want that option).

Similarly, if you do not get a feedback in the ServerHello telling
you whether that server is an updated server or not, then your
client can not agree to an old insecure renegotiation (there
might be environments where the connectivity and possibility
to renegotiate is desired, and the MITM-susceptibility not
considered a problem.

If you want to provide the consumers those options, you will
need signaling.  When changing the calculation of the verify_data
of the finished messages for renegotiation, then the only information
that needs to be signaled is that the other side is updated.

Apparently there are some network monitoring folks that would like
to be able to distinguish patched from unpatched TLS implementations.
They might want signaling.

You could have the servers signal with the highest bit of the
protocol server_version in the ServerHello that they're using a
secured (i.e. different from the base protocol version) finished
message calculation for renegotiations, provided that the
client has indicated support for recognizing this modified
server_version in the ServerHello, indicating that the client
is actually talking to an updated server.

For TLS v1.3, the secure renegotiation Finished message calculation
could be made the default, and then it would no longer be necessary
to have the server modify its protocol version number for
protocol versions >=1.3.

Old clients would still get the old protocol version back
on the ServerHello.

Updated clients asserting the special ciphersuite ID would receive:

  server_version

  0x03,0x00     unpatched server, SSLv3 protocol, original finished calc
  0x03,0x01     unpatched server, TLSv1.0 protocol, original finished calc
  0x03,0x02     unpatched server, TLSv1.1 protocol, original finished calc
  0x03,0x03     unpatched server, TLSv1.2 protocol, original finished calc

  0x83,0x00     patched server, SSLv3 protocol, secure renego finished
  0x83,0x01     patched server, TLSv1.0 protocol, secure renego finished 
  0x83,0x02     patched server, TLSv1.1 protocol, secure renego finished  
  0x83,0x03     patched server, TLSv1.2 protocol, secure renego finished 

and in the future:
  0x03,0x04     new server, TLSv1.3 protocol, secure renego finished

If we're modifying the calculation for the finished messages for
the renegotiation handshake to include the verify_data of the
previous session, then this is a protocol change, and indicating
this in the protocol version of the ServerHello is _no_ abuse. :)

If the client wants to (a) still talk or somewhat dangerous (b) still
renegotiate in the unprotected traditional fashion with an old server,
it can do so, because it determine from the server_version in ServerHello
whether the server is patched and which Finished message calculation
the server will be using.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 14 Nov 2009 02:20:56 +0000

>    There is no need to signal this!

The problem is that this unnecessarily breaks cases in which the
possibility of attack couldn't have been prevented (because only
one of the client and server supports the extension), and in which
there may actually be no attack.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 14 Nov 2009 05:30:57 +0000

> there may actually be no attack.

No, on further consideration this argument is wrong. Since adding the
verify_data into the Finished hashes would only happen for renegotiations,
it cannot cause any interoperability failures on an initial handshake.
It would cause a handshake failure on a renegotiation, if only the client
or only the server has been patched.

Note that a handshake failure in that case doesn't necessarily result in
an interoperability failure. That's because many clients will fall back
to reconnecting on a new session, if a renegotiation fails. In fact,
implementors of web browser clients essentially have no choice but to
do this if they want to interoperate with many web servers (the situation
might be different for non-HTTP protocols) [*].

On the other hand, consider the case of a patched client performing an
initial handshake with an unpatched server. If an extension is not used,
then there is no way for the client to tell that the server is unpatched,
and the connection might succeed even though an attack is taking place.
Using the extension would give patched clients the option of refusing to
connect to unpatched servers.

The converse situation, where a patched server does not know whether it
is talking to a patched or unpatched client, is probably less significant:
an attack can only succeed in that case if the client does not check the
server's certificate, in which case a MITM attack is possible anyway.

Important point: TLS- or extension-intolerant servers are all unpatched.
If a client implementor considers it necessary to interoperate with
such servers, then that would not be consistent with a policy of refusing
to connect to unpatched servers. Suppose that we only use an extension
as an advisory of patched status (i.e. say that an empty extension SHOULD
be sent if patched), but add the verify_data into the Finished hashes
unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, the
concerns about extensions potentially breaking some servers, and the
concerns about lack of an extension potentially resulting in a security
weakness (due to a client being unable to tell whether a server is patched),
would only arise in mutually exclusive sets of cases.

[*] There is a corner case in which this argument might not apply --
    the "Step-Up" protocol, where old versions of the Netscape browser
    would initially offer only 40-bit ciphersuites, and then renegotiate
    to use a stronger ciphersuite if they see that a bit is set in the
    certificate. Such browsers are obviously unpatched, and will fail to
    renegotiate with a patched server that is using a Step-Up certificate.

    Note that "Step-Up" is different from "Server-Gated Cryptography"
    (SGC), in which the client never completes the first handshake and
    reconnects in a new session:
    <https://bugzilla.redhat.com/show_bug.cgi?id=533125#c24>
    SGC does not rely on renegotiation.
    (Verisign/Thawte sells certs that support both and does not
    distinguish between them; don't be confused by that.)

    Step-Up was a Netscape proposal, and SGC was from Microsoft.
    I don't think that Internet Explorer ever implemented Step-Up (as
    opposed to SGC). Netscape only implemented it in versions 3.x and
    4.x, which have numerous arbitrary code execution bugs that would
    be easier to exploit. So this is not a significant issue at all --
    any sites that are still using Step-Up certs, would be well advised
    to just patch their servers and tell their users to stop using such
    old browser versions.

---

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

> server's certificate, in which case a MITM attack is possible anyway.

Ah, but *if* the unpatched client does not properly check the certificate,
then the attack that is described here by Martin Rex:

<http://www.ietf.org/mail-archive/web/tls/current/msg03928.html>

would be possible only as a result of the renegotiation flaw; it is not
possible just using an ordinary MITM attack.

More specifically, the difference between this and an ordinary MITM is
that in the latter, the attacker cannot *both* control a prefix of the
session, and cause the server to be convinced that the client is
authenticated by a particular client cert.

The problem here is that if the server does not see the extension in the
ClientHello, and it chooses to break the connection in order to avoid the
possibility of the above attack, then it might be unnecessarily breaking
a connection with a patched client that was just unwilling to send the
extension.

Still, that's no worse than the situation with the current
draft-rescorla-tls-renegotiate. So I think that what I suggested:

> [...] only use an extension

is still an overall improvement.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 02:31:36 -0600

> there may actually be no attack.

That's a feature: for how do you know that "there may actually be no
attack"??

Either we fix the vulnerability, or we don't.  The only middle of the
road is a "ask the user if this is OK" (client-side) or "allow but log"
(server-side) temporary transition configuration.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 02:41:15 -0600

Right.

Right.

> connect to unpatched servers.

Irrelevant: nothing that goes over the first connection should be at
risk or sensitive, provided that the client did authenticate the server
OR, if an anon-anon cipher suite was used, (that the client refrained
from sending confidential data AND the client did not take destructive
action based on data from the server).

It's OK for the client to learn that the server is unpatched when it
tries to re-negotiate.

Right.

> Important point: TLS- or extension-intolerant servers are all unpatched.

Yes.  But I get the feeling that some folks think it will be easier to
patch them than to upgrade them.  My proposal is particularly useful
then, since it can be applied even to SSLv3.

NOTE: I'm not trying to force a design change at this late stage.  I had
      a caveat at the top of my proposal that it should only be
      considered if the use of extensions turned out to be problematic.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 14 Nov 2009 02:43:58 -0600

> is still an overall improvement.

I think that adding to my proposed fix an _optional_ signal in the
client's hello (and, correspondingly, in the server hello), would be
just fine.  I don't believe it's necessary.

Nico
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 14 Nov 2009 10:25:47 -0800

On 2009-11-13 21:30 PDT, David-Sarah Hopwood wrote:

>     reconnects in a new session: SGC does not rely on renegotiation.
>     opposed to SGC). 

I believe that's correct, and likewise, Netscape never implemented SGC.

> Netscape only implemented it in versions 3.x and 4.x, which have numerous
> arbitrary code execution bugs that would be easier to exploit.

I would add that Mozilla browsers use TLS code inherited from Netscape.
All the Netscape and Mozilla export browsers implemented Step-Up until
the U.S. export regulations changed in the year 2000.

> So this is not a significant issue at all -- any sites that are still
> using Step-Up certs, would be well advised to just patch their servers
> and tell their users to stop using such old browser versions.

I agree, emphatically.  But I have been told that there are still CA
selling step-up certs to this day, because there are still server admins
buying them, because there are still users in the world using those old
clients.  Given the premium prices historically obtained for Step-Up
certs, I'm not optimistic that CAs will voluntarily cut off sales of
their highest margin products for the good of a few users whose systems
are hopelessly vulnerable anyway.

/Nelson Bolyard
Developer of TLS code used in Mozilla and (formerly) Netscape clients

---

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

Nicolas Williams wrote:
>> an interoperability failure. [...]
> 
> Right.
> 

No, that's not correct. The client's session may have been prefixed by
data chosen by the attacker. Therefore everything sent in that session is
at risk.

This depends to some extent on the application protocol, but I would
expect almost all protocols to be potentially vulnerable -- although not
all implementations.

> It's OK for the client to learn that the server is unpatched when it

An attack can occur even against connections of a client that *never*
renegotiates, if it is connecting to an unpatched server.

> then, since it can be applied even to SSLv3.

The easiest patch is to just disable renegotiation. If you're going to
do anything more complicated than that, I don't think it makes any sense
at all to leave the server in a state where it is still TLS- or
extension-intolerant.

Note that we don't need such servers to support TLS; only to tolerate a
TLS ClientHello with extensions, and perform version negotiation correctly
for whatever version(s) they do support.

>       considered if the use of extensions turned out to be problematic.

Yes, that also applies to my suggestion of adding in the Finished hashes
unconditionally for renegotiations, and treating the extension as
advisory. It would be helpful to know to what extent implementors of
commonly used clients actually still think that it is problematic to use
extensions on an initial handshake. (For HTTPS, it would be particularly
interesting to know what Internet Explorer's behaviour would be once it is
patched.)

---

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

> just fine.  I don't believe it's necessary.

So we differ on whether sending signals in the hello messages is a "MAY"
or a "SHOULD". Here are the key-word definitions from RFC 2119:

# 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
#    definition is an absolute requirement of the specification.

# 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
#    may exist valid reasons in particular circumstances to ignore a
#    particular item, but the full implications must be understood and
#    carefully weighed before choosing a different course.

# 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
#    truly optional.  One vendor may choose to include the item because a
#    particular marketplace requires it or because the vendor feels that
#    it enhances the product while another vendor may omit the same item.
#    An implementation which does not include a particular option MUST be
#    prepared to interoperate with another implementation which does
#    include the option, though perhaps with reduced functionality. In the
#    same vein an implementation which does include a particular option
#    MUST be prepared to interoperate with another implementation which
#    does not include the option (except, of course, for the feature the
#    option provides.)

Since this can affect security and not just functionality, I think that
SHOULD is clearly appropriate here (but MUST is not).

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 11:28:57 -0800

> That's a feature: for how do you know that "there may actually be no

In general, you don't -- but sometimes you don't care.

TLS is often used for opportunistic encryption (such as between SMTP  
servers that in many cases have no way to verify each other's  
certificate): If the client and server can encrypt, they'll do it to  
get protection at least against passive attackers; otherwise, they'll  
just fall back to unencrypted transmission.  It would be a shame to  
have protocol negotiation problems make them fall back to unencrypted  
mode, when the currently deployed protocols could give them the  
security they expect.

Bodo