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
- [TLS] RFC 4507bis Mike
- Re: [TLS] RFC 4507bis jwkckid1
- RE: [TLS] RFC 4507bis Joseph Salowey (jsalowey)
- Re: [TLS] RFC 4507bis Mike
- Re: [TLS] RFC 4507bis Dr Stephen Henson
- Re: [TLS] RFC 4507bis Dr Stephen Henson
- Re: [TLS] RFC 4507bis Mike