IETF Logo Mail Archive

Re: [TLS] First TLS cached information draft posted

Simon Josefsson <simon@josefsson.org> Wed, 10 June 2009 16:02 UTC

Return-Path: <simon@josefsson.org>
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 1BA3D3A6A02 for <tls@core3.amsl.com>; Wed, 10 Jun 2009 09:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6]
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 fNddDVScntqa for <tls@core3.amsl.com>; Wed, 10 Jun 2009 09:02:12 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 0092A3A6831 for <tls@ietf.org>; Wed, 10 Jun 2009 09:02:11 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5AG21FE010283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2009 18:02:03 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Min Huang <huangmin123@huaweisymantec.com>
References: <001901c9e999$05678bf0$909a1b0a@china.huawei.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090610:tls@ietf.org::tbKi6xhW+E6gw7+O:iGe
X-Hashcash: 1:22:090610:huangmin123@huaweisymantec.com::jvOqNz1VH2/lVyT6:8NYe
Date: Wed, 10 Jun 2009 18:02:00 +0200
In-Reply-To: <001901c9e999$05678bf0$909a1b0a@china.huawei.com> (Min Huang's message of "Wed, 10 Jun 2009 14:59:38 +0800")
Message-ID: <87bpowaxhj.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 16:02:13 -0000

Min Huang <huangmin123@huaweisymantec.com> writes:

> Hi,Simon
>
> This "heuristic" determination works well in most scenarioes, 
> but the client still be confused in some specific cases.

Hi.  Yes.  I don't like TLS implementations playing guessing games on
the intended interpretation of received data, though, and that is my
primary concern with this document right now.  I'm wondering how other
implementers feel about this, is it acceptable?

> I think adding a type-specific tag as you mentioned is a doable
> method, and it can solve the problems by now.
>
> And if we will construct a type-specific tag, the new "datasize" 
> field in CachedInformationHash is still necessary? It seems not 
> necessary any more. It can be a policy conformed by the client 
> when caching data or sending a CachedObject.

Right.

/Simon

v2.23.0 | Report a Bug | By Email