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
Date: Wed, 31 Mar 2010 21:47:27 +0200
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
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Kemp, David P.
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Simon Josefsson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Michael D'Errico
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Martin Rex