Re: [TLS] RFC 4507bis

Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> Wed, 01 August 2007 16:45 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHKD-0003Qy-8b; Wed, 01 Aug 2007 12:45:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHKB-0003Qj-SS for tls@ietf.org; Wed, 01 Aug 2007 12:45:27 -0400
Received: from relay1.mail.uk.clara.net ([80.168.70.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGHK9-0003Qi-FL for tls@ietf.org; Wed, 01 Aug 2007 12:45:27 -0400
Received: from [149.254.200.222] (helo=[10.36.234.32]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from <lists@drh-consultancy.demon.co.uk>) id 1IGHJu-0003Vk-Qk; Wed, 01 Aug 2007 17:45:14 +0100
Message-ID: <46B0B88D.5000909@drh-consultancy.demon.co.uk>
Date: Wed, 01 Aug 2007 17:45:01 +0100
From: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: Mike <mike-list@pobox.com>
Subject: Re: [TLS] RFC 4507bis
References: <AC1CFD94F59A264488DC2BEC3E890DE5043F329D@xmb-sjc-225.amer.cisco.com> <46B09C2B.70609@pobox.com>
In-Reply-To: <46B09C2B.70609@pobox.com>
X-Enigmail-Version: 0.95.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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

Mike wrote:
> 
>>>    - Is it legal for the server to resume a session
>>>      and not provide a NewSessionTicket?  The message
>>>      flow I'm referring to would look like this:
>>>
>>>      Client                                    Server
>>>      ClientHello
>>>      (SessionTicket extension) -->
>>>                                           ServerHello
>>>                          (no SessionTicket extension)
>>>                                    [ChangeCipherSpec]
>>>                                <--           Finished
>>>      [ChangeCipherSpec]
>>>      Finished                  -->
>>>      Application Data          <->   Application Data
>>>
>>>      If this is not allowed, it should probably be
>>>      stated that when a server resumes a session using
>>>      a SessionTicket, it MUST send an empty Session
>>>      Ticket extension and a NewSessionTicket message
>>>      (optionally with an empty ticket).
>>>
>> [Joe] It is legal to not provide a new session ticket if you do not
>> provide an empty session ticket extension from the server. However if
>> you include an empty session ticket extension from the server you must
>> provide a NewSessionTicket message (which may be empty).  Some other
>> reviewers have had similar comments, is there a place where the text
>> could be clearer?
> 
> The message flow diagram in the draft that shows session
> resumption has the server send an empty SessionTicket
> extension.  If the message flow above is also allowed
> (where no SessionTicket extension is sent by the server),
> then I think you should include the diagram in the spec.
> 

I agree that some clarification is needed in that case. I wasn't aware
of a special meaning for an empty ticket in a NewSessionTicket message
either so an explicit mention of that would be helpful.

One other area I'd like clarified is in 3.4:

>    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. 

I'm assuming this means that if the server accepts the ticket then it
MUST repond with the same Session ID present in ClientHello (which would
mean it MUST be empty if ClientHello Session ID is empty).

One alternative reading of that would be that the server can send an
empty Session ID if it accepts a ticket even if the ClientHello Session
ID is not empty.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

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