[TLS] RFC 5077 (was Re: draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted)

Michael D'Errico <mike-list@pobox.com> Fri, 19 February 2010 18:29 UTC

Return-Path: <mike-list@pobox.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 23D9428C1C2 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 10:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
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 PPWCEL8kdwte for <tls@core3.amsl.com>; Fri, 19 Feb 2010 10:29:48 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 00DA93A7FAC for <tls@ietf.org>; Fri, 19 Feb 2010 10:29:47 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BED529BB0A for <tls@ietf.org>; Fri, 19 Feb 2010 13:31:34 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=uCn0wXUIns5Y mRx13aRvAfpL/mY=; b=Dbr9KUGDQ77J+oXOYTOD85bRZmc92laOWFmC110/k3P1 RLR/EV+4bOZH2WRxT3+bNJkL52NQDQhIAYyLSumKn25JNlkGus8X+tJXkuWMKz+q usxEgEW0HMyuCGTRGnhWfHbddU/hhMPukwZoby7UdHP/qwLT3iL4LP5FySkoIHM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=HCNIeO Rk7aQXfoEkVcuWVwaFsF2+XzAmjJRoLfS5j5gm7cSdJNntmZfXrw+EQCy3rhmXG7 c4ke1/chlTGJFZ+HZ/KLb+1o1LQihAKqHZYPJj1obvSPJ34mlTTwWBdtGTLxtH1a QBiMBnD46DnoQKgZ9ihTPkOuv0MYEh8ALG4no=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B8D039BB09 for <tls@ietf.org>; Fri, 19 Feb 2010 13:31:34 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 45FE59BB07 for <tls@ietf.org>; Fri, 19 Feb 2010 13:31:34 -0500 (EST)
Message-ID: <4B7EDA36.2080801@pobox.com>
Date: Fri, 19 Feb 2010 10:36:38 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <C7A2FC2B.85D4%stefan@aaa-sec.com> <C7A30236.85DC%stefan@aaa-sec.com> <a84d7bc61002180831n412afe3aubffd4708a02b1dd3@mail.gmail.com> <4B7D8AAD.80204@briansmith.org>
In-Reply-To: <4B7D8AAD.80204@briansmith.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 0214B934-1D85-11DF-8DCF-D83AEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: [TLS] RFC 5077 (was Re: draft-ietf-tls-cached-info-02 / New "Fast-Track" 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: Fri, 19 Feb 2010 18:29:49 -0000

Brian Smith wrote:
> .... Note that this is how RFC50[77] works (you 
> have to infer what the server is saying based on what handshake messages 
> it skips; for example, if the server doesn't send a Certificate right 
> after its ServerHello then you have to infer that it's doing a 
> resumption based on the given ticket).

While that method works, an easier method is for the client to include a
non-empty session ID in its ClientHello when attempting to resume a session
based on a session ticket.  If the server does resume the session, then it
returns the client-generated session ID.  From RFC 5077:

    When presenting a ticket, the client MAY generate and include a
    Session ID in the TLS ClientHello.  If the server accepts the ticket
    and the Session ID is not empty, then it MUST respond with the same
    Session ID present in the ClientHello.  This allows the client to
    easily differentiate when the server is resuming a session from when
    it is falling back to a full handshake.  Since the client generates a
    Session ID, the server MUST NOT rely upon the Session ID having a
    particular value when validating the ticket.  If a ticket is
    presented by the client, the server MUST NOT attempt to use the
    Session ID in the ClientHello for stateful session resumption.
    Alternatively, the client MAY include an empty Session ID in the
    ClientHello.  In this case, the client ignores the Session ID sent in
    the ServerHello and determines if the server is resuming a session by
    the subsequent handshake messages.

Mike