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

[Badra <[e-mail]>]

On Wed, Nov 30, 2011 at 8:23 PM, Martin Rex <[e-mail]> wrote:

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

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.



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


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

Best regards,
Badra