Re: [TLS] New Cached info draft

Martin Rex <mrex@sap.com> Wed, 31 March 2010 19:47 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 527573A6A7E for <tls@core3.amsl.com>; Wed, 31 Mar 2010 12:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.333
X-Spam-Level:
X-Spam-Status: No, score=-8.333 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8]
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 GGhPrZ+3gwHu for <tls@core3.amsl.com>; Wed, 31 Mar 2010 12:47:05 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0CBA93A6A75 for <tls@ietf.org>; Wed, 31 Mar 2010 12:47:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2VJlSVm010961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 21:47:28 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003311947.o2VJlRQP004852@fs4113.wdf.sap.corp>
To: brian@briansmith.org (Brian Smith)
Date: Wed, 31 Mar 2010 21:47:27 +0200 (MEST)
In-Reply-To: <003501cad0f6$2b4c3fb0$81e4bf10$@briansmith.org> from "Brian Smith" at Mar 31, 10 12:18:18 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: tls@ietf.org
Subject: Re: [TLS] New Cached info draft
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: Wed, 31 Mar 2010 19:47:06 -0000

Brian Smith wrote:
> 
> Marsh Ray wrote:
> > 
> > I think in this case it's saying there can be a maximum of 1024
> > entries in the list, each of which can take up to 9 bytes
> > (with a one byte length). So the receiver of this structure
> > is only obligated to store (or ignore) (2 + (1 + 8)*1024)
> > bytes of data.
> 
> No, Mike is right and I was wrong; <1024> means "1024 bytes",
> not "1024 entries".

While Marsh explanation sounded quite reasonable to me,
the implementors have a technical advantage of being more
accustomed to the TLS spec syntax for defining a vector size:

http://tools.ietf.org/html/rfc5246#section-4.3

> 
> Is 1024 bytes is an appropriate limit? Maybe not. First, I think we should
> discuss whether/why it is sub-optimal to cache just the most recently
> received value of each information item. Then I think it would become clear
> whether or not it makes sense for the client to send dozens or hundreds or
> more hashes in its ClientHello.

Allowing a client to cache (and to propose) more than one value per type
makes cache management more complicated, but whether a single item is
sufficient appears to depends on several aspects.  One of the aspects
is the exact connection parameters that the clients uses as a lookup
key into his cache.

If the lookup key is only the server/target hostname, then one would need
more than one entry/value in order to support multiple servers on
a host.  If the lookup key is server:port, then one might still need
more than one entry/value if client certs with different characteristics
are used (while it is possible to use an RSA client cert with every
ciphersuite and every kind of server certificate, ECC client certs
can only be used when they share characteritics with the servers ECC cert
and that requires the use of ECC ciphersuites).

TLS-enabled Web-Servers that host several different "zones" of information
with different access policies and using TLS renegotiation to request
zone-specific client-cert authentication could potentially use
zone-specific list of "trusted CAs".  Such a scheme may interact
badly with TLS session caching, though (i.e. incur a full handshake
everytime an access to a different zone is performed from a client.


> 
> 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.


-Martin