Re: [TLS] Question on Stateless TLS Session Resumption

Lakshminath Dondeti <ldondeti@qualcomm.com> Sun, 14 January 2007 02:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5vY8-0002k1-Oe; Sat, 13 Jan 2007 21:56:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5vY6-0002jr-QG for tls@ietf.org; Sat, 13 Jan 2007 21:56:47 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5vY5-0000Yn-Et for tls@ietf.org; Sat, 13 Jan 2007 21:56:46 -0500
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0E2uhjp031602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Jan 2007 18:56:44 -0800
Received: from [10.50.76.70] (qconnect-10-50-76-70.qualcomm.com [10.50.76.70]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0E2ugoZ005801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Jan 2007 18:56:43 -0800
Message-ID: <45A99B9E.8060208@qualcomm.com>
Date: Sat, 13 Jan 2007 18:55:26 -0800
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
User-Agent: Thunderbird 2.0b1 (Windows/20061206)
MIME-Version: 1.0
To: EKR <ekr@networkresonance.com>
Subject: Re: [TLS] Question on Stateless TLS Session Resumption
References: <C24CB51D5AA800449982D9BCB90325133C9A2E@NAEX13.na.qualcomm.com> <863b6eh9v5.fsf@raman.networkresonance.com> <45A973A0.4000105@qualcomm.com> <86irfafo3j.fsf@raman.networkresonance.com>
In-Reply-To: <86irfafo3j.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

No disagreements, just clarifying below:

Eric Rescorla wrote:
> Lakshminath Dondeti <ldondeti@qualcomm.com> writes:
> 
>
> 
> Yes, as I said there are *two* issues. One issue is about what
> happens when a client simply initiates a full handshake. In
> that case there is no general need to invalidate an old ticket.
> TLS is quite capable of having two parallel sessions between any
> pair of communicating parties.

This and key separation between sessions etc., are quite clear and there 
are no issues there.
> 
> However, as you indicate, you might want to explicitly terminate
> a session. As Vidya indicated, this requires server side state,
> though less than a session cache would require.

Right, this is what I was pointing out as "difficult" (for some degree 
of difficulty :) ).  Either we need more state or more state plus some 
more computation to invalidate a ticket (I am thinking a hash 
computation), if the identity (session id) is not fixed.  Yes, I took a 
quick at the relevant portions of the paper you cite, but that analysis 
assumes that there is a session id and assumes that the server has a 
blacklist of invalidated sessions.

In any event, I understand this better now.  Thanks for the clarifications.

regards,
Lakshminath


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls