Subject: Re: [TLS] Thoughts on the protocol and backward-compatibility (was: Server-only solution - proposed text)

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 16:55:00 -0600

Kyle Hamilton wrote:
> 
> I still want the ability to negotiate using an ephemeral suite, and
> only then (in the
> protected-from-eavesdropping-but-not-yet-authenticated channel) offer
> the certificates.

I don't see anything wrong with that in principle (but it doesn't do
what you want, see below). In practice you may end up retroactively
authenticating the anonymous data that was sent earlier. Whether or not
that's ever a valid thing to do was a key point that went unspecified in
the SSLv3 and TLS specs.

It seems that with a retroactive authentication scheme, otherwise minor
oversights usually result in exploitable security holes.

> In my view, this is a rather serious
> information-disclosure vulnerability in the original protocol, where
> the Certificate messages are sent before ChangeCipherSuite.

In theory, the client certificate is "public" info.

In practice, it has all kinds of things in there that admins would
prefer were encrypted.

> This is
> simply not possible without renegotiation.

Even with perfect server-initiated renegotiation, your scheme fails to
prevent MitM from getting the client certificate if he wants it.

> The TLS library has the ability to detect when application data has
> come in -- and one of the ways to mitigate this might be for the TLS
> library to maintain an additional flag

Keep in mind that each additional flag has the potential to double the
testing requirements for implementors.

- Marsh

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 24 Nov 2009 15:39:38 -0800

I'm aware that my proposal doesn't offer complete protection from an
MITM.  What it does provide is protection that the MITM can't see
what's there.

Now, if instead of presenting the certificate, it provided the public
key and proof that the public key matches the private key that it has,
then the channel would be 'bound' to that public key.  The proof of
the keypair could also include a nonce that the client has to respond
with, with its own keypair.

Once the channel's bound to a first-order identity (the public/private
key pair), then it can be authenticated via CA-issued certificates
that contain the same public keys in use.  (Really, I prefer protocols
that have "perfect forward secrecy", but TLS seems to have been built
without that concept in mind, as far as the certificate presentment
and usage goes.  It might be useful to present a certificate and
validate it inside the channel, without having to deal with a full
handshake -- allow the server to send ServerCertificate at any time,
and then validate it, without changing any of the channel parameters.)

I think that it was decided not to do anything like this because it
increases the number of round trips on the network, though I don't
think the number of asymmetric operations would necessarily go up
(client still needs to verify the key that the server provides, and
client still needs to verify the certificate that the server provides
-- and the same for the server, it needs to verify the key that the
client provides and the cert that the client provides).  I'm not
certain, though, because I wasn't on the list at that point.

I just want to make sure that renegotiation is still supported,
because I need that function.  So, I offer my ideas on how to signal
the server that the client knows how to use a modified Finished
handshake.  The only downside is that it takes some kind of extension
to signal the client that the server knows how to do it, too. :P

-Kyle H

On Tue, Nov 24, 2009 at 2:55 PM, Marsh Ray <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 24 Nov 2009 14:14:53 -0800

On Tue, Nov 24, 2009 at 12:43 PM, Marsh Ray <[email-masked]> wrote:
> [email-masked] wrote:
>> Earlier Eric noted that if no application data is exchanged between the
>> initial and renegotiation handshake (i.e. no application data is sent
>> using the 1st session), this would be safe even without protocol
>> changes. Should this be included in this section, too?
>
> In order for that scenario to be 'safe' we would need to find some
> language in the TLS spec, there since the beginning, which says that an
> application MUST NOT attribute any semantics to the successful
> authentication of the remote party. I don't believe the spec has any
> such language.
>
> There is probably some application out there which interprets a
> connection from an authenticated client (or to an authenticated server)
> as an "event" with real semantics.
>
> Using SSH as an analogy, sometimes a login shell is set to, say, a
> backup program. Commands get launched when the user authenticates.
>
> Back with TLS, Microsoft IIS, for example, has a
> client-certificate-to-user mapping facility. It's certainly possible
> that the connection from such authenticated clients could trigger
> certain "non-idempotent" activities, even if just adding false log records.
>
> - Marsh

I still want the ability to negotiate using an ephemeral suite, and
only then (in the
protected-from-eavesdropping-but-not-yet-authenticated channel) offer
the certificates.  In my view, this is a rather serious
information-disclosure vulnerability in the original protocol, where
the Certificate messages are sent before ChangeCipherSuite.  This is
simply not possible without renegotiation.

The TLS library has the ability to detect when application data has
come in -- and one of the ways to mitigate this might be for the TLS
library to maintain an additional flag to prevent any application data
from being sent out or accepted while a (re)negotiation is taking
place.  (There's already a requirement that application data not be
sent with NULL-NULL-NULL, the initial state of the connection... and
the one value which is illegal to negotiate.)  If it does, the server
could fatal-alert either unexpected_value, protocol_error, or
insufficient_security.  (If a patched server *requires* that the
client be patched, insufficient_security or protocol_version would be
appropriate.)

Since there is already one magic value that must not be negotiated as
a cipher suite, there's precedent to use that mechanism... and since
this is a problem that affects all current versions of SSL3/TLS
implementations, it is important that we not change the semantics of
any of the messages that those implementations would normally see.
This means that we must use the only extension mechanism defined in
all SSL/TLS specifications -- the ability to add new cipher suites.
Because of this, I see no way to avoid adding a second "it is an error
if this suite is negotiated" tag to the cipher suite list.

