Re: [TLS] Wrapping up cached info

"Brian Smith" <> Thu, 27 May 2010 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B05B3A6B1C for <>; Thu, 27 May 2010 09:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jjtw9SKwiOnx for <>; Thu, 27 May 2010 09:02:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28D9B3A6982 for <>; Thu, 27 May 2010 09:02:42 -0700 (PDT)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DD02B509DC; Thu, 27 May 2010 12:02:31 -0400 (EDT)
From: "Brian Smith" <>
To: "'Stefan Santesson'" <>, <>
References: <003201cafac0$9a75d9c0$cf618d40$> <>
In-Reply-To: <>
Date: Thu, 27 May 2010 11:02:29 -0500
Message-ID: <000401cafdb6$032063d0$09612b70$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHPr9DNi55j7moazUDWaBpt75m2CQGJ0qXpAs36B9Y=
Content-Language: en-us
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: Thu, 27 May 2010 16:02:43 -0000

Stefan Santesson wrote:
> Could you explain why?
> What is the attack scenario?

Here are some issues I have come up with regarding this extension:

1. If the server went through the trouble of establishing a secure channel
before sending an information item, then doesn't that mean that the server
wants that information item to be kept confidential? If the client sends an
unencrypted hash of a confidential information item to the server, then it
creates an opportunity for known-plaintext attacks on that information item.
In particular, this would negatively affect any server that authenticates
the client and then renegotiates with its "real" certificate and/or other
handshake information.

2. Let's say you go to site A and cache site A's cert list. Then you send a
hash of that to site B. Then, site B can use that hash to recognize that the
user has previously been to site A. This if an information leak very similar
to the HTTP referrer header. For this reason, clients must be careful not to
send a hash of an information item to any site other than the one that sent
it to them. But this creates a problem, since the client hello happens
before authentication. This is worse than TLS session IDs and TLS session
tickets because both of the TLS session resumption mechanisms can be done in
such a way that it is impossible to map a session ID/ticket to the source
3. Let's say that a server generates a unique trusted CA list record for
every new session. Then the client's hash of the trusted CA list will act
like a HTTP cookie, much like TLS session IDs and tickets. Clients will have
to ensure that they clear their cached info cache similarly to the way they
clear HTTP cookie caches and TLS session caches.


> On 10-05-23 11:40 PM, "Brian Smith" <> wrote:
> > Stefan Santesson wrote:
> >> I will, provided that this seems acceptable still in a few days from
> >> write up a new draft that captures the changes which then hopefully can
> >> ready for a WGLC.
> >
> > There's another issue still. If the server sends the client an
> > item X after the change cipher suite message, then the client must not
> > 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
> > connection. In other words, the client must ensure that it doesn't leak
> > information that would otherwise be confidential--including even
> > messages and client certificate cipher suite messages that were received
> > over an encrypted connection.
> >
> > Regards,
> > Brian
> >