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