Re: [TLS] Handshake not under protection

Martin Rex <mrex@sap.com> Mon, 21 December 2009 19:49 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD303A692A for <tls@core3.amsl.com>; Mon, 21 Dec 2009 11:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level:
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdIv3TxLhP6N for <tls@core3.amsl.com>; Mon, 21 Dec 2009 11:49:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D5A5C3A68C3 for <tls@ietf.org>; Mon, 21 Dec 2009 11:49:24 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBLJn5FU000289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 20:49:05 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Mon, 21 Dec 2009 20:49:04 +0100
In-Reply-To: <4B2FCE60.3020507@extendedsubset.com> 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 virwal08
X-SAP: out
Cc: ravi@findravi.com, tls@ietf.org
Subject: Re: [TLS] Handshake not under protection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Dec 2009 19:49:26 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > Marsh Ray wrote:
> > 
> >> At the TLS level, it's possible for the current session to be
> >> anon-anon-DH, which provides no protection.
> > 
> > And which rfc-5246 requires to _not_ request a client certificate:
> > 
> >    7.4.4.  Certificate Request
> > 
> >    When this message will be sent:
> > 
> >        A non-anonymous server can optionally request a certificate from
> >        the client, if appropriate for the selected cipher suite.
> 
> The client cert is requested in the renegotiating handshake, not the
> initial one.  An anon-anon-DH session provides no "protection" for the
> client cert passed in renegotiation.
> 
> But it probably makes some people feel more secure to not see the
> details (usernames, emails, phone numbers, street addresses) flying by
> on the wire.

OK.  You are correct.

That provision in 7.4.4. is about the _current_ handshake only
and refers to the fact that a server has sent a "Certificate"
message prior to CertificateRequest.  Since at the point of
the handshake, the Server is _not_ authenticated.  There could have
been a certificate path validation of the server certificate,
but there is no proof yet, that the alleged server knows the
necessary private key to the presented certificate, so this
restriction in 7.4.4. does not provide security.


-Martin