Re: [TLS] First TLS cached information draft posted

Martin Rex <Martin.Rex@sap.com> Tue, 16 June 2009 15:29 UTC

Return-Path: <Martin.Rex@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 D237D3A6AFF for <tls@core3.amsl.com>; Tue, 16 Jun 2009 08:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 7IqnRCGZPht7 for <tls@core3.amsl.com>; Tue, 16 Jun 2009 08:29:22 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CAC283A691F for <tls@ietf.org>; Tue, 16 Jun 2009 08:29:21 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n5GFT1Il016501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 17:29:01 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200906161529.n5GFT0iP007243@fs4113.wdf.sap.corp>
To: stefan@aaa-sec.com
Date: Tue, 16 Jun 2009 17:29:00 +0200
In-Reply-To: <C65D8260.2A79%stefan@aaa-sec.com> from "Stefan Santesson" at Jun 16, 9 05:09:52 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: huangmin123@huaweisymantec.com, 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
Reply-To: martin.rex@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: Tue, 16 Jun 2009 15:29:22 -0000

Stefan Santesson wrote:
> 
> This CachedObject stucture may contain any number of hashes. This might be
> hashes using different algorithms over the same object or it may be hashes
> of the same kind over different objects (e.g. multiple acceptble certs). It
> is just an unordered list of hashes.
> 
> The server now takes the data it intended to send. And compute the hash over
> that data with as many algorithms it can out of the algorithms used by the
> client. If one of the received hashes matches one of the generated hashes,
> the match is accepted and the server will return one of the matching hashes
> as acceptance of the cache (data replacement).

To me, this sounds more complex that I think it should be.

I think the server should neither have to compute and neither have
to check the hash values for all hash algorithms for which the client
sent hashes. (which implies that the client has to send hash
values consistently for all items and all hash algorithms that
it wants to offer.

The server should reply in the ServerHello extension for which items
and which hash algorithm (of those poposed by the client) it supports
substituting the real data with the replacement (the hash
value in the current proposal).

The server should not have to compute and compare multiple hash
values over the real value when composing the handshake message
affected by the diet, and neither should the client have to
compare the substituted value to the hash values of more than
one hash algorithm (when the client proposed multiple values
for the same item with different hash algs.


-Martin