[TLS] Question on Stateless TLS Session Resumption

"Narayanan, Vidya" <vidyan@qualcomm.com> Sat, 13 January 2007 19:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oxv-0000UV-I2; Sat, 13 Jan 2007 14:54:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oxu-0000UO-Lk for tls@ietf.org; Sat, 13 Jan 2007 14:54:58 -0500
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5oxs-0005i7-A6 for tls@ietf.org; Sat, 13 Jan 2007 14:54:58 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0DJst3O016513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <tls@ietf.org>; Sat, 13 Jan 2007 11:54:55 -0800
Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0DJssDZ021105 for <tls@ietf.org>; Sat, 13 Jan 2007 11:54:55 -0800
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 11:54:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 13 Jan 2007 11:54:54 -0800
Message-ID: <C24CB51D5AA800449982D9BCB90325133C9A2E@NAEX13.na.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Question on Stateless TLS Session Resumption
Thread-Index: Acc3TLHsrx0WXtswTt28sO/OoPUYjQ==
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: tls@ietf.org
X-OriginalArrivalTime: 13 Jan 2007 19:54:54.0881 (UTC) FILETIME=[B21FA910:01C7374C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc:
Subject: [TLS] Question on Stateless TLS Session Resumption
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

All,
RFC4507 makes no mention of ticket replays at all, which I find to be a
bit surprising. It actually doesn't talk about message replays either,
but, since the protocol takes 1.5 RTs,  both parties prove to be live
and so, that is not a problem. But, ticket replays seem to be of some
concern. Based on the fact that the ticket contains a timestamp, using
which expiry can be determined, it appears that a given ticket will be
accepted until its expiry time, even if a newer ticket may have been
issued after that. This itself is not so much a problem, since, the
client really has no incentive in using an older ticket as opposed to
the latest one. However, if a new ticket is either not issued or if the
session is terminated by the server for some reason, this seems to be a
problem. Since there is really no means of ticket revocation or any
server state on the status of a ticket, there seems to be no way to
determine that the client is not supposed to be using that ticket to
resume a session. Also, the fact that the client is allowed to pick a
Session ID makes it infeasible to track a terminated session that must
not be allowed to resume. 

Am I missing something? Has this been talked about before? 

Vidya

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