Re: [TLS] RFC 4507bis

jwkckid1@ix.netcom.com Sun, 29 July 2007 17:40 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 1IFCkW-00073e-Do; Sun, 29 Jul 2007 13:40:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCkU-00073U-Tz for tls@ietf.org; Sun, 29 Jul 2007 13:40:11 -0400
Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFCkT-0000xg-Ee for tls@ietf.org; Sun, 29 Jul 2007 13:40:10 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=k/XuzXZNDvQ73bQ1y/cBeMvtlpJZZJJAW58ijOC9AqsfW5UVz/0Axdi6mYR3TwY5; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.49] (helo=elwamui-sweet.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IFCkQ-0002rP-6k; Sun, 29 Jul 2007 13:40:06 -0400
Received: from 64.183.183.188 by webmail.pas.earthlink.net with HTTP; Sun, 29 Jul 2007 13:40:05 -0400
Message-ID: <20230308.1185730806178.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net>
Date: Sun, 29 Jul 2007 12:40:05 -0500
From: jwkckid1@ix.netcom.com
To: Mike <mike-list@pobox.com>, tls@ietf.org
Subject: Re: [TLS] RFC 4507bis
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068865979ef6ee5ba0e8795f69f25cf78584350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.49
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jwkckid1@ix.netcom.com
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 and all,

  I would say that HMAC-SHA256 should be recomended.

-----Original Message-----
>From: Mike <mike-list@pobox.com>
>Sent: Jul 29, 2007 11:58 AM
>To: tls@ietf.org
>Subject: [TLS] RFC 4507bis
>
>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
Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Registered Email addr with the USPS Contact Number: 214-244-4827



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