[TLS] RFC 4507bis

Mike <mike-list@pobox.com> Sun, 29 July 2007 16:56 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 1IFC4G-0007ZS-FI; Sun, 29 Jul 2007 12:56:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFC4E-0007QM-Nl for tls@ietf.org; Sun, 29 Jul 2007 12:56:30 -0400
Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFC4E-0008Vr-ES for tls@ietf.org; Sun, 29 Jul 2007 12:56:30 -0400
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 166672EF for <tls@ietf.org>; Sun, 29 Jul 2007 12:56:52 -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 sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id D95636A0FC for <tls@ietf.org>; Sun, 29 Jul 2007 12:56:51 -0400 (EDT)
Message-ID: <46ACC722.8080702@pobox.com>
Date: Sun, 29 Jul 2007 09:58:10 -0700
From: Mike <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc:
Subject: [TLS] RFC 4507bis
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

I'm working on adding support for RFC 4507 to my code
and have found a few issues with the draft.

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

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

   - It may be useful to state that the MAC computation
     in the ticket is over the encrypted contents to
     be able to quickly reject a ticket and not have to
     perform a decryption first.

   - Should HMAC-SHA256 be recommended instead of
     HMAC-SHA1?

   - StatePlaintext needs more data fields when TLS
     extensions are used such as max fragment length.
     This should be obvious, but it wouldn't hurt to
     state.

Mike

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