Thus, I support the idea of using a new magic value in the cipher list
to indicate that a client has been patched (with the patch including
"must not negotiate this cipher suite, but including it means that the
server knows that the client can do the new renegotiation semantics").
 I also support the idea of standards action with all due haste (once
things are agreed upon) to update TLS 1.0, 1.1, and 1.2 with new
semantics (and the Standards Action necessary to allocate a new cipher
suite tag), with a recommendation to also update SSL 3.0
implementations.  (SSL 2 is just bad in the first place, and I see no
reason to try to improve it.)

The only downside I see to this is the eventual possibility of
branches of the protocol like Limewire did... using magic strings in
what essentially amounted to the User-Agent string to identify extra
capabilities.  I believe that this problem is much more effectively
and efficiently solved using TLS Extensions, so I am loath to add any
additional magic values unless something else comes up that requires
additional *retroactive* changes to the protocols that need to be
signalled.

(Using a cipher suite tag essentially leaves the protocol untouched
for unpatched clients, and the workarounds on the server side ('no
renegotiation' or 'server-initiated renegotiation only') will still
work.  If a server demands that the client be patched, I've discussed
above what the appropriate response would appear to be, to my eyes
(based on the definitions in RFC 5246 -- I haven't looked at earlier
versions).)

Once the signal has been sent by the client that it has been patched,
both the patched client and server implementations could then branch
into a different Finished calculation.  I do like the idea of adding
the hash from the last Finished message that the client sent --
initial state as all bits off -- to a renegotiated Finished handshake
calculation.  Since a client is not considered authenticated until the
server has verified that the certificate is valid, the key to that
certificate is held by the entity at the other end of the connection,
and the ChangeCipherSpec and Finished messages check out... well,
there's no worry of a client being improperly authenticated and
triggering anything other than at most a 'bad login' attempt.  Though
I would prefer to see that one not be 'bad login' (since that could be
a non-idempotent action that, for example, locks the user account),
but 'attack detected'.)

I also support the creation of a Renegotiation Indication extension,
so that TLS servers that support extensions won't have to set a
connection-context flag during processing of the cipher list.  RI
should also include the magic cipher code, or even have its tag *be*
the magic 'patched cipher' code.

(I do hate special-casing code -- in this case, during the cipher list
processing, and then during the Finished message calculation -- but I
don't really see much of a choice if we want to maintain some limited
backward compatibility with the world that already exists, which the
AD has stated is a priority.)

-Kyle H

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Nov 2009 17:46:20 -0600

> MITM.  What it does provide is protection that the MITM can't see

That's insufficient.

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 01:20:52 +0100 (MET)

> reason to try to improve it.)

To me it looks like there is a serious problem with the current
approach of the magic cipher suite in TLS extension RI.

If you have an SSLv3 or TLS client with not fallback, then the most
common conservative approach for the widest interop is to _NOT_ use
TLS extensions.  So if that client sends only the magic cipher suite
but the server doesn't signal back -- you have a problem if the
server wants to use renegotiation.  If the server asks for renegotiation
then the client, not knowing about the servers status will conservatively
assume this is an old server.  What should it send on the renegotiate
request?  If it sends only the magic cipher suite in the renegotiation
ClientHello?  Then TLS extension RI requires the server to abort.
Send a ClientHello without the magic ciphersuite?  Then the server
will assume it is an attack and abort.

So what is the best thing for a conservative client to do?

Not to upgrade!

Keep it like it is and require the server to allow renegotiation
for backwards interop if the server really needs it.
The other solution is that the server operator reorganizes his
server so that he doesn't need renegotiation any more.

In most scenarios, renegotiation is a feature needed by the
server, not by the client.

If there was a fix for the renegotiation problem that worked
for all usage scenarios and protocol versions, then I would
risk adding that to our TLS implementation.  But we don't
use renegotiation, we only have it in the client because
some sites needed it.

I'm not going to risk shipping a patch that suddenly starts
sending TLS extensions in the ClientHello.  Our client has
never done that, and therefore we never needed fallbacks.

I would wait at least several month before thinking about a
change to the client with such a disruptive potential,
and let the others find out the problems.

Impairing the interoperability of a large amount of clients in order
to fix a problem of a small number of servers seems questionable to me.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 18:24:11 -0600

> MITM.  What it does provide is protection that the MITM can't see

No server-only fix can provide meaningful secrecy for the client
certificate.

It's the client that possesses the client cert that you want to protect,
right? Changes have to be made there, in addition to the server.

Will you still support servers which request the client cert on the
initial handshake? If so, all MitM has to do is to imitate the server
long enough to ask the client for his cert! Sure, he may not be able to
forge the Finished verify_data, but he doesn't have to. The client is
required by the protocol to transmit the cert, that's all there is to it.

If you don't care about clients supporting existing servers (admins are
scrambling to disable renegotiation as we speak) then you can make a
somewhat disruptive change so that clients can require to strongly auth
the servers before a server-initiated renegotiation asks them to supply
the cert.

Nothing stops you from writing such a client app today, it requires no
changes to the TLS spec. But this could have been done years ago by web
browsers if they had wanted to, but for whatever reason (most) https
client apps seem to treat the client cert handling as an afterthought.

I, too, think renegotiation is useful and worth saving. But it will take
 additional restrictions (at higher layers, not TLS) if you want clients
to be able to make their certs secret.

- Marsh