Re: [TLS] Wrapping up cached info

"Brian Smith" <brian@briansmith.org> Thu, 27 May 2010 15:38 UTC

Return-Path: <brian@briansmith.org>
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 40A1A3A6960 for <tls@core3.amsl.com>; Thu, 27 May 2010 08:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_66=0.6]
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 OvxT8XFBbnpN for <tls@core3.amsl.com>; Thu, 27 May 2010 08:38:28 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 381453A6950 for <tls@ietf.org>; Thu, 27 May 2010 08:38:28 -0700 (PDT)
Received: from T60 (unknown [70.245.69.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B1547509DA; Thu, 27 May 2010 11:38:11 -0400 (EDT)
From: "Brian Smith" <brian@briansmith.org>
To: <mrex@sap.com>
References: <003201cafac0$9a75d9c0$cf618d40$@briansmith.org> from "Brian Smith" at May 23, 10 04:40:41 pm <201005251346.o4PDkvJT024708@fs4113.wdf.sap.corp>
In-Reply-To: <201005251346.o4PDkvJT024708@fs4113.wdf.sap.corp>
Date: Thu, 27 May 2010 10:38:09 -0500
Message-ID: <000301cafdb2$9f59f800$de0de800$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHPr9DNi55j7moazUDWaBpt75m2CQMEn5zqAjgegDw=
Content-Language: en-us
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
X-BeenThere: tls@ietf.org
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." <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: Thu, 27 May 2010 15:38:33 -0000

Martin Rex wrote:
> Brian Smith wrote:
> > There's another issue still. If the server sends the client an
information
> > item X after the change cipher suite message, then the client must not
send
> > a hash of that information item in its client hello message on another
> > connection, until it has verified the identity of the server on that
second
> > connection. In other words, the client must ensure that it doesn't leak
> > information that would otherwise be confidential--including even
certificate
> > messages and client certificate cipher suite messages that were received
> > over an encrypted connection.
> 
> I think that should be described in the Security Considerations that
> a client or client&server that perform renegotiation for the purpose
> of client identity protection may want to tag their cached values
> so that when that value was established on an encrypted handshake,
> it is not going to be proposed by the client on a successor
> plaintext handshake.

How would the server indicate this to the client?

Regards,
Brian