Re: [TLS] Handshake not under protection

Martin Rex <> Mon, 21 December 2009 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBB303A6842 for <>; Mon, 21 Dec 2009 14:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1HSSNie6-aAi for <>; Mon, 21 Dec 2009 14:49:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2F8A3A6930 for <>; Mon, 21 Dec 2009 14:49:15 -0800 (PST)
Received: from by (26) with ESMTP id nBLMmuBb008245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 23:48:56 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Date: Mon, 21 Dec 2009 23:48:55 +0100
In-Reply-To: <> from "Marsh Ray" at Dec 21, 9 01:37:04 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: Re: [TLS] Handshake not under protection
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Dec 2009 22:49:16 -0000

There seems to be a slight confusion based on me quoting only part
of Marsh' reply, and not the part the confirms the technical possibility
of client identity protection (below).

I confirmed that the restriction in rfc-5246 7.4.4. Certificate Request
"A non-anonymous server can optionally request a certificate from the client"
can not protect against server that wants to elicit a "Certificate"
message from TLS clients in order to reveal the identity of these clients.

> I have seen common recommendations to have the server ask for it by
> renegotiation, as if that were a secure solution.

Correct.  This will protect client identies only from purely
passive observers/attackers.

> > The client certificate itself is sent with whatever protection the
> > record layer currently applies (non on an initial handshake) without
> > any kind of additional protection in a Certificate message from the client
> > to the server if the server includes a CertificateRequest message
> > between ServerHello and ServerHelloDone.
> > 
> > At that point, the Server is _not_ authenticated. The server has
> > already sent his "Certificate" message (containing the server certificate),
> > but that could be fake.  Only when the TLS handshake succeeds, the
> > client knows that the provided server certificate wasn't fake
> Yep.
> > -- and
> > at that point the application could decide whether it wants to
> > reveal its identity to that authenticated server through TLS
> > renegotiation.
> There are several significant points during the handshake that seem to
> require special application-layer processing. Rarely do we see one
> callback implemented perfectly, much less for two handshakes!
> > Client identity protection through renegotiation _can_ be used in
> > a secure fashion.
> It could be done securely if the application layer specified its
> operation thoroughly.
> HTTPS does not, I wonder if any do?
> > There is no guidance in the TLS spec how to do it,
> > though, and most existing clients are willing to send a client
> > certificate in any handshake.
> That's my point exactly.

OK.  How about this characterization then:

Although it's technically possible to implement client identity
protection securely with the existing protocol, it is so significantly
underspecified that it makes it unlikely that even those clients
which care about this, implement it in a secure fashion today.