Re: [TLS] New Cached info draft

Stefan Santesson <stefan@aaa-sec.com> Wed, 31 March 2010 18:21 UTC

Return-Path: <stefan@aaa-sec.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 DF63A3A6A4C for <tls@core3.amsl.com>; Wed, 31 Mar 2010 11:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.506
X-Spam-Level:
X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 NIgDtDLIgARN for <tls@core3.amsl.com>; Wed, 31 Mar 2010 11:21:52 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 102503A67B2 for <tls@ietf.org>; Wed, 31 Mar 2010 11:21:25 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 77766696F for <tls@ietf.org>; Wed, 31 Mar 2010 20:21:13 +0200 (CEST)
Received: (qmail 10745 invoked from network); 31 Mar 2010 18:21:05 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 31 Mar 2010 18:21:05 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 31 Mar 2010 20:21:04 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, tls@ietf.org
Message-ID: <C7D95F30.9C82%stefan@aaa-sec.com>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AQD3PCi3D0f3Jturskef2KINR30JKAHKu56TAa/xh04BZOPNv5OMiP/C
In-Reply-To: <003501cad0f6$2b4c3fb0$81e4bf10$@briansmith.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] New Cached info draft
X-BeenThere: tls@ietf.org
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." <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 18:21:55 -0000

I don't have a great use case where it is necessary to cache more than one
value per object type.

The closest I can think of is if there are two servers in a a cluster with
different server certificates.

I do however believe in the principle of not closing doors in standards
unless there is a well motivated reason to do so. Even if I can't think of
all good reasons to keep a door open, there might be more reasons discovered
in the future.

This standard offers future extensibility, so even if there are no reasons
to cache more than one value for current information object types, there
might be good reasons to do so for future defined object types.

The vector length defines the number of bytes and not the number of entries.
Each entry is 10 bytes (1 byte object type, 1 byte digest length, 8 byte
digest). 1024 bytes allows 102 digest values for various cached objects
types. I think this is more than enough.

I don't feel strongly about this limitation however.

Concerning security issues:
Fell free to suggest security considerations text. However I can't see any
integrity issues with advertising digest values of cached items so I don't
think we need to beat this horse to death.

/Stefan


On 10-03-31 6:18 PM, "Brian Smith" <brian@briansmith.org> wrote:

> Marsh Ray wrote:
>> On 3/31/2010 10:52 AM, Michael D'Errico wrote:
>>> I haven't been able to totally keep up with the progress of this draft
>>> or to follow the discussion, but I think it's a bad idea to
>>> artificially limit the size of anything to 1024 bytes.
> 
>> 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.
> 
>>> If somebody wants to use small fixed-size buffers, then they can check
>>> the length of the vector to see if it will fit.  If it won't fit, then
>>> they have to deal with it somehow.
>> 
>> What ends up happening in the absence of a defined limit is that products
> will
>> either be subject to a DOS, or different limits will be imposed by
> different
>> products which harms interoperability.
> 
> Also, there are interoperability problems with fragmented ClientHellos so
> the pragmatic total maximum size of a ClientHello is 2^14 bytes.
> 
> 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.
> 
> 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.
> 
> 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 think the author, Stefan Santesson, seems to know of some cases where
> caching more than one value is useful. Stefan, it would be very helpful if
> you could explain when it would be sub-optimal to send only one value per
> information item in the ClientHello, and when/why it is not a
> security/privacy problem to send a hash to a server that hadn't previously
> sent you the value from which that hash was created.
> 
> Regards,
> Brian
>