Re: [TLS] RFC 4507bis

Mike <mike-list@pobox.com> Wed, 01 August 2007 14:42 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 1IGFPK-00055Z-7A; Wed, 01 Aug 2007 10:42:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFPJ-00055N-AM for tls@ietf.org; Wed, 01 Aug 2007 10:42:37 -0400
Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFPH-0000Im-L1 for tls@ietf.org; Wed, 01 Aug 2007 10:42:37 -0400
Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 4980D1158EF for <tls@ietf.org>; Wed, 1 Aug 2007 10:42:57 -0400 (EDT)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 8C4A21158B1 for <tls@ietf.org>; Wed, 1 Aug 2007 10:42:56 -0400 (EDT)
Message-ID: <46B09C2B.70609@pobox.com>
Date: Wed, 01 Aug 2007 07:43:55 -0700
From: Mike <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] RFC 4507bis
References: <AC1CFD94F59A264488DC2BEC3E890DE5043F329D@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5043F329D@xmb-sjc-225.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc:
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

>>    - Should the NewSessionTicket message be included
>>      in the hash used to create/verify the Finished
>>      message.  I believe it should since it's a
>>      handshake message, but it's not stated anywhere.
>>      I think it would be a good idea to specifically
>>      state that it is.
>>
> [Joe]It is part of the TLS hello message and is therefore included in
> the finished message.  This is part of the TLS extensions spec.  I'm not
> sure we need to clarify it here.

I was referring to the NewSessionTicket message sent by
the server to the client just before ChangeCipherSpec.
I think you should state that it is included in the hash
used to create/verify the Finished messages.

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

> [Joe] I was under the impression that most people were OK with
> HMAC-SHA-1 use for the foreseeable future.  If this is not the case we
> can probably change it to HMAC-SHA-256.

I will leave that up to the experts to decide, but will
use SHA-256 in my code in any case.

Mike

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