Re: [TLS] Wrapping up cached info

Martin Rex <> Tue, 25 May 2010 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD1FD3A6E2D for <>; Tue, 25 May 2010 06:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.445
X-Spam-Status: No, score=-7.445 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b0fqPXn0Meer for <>; Tue, 25 May 2010 06:47:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B18073A6BF9 for <>; Tue, 25 May 2010 06:47:15 -0700 (PDT)
Received: from by (26) with ESMTP id o4PDkw3r003247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 15:46:59 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Brian Smith)
Date: Tue, 25 May 2010 15:46:57 +0200 (MEST)
In-Reply-To: <003201cafac0$9a75d9c0$cf618d40$> from "Brian Smith" at May 23, 10 04:40:41 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] Wrapping up cached info
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: Tue, 25 May 2010 13:47:16 -0000

Brian Smith wrote:
> Stefan Santesson wrote:
> > I will, provided that this seems acceptable still in a few days from now,
> > write up a new draft that captures the changes which then hopefully can be
> > ready for a WGLC.
> 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.