[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] New Cached info draft
From:       Stefan Santesson <stefan () aaa-sec ! com>
Date:       2010-04-01 0:38:50
Message-ID: C7D9A9AA.9CAC%stefan () aaa-sec ! com
[Download RAW message or body]

On 10-03-31 8:47 PM, "Martin Rex" <mrex@sap.com> wrote:

>> 
>> I can see that it might be useful for the client to cache one value of each
>> cached information item that were obtained during initial (unauthenticated,
>> unencrypted) handshakes plus another set of values per client certificate
>> that were obtained during renegotiation following client authentication.
>> However, in that case, the server probably wouldn't want the client to leak
>> the hash of its second certificate in subsequent initial (unauthenticated,
>> unencrypted) handshakes. It seems something about this should be added to
>> the security considerations of the draft.
> 
> 
> Interesting, I hadn't thought of this aspect.  I think that the
> caching extension (update of client cache, proposal of cached values)
> should apply to all full handshakes, which includes TLS renegotiations,
> this will likely make hashes from data exchanged on a confidential
> rengotiation handshake visible on new in-the-clear handshakes.
> 
> 
>> 
>> If there are other cases where it seems useful to have the client send
>> multiple hashes for the same information item, then those cases should also
>> be discussed before publication so that the security properties of that
>> those kind of usages can be analyzed. For example, I think it is a big
>> privacy problem to send a digest of a value obtained from one server to
>> another server.
> 
> I mainly see a privacy problem for the client, similar to HTTP-Referers:
> or the browser cache.  Maybe a "Cache considerations" sections would
> be appropriate.

I'm still not sure what the threat is.

The client only gives away digest values. In order to know what data these
hash values represent, the "attacker" reasonably needs access to the cached
data.

I can't think of anything useful or serious the attacker can do with this.

/Stefan




[prev in list] [next in list] [prev in thread] [next in thread]