Subject: [TLS] TLS identity protection using Signaling Cipher Suite Value

From: Badra <[email-masked]>
Date: Thu, 17 Nov 2011 10:49:47 +0100

Dear TLS WG,

I posted a document that defines a pecial Signaling Cipher Suite Value to
enable the negotiation of the client identity protection. This approach had
been initially proposed by Francisco Corella, to the TLS mailing list
during August 2000.

http://www.ietf.org/id/draft-badra-tls-identity-protection-00.txt

Best regards
Badra

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Nov 2011 20:23:06 +0100 (MET)

> http://www.ietf.org/id/draft-badra-tls-identity-protection-00.txt

A signaling cipher suite value is certainly *MUCH* better than
the other proposal for a cartesian product of common ciphersuites.

Although performing negotiation of this capability through ciphersuite
values instead of a TLS extension would protect against a very simplistic
DoS attack against a TLS handshake between the rightful client and
rightful server using TLS extension (but only in case the client is
capable and willing to perform a reconnect fallback with an
extension-less ClientHello),
this approach can *NOT* protect against an active attacker that
is determined to learn the client's identity and does not
care about causing a failed TLS handshake while doing so.

As I previously mentioned, the only reliable protection during the
handshake would be an indication from the server that is authenticated
by the server credential an can *not* be stripped from the handshake.
Basically, it would need to be hardwired into the server's credential,
like an additional certificate extension or a new EKU OID.

The Finished MAC protection of the handshake contents can only protect
the application from using the resulting connection, it can not
protect the negotiation and use of protocol features _during_
the TLS handshake because modifications of the handshake by an
active MitM can only reliably be detected *after* the handshake when
verifying the finished messages.

-Martin

---

From: Badra <[email-masked]>
Date: Thu, 1 Dec 2011 00:01:42 +0100

> like an additional certificate extension or a new EKU OID.

As you previously mentioned too, hardwiring an new optional TLS protocol
feature into a TLS server certificate, resulting in potentially hard to
diagnose handshake failures.

Can in this case extend the ServerKeyExchange structure as follow:

struct {
    select (KeyExchangeAlgorithm) {
         case rsa:
             struct { } ;
         case rsa_scsv: // message is NOT omitted when SCSV is received
             struct {
                 digitally-signed struct {
                   opaque handshake_messages[handshake_messages_length];
                 }
             } ;
    };
} ServerKeyExchange;

handshake_messages refers to all handshake messages sent or received,
starting at client hello and up to, but not including, this message.

If the client doesn't receive such a message from the server, it must
stop the TLS handshake

It may be costly for the serer to sign this message for each handshake.
The server can, for every one day, sign the concatenation of SCSV code
and the day's date and send the result during every handshake that may
happen during that day.

> verifying the finished messages.

True, and this is applied to any feature supported by TLS

Best regards,
Badra

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 00:41:19 +2500 (MET)

Badra wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >

This "hard to diagnose handshake failures" refers only to client
implementations that would check for this server certificate attribute
and not sensible report to the user why the client implementation
aborted the handshake.  "old" clients who do not check the feature
would not abort.  Typical user reaction "but it works with Browser X!".

> If the client doesn't receive such a message from the server, it must

Of course, you could implement it as a client-side credential attribute
which says "never send in the clear", instead of negotiating the protocol
feature with the server.  That is not so much different from the server
conveying the info through a certificate attribute, just that it is
entirely up to the client whether an when it is being "enforced",
and the server has no say in that.  If the user tries to use such a
feature before the server has even implemented it, the user will
face a failure (and switch it off).  Who is going to reenable it
when the server adds the feature, then?  If the server could steer
this with a certificate attribute, this would provide a certain
level of synchronization and negotiation whether the feature is
available and can (or should) be used.

But in the longer run this might lead to multiple distinct client
credentials for different purposes in order to accomodate different
servers/services feature upgrade strategies, and at that point
the client may become identifiable for an MITM attacker that requests the
"low-protection" credential rather than the "high-protection" credential,
so you're back at square one...

> True, and this is applied to any feature supported by TLS

Correct.  This poses a certain risk to proposed features like
"TLS false start", where data may get sent prior to verification
of the server's finished handshake message on a full TLS handshake
so that it may be protected only by the lowest protection offered
by the client that an active MITM was able to force on the client.

-Martin