Re: [TLS] First TLS cached information draft posted

Min Huang <huangmin123@huaweisymantec.com> Wed, 10 June 2009 06:57 UTC

Return-Path: <huangmin123@huaweisymantec.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 616F53A6A15 for <tls@core3.amsl.com>; Tue, 9 Jun 2009 23:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 CHVnmZz3aFDb for <tls@core3.amsl.com>; Tue, 9 Jun 2009 23:57:00 -0700 (PDT)
Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 6A3F33A659C for <tls@ietf.org>; Tue, 9 Jun 2009 23:57:00 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KL00085CGN17R10@hstga02-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:57:01 +0800 (CST)
Received: from h00104745 ([10.27.154.144]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KL000CBIGMXQI10@hstml01-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:57:01 +0800 (CST)
From: Min Huang <huangmin123@huaweisymantec.com>
To: stefan@aaa-sec.com
Date: Wed, 10 Jun 2009 14:56:57 +0800
Message-id: <001801c9e998$a58b4b40$909a1b0a@china.huawei.com>
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-index: AcnpmKU3A6jU6q9xQxOJfsECPeRUeQ==
X-Mailman-Approved-At: Wed, 10 Jun 2009 06:20:29 -0700
Cc: tls@ietf.org
Subject: Re: [TLS] First TLS cached information draft posted
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, 10 Jun 2009 06:57:01 -0000

Hi, Stefan

You said:
"1) Is it allowed to send over multiple CachedObject elements
containing the same type identifier?
Proposed answer = No (you can already include multiple hashes 
for each type)"

It means that the number of the cached certificate is one or 
it means the hash values of all cached certificates are contained 
in one CachedObject of the same type?


regards,
Min




>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I think I have to try to clarify this

The client send a cached_information extension which contains a list of
CachedObject structures.

Each ChachedObject element contains:

- type identifier (CachedInformationType type)
- a list of hash values (CachedInformationHash hashes)

Each CachedInformationHash contains:

- Algorithm identifier (HashAlgorithm hash)
- Hash value (opaque hash_value)



There are a number of issues that need to be specified or clarified in the
draft:

1) Is it allowed to send over multiple CachedObject elements containing the
same type identifier?

Proposed answer = No (you can already include multiple hashes for each type)


2) What should the server return in its server hello message for each
acceptable CachedObject?

Alternative 1 = The CachedObject element, exactly as it was received by the
client (with all hashes)

Alternative 2 = The CachedObject element, but only containing the
CachedInformationHash elements that is recognize and support.

Proposed answer = Alternative 1 (This allows the server to say YES in
principle without analyzing the hash values at the time of Hello exchange)


3) Is the server REQUIRED to honor its support of a CachedObject by
replacing the identified handshake data with a received hash?

Proposed answer = NO (for reasons raised by Martin)


4) What does the server send as replacement for the replaced handshake data?

Proposed answer = One opaque hash_value (without hash type identifier) that
was received by the client, which MUST contain a valid hash over the
replaced data.



Do you agree?

/Stefan