Re: [TLS] Wrapping up cached info

Nicolas Williams <Nicolas.Williams@oracle.com> Thu, 27 May 2010 16:17 UTC

Return-Path: <Nicolas.Williams@oracle.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 80E813A6AEE for <tls@core3.amsl.com>; Thu, 27 May 2010 09:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.829
X-Spam-Level:
X-Spam-Status: No, score=-4.829 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 QfmMDtOob6kP for <tls@core3.amsl.com>; Thu, 27 May 2010 09:17:34 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 553FF3A6B36 for <tls@ietf.org>; Thu, 27 May 2010 09:17:32 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RGGxkd021366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 16:17:05 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RB8Cdw010503; Thu, 27 May 2010 16:16:57 GMT
Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 303122421274977011; Thu, 27 May 2010 09:16:51 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 09:16:51 -0700
Date: Thu, 27 May 2010 11:16:45 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Brian Smith <brian@briansmith.org>
Message-ID: <20100527161645.GU9605@oracle.com>
References: <003201cafac0$9a75d9c0$cf618d40$@briansmith.org> <201005251346.o4PDkvJT024708@fs4113.wdf.sap.corp> <000301cafdb2$9f59f800$de0de800$@briansmith.org> <20100527154717.GQ9605@oracle.com> <000501cafdb7$1ee6b8c0$5cb42a40$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000501cafdb7$1ee6b8c0$5cb42a40$@briansmith.org>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090207.4BFE9B06.016C:SCFMA4539811,ss=1,fgs=0
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
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: Thu, 27 May 2010 16:17:44 -0000

On Thu, May 27, 2010 at 11:10:21AM -0500, Brian Smith wrote:
> Nicolas Williams wrote:
> > > How would the server indicate this to the client?
> > 
> > There's no need for the server to indicate anything to the client here.
> > 
> > If a client wouldn't attempt user authentication w/o re-negotiation then
> > it shouldn't send a hash of its user cert / cert chain in the initial
> > handshake.  If a server considers user cert TAs to be confidential
> > (highly unlikely, but let's suppose) then the server shouldn't list
> > their hashes in initial handshakes.  It's that simple.
> 
> AFAICT, that wouldn't stop a compliant (to the current draft) client from
> sending the hashes. Even if the server previously indicated that it didn't
> support the extension and/or didn't support caching certain information
> items, a complaint (to the current draft) client is still allowed to send
> those hashes:

The client can do stupid things, of course.  The point is to have text
that says "the client MUST NOT" do stupid things.

Neither the client nor the server should send all their cached hashes on
initial handshakes.  For one, that could be an enormous amount of
useless data.  Only possibly-relevant cached object hashes should be
exchanged.  The "possibly-relevant" part includes the consideration of
whether a cached object is relevant to initial vs. re-negotiation
handshakes.  I don't think we need to change the protocol to get this
right; at most we'll need to add text about this.

Nico
--