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

From: Mohamad Badra <[email-masked]>
Date: Fri, 2 Dec 2011 13:09:44 +0100

On Wed, Nov 30, 2011 at 12:41 AM, Martin Rex <[email-masked]> wrote:

> Badra wrote:
> >
> > Martin Rex <[email-masked]> wrote:
> > >
> > > 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.
>
> 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
> > stop the TLS handshake
>
> 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.
>

Shall be the server's indication authenticated? (i.e. the client's
indication is not authenticated)

Best regards
Badra