From tls-bounces@lists.ietf.org Wed May 11 08:47:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVqcT-0001N9-CW; Wed, 11 May 2005 08:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTqS-0005yZ-Ut for tls@megatron.ietf.org; Tue, 10 May 2005 08:28:16 -0400 Received: from shn-mail02.corp.avocent.com (mail.cybex.ie [212.120.141.82] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20874 for ; Tue, 10 May 2005 08:28:14 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 13:27:43 +0100 Message-ID: Thread-Topic: Question on length field used in HMAC calculation Thread-Index: AcVVW6ninwAXNdo4QKuzGXSd8hqeHA== From: "Nolan, Jerome" To: X-Mailman-Approved-At: Wed, 11 May 2005 08:47:19 -0400 Cc: Subject: [TLS] Question on length field used in HMAC calculation 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1052174202==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1052174202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5555B.AA7135F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5555B.AA7135F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm new to SSL/TLS and am looking at its implementation in hardware. I have a question about the length field that is used in the hash calculation. Given the structures below, is the length used in the hash calculation TLSCiphertext.length or TLSCompressed.length? It looks like it is TLSCompressed.length from the specification but this means that is necessary to decrypt the Ciphertext completely before starting the authentication (in order to get the padding_length and thus know the TLSCompressed.length). Is there a reason why TLSCompressed.length was chosen over TLSCiphertext.length? =20 Jerome Nolan Avocent =20 =20 struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; } fragment; } TLSCiphertext; =20 =20 block-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; =20 ------_=_NextPart_001_01C5555B.AA7135F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
   =20 I'm new to SSL/TLS and am looking at its implementation in hardware. I = have a=20 question about the length field that is used in the hash calculation.=20 Given the=20 structures below, is the length used in the hash = calculation TLSCiphertext.length or TLSCompressed.length? It looks = like it=20 is TLSCompressed.length from the specification but this means that = is=20 necessary to decrypt the Ciphertext completely before starting the=20 authentication (in order to get the padding_length and thus know=20 the TLSCompressed.length). Is there a reason why = TLSCompressed.length was=20 chosen over TLSCiphertext.length?

 

Jerome = Nolan
Avocent
 
 
=

struct {

           =20 ContentType type;

           =20 ProtocolVersion version;

           =20 uint16 length;

           =20 select (CipherSpec.cipher_type) {

           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 case stream: GenericStreamCipher;

           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       =20 case block: GenericBlockCipher;

           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    }=20 fragment;

          =20 } TLSCiphertext;

 

 

block-ciphered struct {

           &n= bsp;           &nb= sp;           &nbs= p;=20 opaque content[TLSCompressed.length];

           &n= bsp;           &nb= sp;           &nbs= p;=20 opaque = MAC[CipherSpec.hash_size];

           &n= bsp;           &nb= sp;           &nbs= p;=20 uint8 padding[GenericBlockCipher.padding_length];

                 &n= bsp;           &nb= sp;        uint8=20 padding_length;

           &n= bsp;           &nb= sp;         =20 } GenericBlockCipher;

 

------_=_NextPart_001_01C5555B.AA7135F3-- --===============1052174202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1052174202==-- From tls-bounces@lists.ietf.org Thu May 12 12:54:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGx1-0001LS-6T; Thu, 12 May 2005 12:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGx0-0001LK-4l for tls@megatron.ietf.org; Thu, 12 May 2005 12:54:18 -0400 Received: from laser.networkresonance.com (laser.networkresonance.com [198.144.196.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11077 for ; Thu, 12 May 2005 12:54:14 -0400 (EDT) Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A567B8A02C for ; Thu, 12 May 2005 10:00:27 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 12 May 2005 09:53:46 -0700 From: EKR Message-Id: <20050512170027.A567B8A02C@laser.networkresonance.com> Cc: Subject: [TLS] Closing on ECC/TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org OK, I've reviewed the last call comments for draft-ietf-tls-ecc. Here are the issues as I see them: 1. Replacing SHA-1 [Medvinsky] 2. Mixed cert chains [Medvinsky] 3. Hybrid port format/Format negotiation [Larsch] I don't see a lot of support for point (1) and (2) seems to be purely editorial. However, point (3) seems like it deserves more discussion. Nils, would you like to summarize your current position for WG discussion? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 12 12:55:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGy5-0001Ul-4Y; Thu, 12 May 2005 12:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGy3-0001Ub-Hn for tls@megatron.ietf.org; Thu, 12 May 2005 12:55:23 -0400 Received: from laser.networkresonance.com (laser.networkresonance.com [198.144.196.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11265 for ; Thu, 12 May 2005 12:55:19 -0400 (EDT) Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id ACA3B8A02D for ; Thu, 12 May 2005 10:01:32 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 12 May 2005 09:54:51 -0700 From: EKR Message-Id: <20050512170132.ACA3B8A02D@laser.networkresonance.com> Cc: Subject: [TLS] Results of last call on draft-ietf-tls-rfc3546bis 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The last call on this draft is now over and there were no comments. I'll review this document for nits and pass it on to the IESG. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat May 14 09:07:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWwMr-0003Up-4c; Sat, 14 May 2005 09:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWwMp-0003Uj-PI for tls@megatron.ietf.org; Sat, 14 May 2005 09:07:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00452 for ; Sat, 14 May 2005 09:07:41 -0400 (EDT) Received: from smtp-out2.blueyonder.co.uk ([195.188.213.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWwcx-0006ZH-7D for tls@ietf.org; Sat, 14 May 2005 09:24:24 -0400 Received: from [127.0.0.1] ([82.42.16.223]) by smtp-out2.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sat, 14 May 2005 14:08:20 +0100 Message-ID: <4285F7F7.8050606@blueyonder.co.uk> Date: Sat, 14 May 2005 14:07:03 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Question on length field used in HMAC calculation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2005 13:08:20.0100 (UTC) FILETIME=[0021BC40:01C55886] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Nolan, Jerome wrote: > Hi, > > I'm new to SSL/TLS and am looking at its implementation in hardware. > I have a question about the length field that is used in the hash > calculation. Given the structures below, is the length used in the hash > calculation TLSCiphertext.length or TLSCompressed.length? TLSCompressed.length (the spec is clear on this, AFAICS). > It looks like > it is TLSCompressed.length from the specification but this means that is > necessary to decrypt the Ciphertext completely before starting the > authentication (in order to get the padding_length and thus know the > TLSCompressed.length). Yes. > Is there a reason why TLSCompressed.length was chosen over TLSCiphertext.length? Inexperience. (It would have been better on both security and efficiency grounds to encrypt-then-MAC.) -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 16 17:41:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnKw-00076M-1q; Mon, 16 May 2005 17:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnKq-00075C-TX for tls@megatron.ietf.org; Mon, 16 May 2005 17:41:12 -0400 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24341 for ; Mon, 16 May 2005 17:41:09 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DXnKq-0006pC-1a; Mon, 16 May 2005 17:41:12 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 16 May 2005 17:41:12 -0400 Cc: tls@ietf.org Subject: [TLS] Last Call: 'The TLS Protocol Version 1.1' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'The TLS Protocol Version 1.1 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-10.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 18 15:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUZa-0005ma-6L; Wed, 18 May 2005 15:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUZW-0005lx-DF; Wed, 18 May 2005 15:51:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01480; Wed, 18 May 2005 15:51:12 -0400 (EDT) Message-Id: <200505181951.PAA01480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 18 May 2005 15:51:12 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The TLS Protocol Version 1.1 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc2246-bis-11.txt Pages : 90 Date : 2005-5-18 This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc2246-bis-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-18162724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc2246-bis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-18162724.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Thu May 19 18:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtEq-0001Nb-CM; Thu, 19 May 2005 18:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtEj-0001Mm-Uw for tls@megatron.ietf.org; Thu, 19 May 2005 18:11:26 -0400 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06784 for ; Thu, 19 May 2005 18:11:23 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DYtEj-00084n-DE; Thu, 19 May 2005 18:11:25 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 19 May 2005 18:11:25 -0400 Cc: tls@ietf.org Subject: [TLS] Last Call: 'Transport Layer Security (TLS) Extensions' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'Transport Layer Security (TLS) Extensions' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-06-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-00.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 19 21:10:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYw1s-000196-9e; Thu, 19 May 2005 21:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYw1p-000191-VS for tls@megatron.ietf.org; Thu, 19 May 2005 21:10:18 -0400 Received: from laser.networkresonance.com (laser.networkresonance.com [198.144.196.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25529 for ; Thu, 19 May 2005 21:10:13 -0400 (EDT) Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id BD2028A02C for ; Thu, 19 May 2005 18:16:24 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 19 May 2005 18:09:44 -0700 From: EKR Message-Id: <20050520011624.BD2028A02C@laser.networkresonance.com> Cc: Subject: [TLS] whither draft-salowey-tls-ticket-02.txt? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Folks, Joe Salowey has posted draft-salowey-tls-ticket-02.txt, which has the following abstract: This document describes a mechanism which enables the TLS server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This mechanism makes use of new TLS handshake messages and TLS hello extensions. Is there interest in the TLS WG in pursuing this as a WG item? Please send comments/discussion on this topic by May 31. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 20 08:18:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6SU-0003YW-DP; Fri, 20 May 2005 08:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6ST-0003YB-G7 for tls@megatron.ietf.org; Fri, 20 May 2005 08:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07076 for ; Fri, 20 May 2005 08:18:27 -0400 (EDT) Received: from decibel.pvv.ntnu.no ([129.241.210.179]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DZ6jo-0008Fp-C7 for tls@ietf.org; Fri, 20 May 2005 08:36:25 -0400 Received: (qmail 2888 invoked by uid 32454); 20 May 2005 12:18:24 -0000 To: EKR Subject: Re: [TLS] whither draft-salowey-tls-ticket-02.txt? References: <20050520011624.BD2028A02C@laser.networkresonance.com> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Fri, 20 May 2005 14:18:24 +0200 In-Reply-To: <20050520011624.BD2028A02C@laser.networkresonance.com> (ekr@networkresonance.com's message of "Thu, 19 May 2005 18:09:44 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org EKR writes: > Joe Salowey has posted draft-salowey-tls-ticket-02.txt, [...] Is this the same principle as described in your paper "Client Side Caching for TLS"? -- Jostein Tveit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 20 10:26:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8SX-0006eq-Ge; Fri, 20 May 2005 10:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8SV-0006ek-LN for tls@megatron.ietf.org; Fri, 20 May 2005 10:26:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21917 for ; Fri, 20 May 2005 10:26:37 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8jr-0003JX-7n for tls@ietf.org; Fri, 20 May 2005 10:44:37 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 May 2005 07:26:28 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4KEQPnC002052; Fri, 20 May 2005 07:26:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] whither draft-salowey-tls-ticket-02.txt? Date: Fri, 20 May 2005 07:30:16 -0700 Message-ID: <7210B31550AC934A8637D6619739CE690534F23A@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] whither draft-salowey-tls-ticket-02.txt? Thread-Index: AcVdNteMzWSbkjqiQNSMPbLlVXlGUAAEP/wQ From: "Salowey, Joe" To: "Jostein Tveit" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Yes. =20 > -----Original Message----- > From: Jostein Tveit [mailto:josteitv@pvv.ntnu.no]=20 > Sent: Friday, May 20, 2005 5:18 AM > To: EKR > Cc: tls@ietf.org > Subject: Re: [TLS] whither draft-salowey-tls-ticket-02.txt? >=20 > EKR writes: >=20 > > Joe Salowey has posted draft-salowey-tls-ticket-02.txt, [...] >=20 > Is this the same principle as described in your paper "Client=20 > Side Caching for TLS"? >=20 > -- > Jostein Tveit >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 20 15:06:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCos-0008Bo-GG; Fri, 20 May 2005 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCoo-0008Al-Fi for tls@megatron.ietf.org; Fri, 20 May 2005 15:06:00 -0400 Received: from treese.lh.vix.com (treese.lh.vix.com [204.152.188.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26186 for ; Fri, 20 May 2005 15:05:56 -0400 (EDT) Received: from snoopy.treese.org (c-24-91-18-113.hsd1.ma.comcast.net [24.91.18.113]) by treese.lh.vix.com (Postfix) with ESMTP id 87468C0D8 for ; Fri, 20 May 2005 14:45:24 -0400 (EDT) Received: from snoopy.treese.org (localhost [127.0.0.1]) by snoopy.treese.org (Postfix) with ESMTP id 77B8F444A for ; Fri, 20 May 2005 15:05:55 -0400 (EDT) To: tls@ietf.org From: Win Treese X-Mailer: MH-E 7.82; nmh 1.1; GNU Emacs 21.4.1 Date: Fri, 20 May 2005 15:05:55 -0400 Message-Id: <20050520190555.77B8F444A@snoopy.treese.org> Cc: Subject: [TLS] stepping down as co-chair 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Members of the TLS Working Group: For a variety of reasons, I have decided that it is time for me to step down as co-chair of the TLS working group. It has been a privilege and an honor to work with you in this capacity, and I greatly appreciate all the work that has gone into making TLS successful. I know that I am leaving the working group in good hands with Eric Rescorla, and I look forward to seeing continued improvements in TLS as a user. Thanks again for your work on TLS. Win Treese treese@acm.org _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 20 15:40:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDLx-0001GI-TE; Fri, 20 May 2005 15:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDLt-0001C2-7W; Fri, 20 May 2005 15:40:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01589; Fri, 20 May 2005 15:40:06 -0400 (EDT) Message-Id: <200505201940.PAA01589@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 20 May 2005 15:40:06 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Extensions Author(s) : S. Blake-Wilson, et al. Filename : draft-ietf-tls-rfc3546bis-01.txt Pages : 29 Date : 2005-5-20 This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc3546bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc3546bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-20154635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc3546bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc3546bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-20154635.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Fri May 20 16:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE9b-0001EX-QT; Fri, 20 May 2005 16:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE9a-0001ES-Kl for tls@megatron.ietf.org; Fri, 20 May 2005 16:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11632 for ; Fri, 20 May 2005 16:31:28 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZER0-0000DL-9N for tls@ietf.org; Fri, 20 May 2005 16:49:31 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 1F19F1706A; Fri, 20 May 2005 13:40:35 -0700 (PDT) To: Win Treese Subject: Re: [TLS] stepping down as co-chair References: <20050520190555.77B8F444A@snoopy.treese.org> From: Eric Rescorla Date: Fri, 20 May 2005 13:40:35 -0700 In-Reply-To: <20050520190555.77B8F444A@snoopy.treese.org> (Win Treese's message of "Fri, 20 May 2005 15:05:55 -0400") Message-ID: <86sm0h637g.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Win Treese writes: > Members of the TLS Working Group: > > For a variety of reasons, I have decided that it is time for me to step > down as co-chair of the TLS working group. It has been a privilege and > an honor to work with you in this capacity, and I greatly appreciate all > the work that has gone into making TLS successful. > > I know that I am leaving the working group in good hands with Eric > Rescorla, and I look forward to seeing continued improvements in TLS > as a user. Win, On behalf of the WG, thanks for the years of service. After 8 years as WG chair, I think you deserve a vacation! -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 23 18:59:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLtu-0000TZ-QX; Mon, 23 May 2005 18:59:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLtt-0000Od-6O for tls@megatron.ietf.org; Mon, 23 May 2005 18:59:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11428 for ; Mon, 23 May 2005 18:59:54 -0400 (EDT) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DaMBu-0000Bk-5X for tls@ietf.org; Mon, 23 May 2005 19:18:37 -0400 Received: (qmail invoked by alias); 23 May 2005 22:59:39 -0000 Received: from d171007.adsl.hansenet.de (EHLO [80.171.171.7]) [80.171.171.7] by mail.gmx.net (mp023) with SMTP; 24 May 2005 00:59:39 +0200 X-Authenticated: #25888033 Message-ID: <42926167.9010305@gmx.net> Date: Tue, 24 May 2005 01:04:07 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Closing on ECC/TLS References: <20050512170027.A567B8A02C@laser.networkresonance.com> In-Reply-To: <20050512170027.A567B8A02C@laser.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org EKR wrote: > OK, I've reviewed the last call comments for draft-ietf-tls-ecc. > > Here are the issues as I see them: > > 1. Replacing SHA-1 [Medvinsky] > 2. Mixed cert chains [Medvinsky] > 3. Hybrid port format/Format negotiation [Larsch] > > I don't see a lot of support for point (1) and (2) seems to be purely > editorial. However, point (3) seems like it deserves more discussion. > Nils, would you like to summarize your current position for WG discussion? Concerning the hybrid point format: as I'm not aware of any practical use for them => I would prefer not to include them. About point format negotiation: the current draft has the disadvantage that a client/server has either the option to offer support for prime and binary field curves and no point compression or only offer support for prime curves and point compression when using only patent free algs (point compression for binary curves is tainted). If point compression is considered a useful feature a more fine grained point negotiation might be useful (separate flags to indicate support for compressed for binary and prime field curves as Bodo suggested). Cheers, Nils _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 24 14:24:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae5D-0002Yc-Cj; Tue, 24 May 2005 14:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae5B-0002Wn-V9 for tls@megatron.ietf.org; Tue, 24 May 2005 14:24:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28488 for ; Tue, 24 May 2005 14:24:48 -0400 (EDT) Received: from mx1.opera.com ([193.69.116.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaeNP-0007OZ-1A for tls@ietf.org; Tue, 24 May 2005 14:43:40 -0400 Received: from mailbox.opera.com (root@mail.opera.com [193.69.113.66]) by mx1.opera.com (8.13.3/8.13.3/Debian-6) with ESMTP id j4OIOX34022882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 May 2005 18:24:33 GMT Received: from killashandra.oslo.opera.com (pc079.lan024.oslo.opera.com [10.20.24.79] (may be forged)) by mailbox.opera.com (8.13.2/8.13.2/Debian-1) with ESMTP id j4OIOXlL006180 for ; Tue, 24 May 2005 18:24:33 GMT Date: Tue, 24 May 2005 20:29:25 +0200 From: "Yngve Nysaeter Pettersen" To: tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt References: <200505181951.PAA01480@ietf.org> Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200505181951.PAA01480@ietf.org> User-Agent: Opera M2/7.54 (Win32, build 3929) X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 17:52:19 2005 on mx1.opera.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hello all, A couple of question and comments: Sec. 6 says "If a TLS implementation receives a record type it does not understand, it SHOULD just ignore it." If such a record is received after the parties have started encrypting the records, should it try to decrypt the data, or should the implementation throw the record away immediately? Sec A.5 specifically forbids the negotiation of 40 bit export ciphers. Does this also apply to the 56 bit export ciphers that was defined just before the export restrictions were eased? My reading of the document indicates "Yes". But should not also the single DES suites (e.g. TLS_RSA_WITH_DES_CBC_SHA) and perhaps also IDEA also be phased out in a similar manner? About compatibility: Back in August/September 2004 Opera Software performed a test where we released a Technology Preview version of Opera with TLS 1.1 and TLS Extensions enabled. During this test our users identified more than 120 services (including major banks) that did not interoperate with a client using either TLS 1.1 or TLS Extensions, or both. I have so far not been able to find out what is causing the problem. Is it within the scope of this draft to discuss how to handle this situation? We did, after all, have similar problems when TLS 1.0 was introduced. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 26 10:28:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJLp-0005H8-Me; Thu, 26 May 2005 10:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJLo-0005G6-00 for tls@megatron.ietf.org; Thu, 26 May 2005 10:28:44 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02696 for ; Thu, 26 May 2005 10:28:41 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id B5C7428441 for ; Thu, 26 May 2005 08:00:54 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 26 May 2005 07:37:31 -0700 From: Eric Rescorla Message-Id: <20050526150054.B5C7428441@sierra.rtfm.com> Cc: Subject: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org WG members: G. Chudov has just posted draft-chudov-cryptopro-tlsprfneg-00.txt, which describes a scheme for PRF negotiation for TLS. The major motivation for this is to enable GOST use in TLS, because for regulatory reasons GOST cannot be used with non-GOST hash functions. This would be a major technical change to TLS. Is this work that the TLS WG wants to take on? Please submit comments before June 10. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 26 23:17:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbVLY-0008Cx-WF; Thu, 26 May 2005 23:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbVLX-0008Cs-OF for tls@megatron.ietf.org; Thu, 26 May 2005 23:17:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09265 for ; Thu, 26 May 2005 23:17:13 -0400 (EDT) Received: from cosmic.dnp.co.jp ([210.133.104.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbVeE-0006p2-W5 for tls@ietf.org; Thu, 26 May 2005 23:36:36 -0400 Received: from kuro.cansec.dnp.co.jp (kuro.cansec.dnp.co.jp [192.168.2.130]) by cosmic.dnp.co.jp (DNP/IOC-5.4/Fw+Ex/MTA) with ESMTP id j4R3HCkp018378 for ; Fri, 27 May 2005 12:17:12 +0900 (JST) Received: from kuro.cansec.dnp.co.jp (localhost [127.0.0.1]) by kuro.cansec.dnp.co.jp (CANSEC//CANSEC/MTA/20040520) with ESMTP id j4R3HBHr022138 for ; Fri, 27 May 2005 12:17:11 +0900 (JST) Received: from lupin.lab.cio.dnp.co.jp ([10.100.128.182]) by kuro.cansec.dnp.co.jp (CANSEC//CANSEC/MTA/20040520) with ESMTP id j4R3HBlA022132 for ; Fri, 27 May 2005 12:17:11 +0900 (JST) Received: from lab.cio.dnp.co.jp (akimoto.lab.cio.dnp.co.jp [10.100.144.69]) by lupin.lab.cio.dnp.co.jp (8.12.10/8.12.10) with ESMTP id j4R3HBDY002704 for ; Fri, 27 May 2005 12:17:11 +0900 Message-ID: <42969153.20401@lab.cio.dnp.co.jp> Date: Fri, 27 May 2005 12:17:39 +0900 From: Satoshi Akimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: tls@ietf.org References: <200505181951.PAA01480@ietf.org> In-Reply-To: <200505181951.PAA01480@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Subject: [TLS] PKCS #1 block type 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, The terms like 'PKCS #1 block type x' are frequently used in 2246 and its bis, but they are no longer used in the current PKCS #1 or rfc3447. Wouldn't it be more explicit to use 'EME-PKCS1-v1_5' or 'EMSA-PKCS1-v1_5' instead? (it leaves a question for 'type 0' padding, though) Best regards, Satoshi Akimoto Dai Nippon Printing _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 27 00:16:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbWGn-0000P5-JC; Fri, 27 May 2005 00:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbWGm-0000P0-Mo for tls@megatron.ietf.org; Fri, 27 May 2005 00:16:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12882 for ; Fri, 27 May 2005 00:16:21 -0400 (EDT) Received: from ws6-5.us4.outblaze.com ([205.158.62.152]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DbWZU-000800-B1 for tls@ietf.org; Fri, 27 May 2005 00:35:45 -0400 Received: (qmail 24663 invoked from network); 27 May 2005 04:16:16 -0000 Received: from unknown (HELO ?192.168.0.2?) (nelson@bolyard.com@24.6.210.63) by ws6-5.us4.outblaze.com with SMTP; 27 May 2005 04:16:16 -0000 Message-ID: <42969F7B.9040804@bolyard.com> Date: Thu, 26 May 2005 21:18:03 -0700 From: "Nelson B. Bolyard" Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521 MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] whither draft-salowey-tls-ticket-02.txt? References: <20050520011624.BD2028A02C@laser.networkresonance.com> In-Reply-To: <20050520011624.BD2028A02C@laser.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org EKR wrote: > Folks, > > Joe Salowey has posted draft-salowey-tls-ticket-02.txt, Did I see EKR's name in there, too? :) > Is there interest in the TLS WG in pursuing this as a WG item? > > Please send comments/discussion on this topic by May 31. Yes, I believe that this proposed enhancement to TLS is worthy of our group's pursuit. It would potentially enable TLS server solutions to scale to multiple server-system (box) solutions more cheaply than is commonly done today, I think. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 27 02:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbYj0-0007c5-Be; Fri, 27 May 2005 02:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbYiy-0007bf-Ip for tls@megatron.ietf.org; Fri, 27 May 2005 02:53:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14514 for ; Fri, 27 May 2005 02:53:37 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbZ1e-0002jR-J5 for tls@ietf.org; Fri, 27 May 2005 03:13:01 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1DbYiq1aId-0006e3; Fri, 27 May 2005 08:53:32 +0200 Received: by tau.local (Postfix, from userid 500) id A7FDE2F19D; Fri, 27 May 2005 00:52:49 -0600 (MDT) Date: Fri, 27 May 2005 00:52:49 -0600 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt Message-ID: <20050527065249.GA17836@tau.local> References: <200505181951.PAA01480@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505181951.PAA01480@ietf.org> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Wed, May 18, 2005 at 03:51:12PM -0400, Internet-Drafts@ietf.org wrote: > Title : The TLS Protocol Version 1.1 > Author(s) : T. Dierks, E. Rescorla > Filename : draft-ietf-tls-rfc2246-bis-11.txt > Pages : 90 > Date : 2005-5-18 > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt This new ID does not yet correct the inconsistencies for some field and type names pointed out in , reproduced below. But first, here's a new comment: 7.4.7.1. RSA encrypted premaster secret message [...] In practice, since there are no significant known security differences between TLS and SSLv3, rollback to SSLv3 is not believed to be a serious security risk. Discussing "security differences between TLS and SSLv3" is a little odd because this sounds like comparing two protocol versions. But in fact this specification defines TLS 1.1, so there are three protocol versions to take into account. And there are security differences both between SSL 3.0 and TLS 1.0 *and* between TLS 1.0 and TLS 1.1: TLS 1.1 uses explicit IVs for CBC encryption to avoid deficiencies present in both earlier versions; SSL 3.0 has additional weaknesses due to its failure to completely specify block cipher padding (as I pointed out in http://www.imc.org/ietf-tls/mail-archive/msg03983.html). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Section 7.4.3 defines struct { opaque rsa_modulus<1..2^16-1>; opaque rsa_exponent<1..2^16-1>; } ServerRSAParams; struct { opaque dh_p<1..2^16-1>; opaque dh_g<1..2^16-1>; opaque dh_Ys<1..2^16-1>; } ServerDHParams; /* Ephemeral DH parameters */ but Appendix A.4.2 has capitalized versions of the names. struct { opaque RSA_modulus<1..2^16-1>; opaque RSA_exponent<1..2^16-1>; } ServerRSAParams; struct { opaque DH_p<1..2^16-1>; opaque DH_g<1..2^16-1>; opaque DH_Ys<1..2^16-1>; } ServerDHParams; Generally, the principle appears to be that field names should be [mostly] lower-case, with capital letters reserved for type names, so it's A.4.2 that should be changed. And in A.4.3, the type definition for ClientKeyExchange refers to a "DiffieHellmanClientPublicValue" type. But this should actually be "ClientDiffieHellmanPublic". <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 27 04:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbaYz-0001T6-NQ; Fri, 27 May 2005 04:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbaYy-0001Sz-93 for tls@megatron.ietf.org; Fri, 27 May 2005 04:51:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21722 for ; Fri, 27 May 2005 04:51:26 -0400 (EDT) Received: from harpo.itss.auckland.ac.nz ([130.216.190.13] helo=smtpc.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbarj-0005I4-MI for tls@ietf.org; Fri, 27 May 2005 05:10:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id EFE4E344BA; Fri, 27 May 2005 20:51:15 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15290-10; Fri, 27 May 2005 20:51:15 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id CC2083449C; Fri, 27 May 2005 20:51:14 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C678437756; Fri, 27 May 2005 20:51:14 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbaYr-0008PY-00; Fri, 27 May 2005 20:51:21 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: akimoto@lab.cio.dnp.co.jp, tls@ietf.org Subject: Re: [TLS] PKCS #1 block type In-Reply-To: <42969153.20401@lab.cio.dnp.co.jp> Message-Id: Date: Fri, 27 May 2005 20:51:21 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Satoshi Akimoto writes: >The terms like 'PKCS #1 block type x' are frequently used in 2246 and its >bis, but they are no longer used in the current PKCS #1 or rfc3447. Wouldn't >it be more explicit to use 'EME-PKCS1-v1_5' or 'EMSA-PKCS1-v1_5' instead? (it >leaves a question for 'type 0' padding, though) Far too many existing publications refer to PKCS #1 to simply drop it at this point. Perhaps the text could use both, with the alphabet-soup version in parentheses after the more common term. I've always found the alphabet-soup terminology that seems to have been introduced by P1363 highly confusing, so having both would be nice. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 27 12:39:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhrt-0007JI-3G; Fri, 27 May 2005 12:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhrq-0007Ix-5b for tls@megatron.ietf.org; Fri, 27 May 2005 12:39:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25668 for ; Fri, 27 May 2005 12:39:23 -0400 (EDT) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiAc-0007X7-JV for tls@ietf.org; Fri, 27 May 2005 12:58:53 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id DBD531E8CCD; Fri, 27 May 2005 09:39:04 -0700 (PDT) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] PKCS #1 block type References: From: EKR Date: Fri, 27 May 2005 09:39:04 -0700 In-Reply-To: (Peter Gutmann's message of "Fri, 27 May 2005 20:51:21 +1200") Message-ID: <86y8a0pqs7.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Satoshi Akimoto writes: > >>The terms like 'PKCS #1 block type x' are frequently used in 2246 and its >>bis, but they are no longer used in the current PKCS #1 or rfc3447. Wouldn't >>it be more explicit to use 'EME-PKCS1-v1_5' or 'EMSA-PKCS1-v1_5' instead? (it >>leaves a question for 'type 0' padding, though) > > Far too many existing publications refer to PKCS #1 to simply drop it at this > point. Perhaps the text could use both, with the alphabet-soup version in > parentheses after the more common term. I've always found the alphabet-soup > terminology that seems to have been introduced by P1363 highly confusing, so > having both would be nice. I've discussed this with Russ and our plan is to provide references to both 2246 and 3447 but in the interest of minimal spec changes to use the old PKCS#1 1.5 terminology. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 27 13:47:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiw3-0008VC-Av; Fri, 27 May 2005 13:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiw1-0008Ta-Mo for tls@megatron.ietf.org; Fri, 27 May 2005 13:47:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04610 for ; Fri, 27 May 2005 13:47:48 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjEq-0001rd-Rm for tls@ietf.org; Fri, 27 May 2005 14:07:17 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 74D551705C; Fri, 27 May 2005 10:58:02 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt References: <200505181951.PAA01480@ietf.org> <20050527065249.GA17836@tau.local> From: Eric Rescorla Date: Fri, 27 May 2005 10:58:02 -0700 In-Reply-To: <20050527065249.GA17836@tau.local> (Bodo Moeller's message of "Fri, 27 May 2005 00:52:49 -0600") Message-ID: <867jhkd00l.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo Moeller writes: > On Wed, May 18, 2005 at 03:51:12PM -0400, Internet-Drafts@ietf.org wrote: > >> Title : The TLS Protocol Version 1.1 >> Author(s) : T. Dierks, E. Rescorla >> Filename : draft-ietf-tls-rfc2246-bis-11.txt >> Pages : 90 >> Date : 2005-5-18 > >> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-11.txt > > This new ID does not yet correct the inconsistencies for some field > and type names pointed out in > , > reproduced below. OK. I'll fix this. > But first, here's a new comment: > > 7.4.7.1. RSA encrypted premaster secret message > > [...] In practice, since > there are no significant known security differences between TLS > and SSLv3, rollback to SSLv3 is not believed to be a serious > security risk. > > Discussing "security differences between TLS and SSLv3" is a little > odd because this sounds like comparing two protocol versions. But in > fact this specification defines TLS 1.1, so there are three protocol > versions to take into account. And there are security differences > both between SSL 3.0 and TLS 1.0 *and* between TLS 1.0 and TLS 1.1: > TLS 1.1 uses explicit IVs for CBC encryption to avoid deficiencies > present in both earlier versions; SSL 3.0 has additional weaknesses > due to its failure to completely specify block cipher padding > (as I pointed out in > http://www.imc.org/ietf-tls/mail-archive/msg03983.html). Right. I'll rewrite this. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Section 7.4.3 defines > > struct { > opaque rsa_modulus<1..2^16-1>; > opaque rsa_exponent<1..2^16-1>; > } ServerRSAParams; > > struct { > opaque dh_p<1..2^16-1>; > opaque dh_g<1..2^16-1>; > opaque dh_Ys<1..2^16-1>; > } ServerDHParams; /* Ephemeral DH parameters */ > > but Appendix A.4.2 has capitalized versions of the names. > > struct { > opaque RSA_modulus<1..2^16-1>; > opaque RSA_exponent<1..2^16-1>; > } ServerRSAParams; > > struct { > opaque DH_p<1..2^16-1>; > opaque DH_g<1..2^16-1>; > opaque DH_Ys<1..2^16-1>; > } ServerDHParams; > > Generally, the principle appears to be that field names should be > [mostly] lower-case, with capital letters reserved for type names, > so it's A.4.2 that should be changed. > > > And in A.4.3, the type definition for ClientKeyExchange refers to a > "DiffieHellmanClientPublicValue" type. But this should actually > be "ClientDiffieHellmanPublic". OK. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 30 00:58:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DccMY-00054C-Og; Mon, 30 May 2005 00:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DccMW-000547-Oc for tls@megatron.ietf.org; Mon, 30 May 2005 00:58:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23524 for ; Mon, 30 May 2005 00:58:50 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dccfr-0007tz-92 for tls@ietf.org; Mon, 30 May 2005 01:18:52 -0400 Received: from esebh108.NOE.Nokia.com ([172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4U4wkPQ019014; Mon, 30 May 2005 07:58:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 07:58:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 07:58:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Date: Mon, 30 May 2005 07:58:45 +0300 Message-ID: Thread-Topic: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Thread-Index: AcVh/5L9OEo1XqGDT0C1mxuvItvY+gC0sPpQ To: , X-OriginalArrivalTime: 30 May 2005 04:58:46.0147 (UTC) FILETIME=[42803530:01C564D4] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, It does seem that having a way to use some other PRF than the=20 standard one would be useful in some (very limited)=20 circumstances. However, I'm not so sure about the usefulness of adding a=20 new negotiation mechanism for it. It was proposed earlier=20 that we could simply define the PRF (and the hash used when=20 calculating Finished messages) to be part of the ciphersuite; this sounds like a reasonable and simple approach to me.=20 (Of course, for those ciphersuites that don't say anything=20 about the PRF, it would be the standard TLS-PRF, so there's no need to have this included in 2246bis.) Best regards, Pasi > -----Original Message----- > From: Eric Rescorla > Sent: Thursday, May 26, 2005 5:38 PM > To: tls@ietf.org > Subject: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt >=20 >=20 > WG members:=20 >=20 > G. Chudov has just posted=20 > draft-chudov-cryptopro-tlsprfneg-00.txt, which > describes a scheme for PRF negotiation for TLS. The major motivation > for this is to enable GOST use in TLS, because for regulatory reasons > GOST cannot be used with non-GOST hash functions. This would=20 > be a major=20 > technical change to TLS.=20 >=20 > Is this work that the TLS WG wants to take on?=20 >=20 > Please submit comments before June 10. >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 30 04:21:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcfWQ-0001F6-4Z; Mon, 30 May 2005 04:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcfWN-0001Ew-DZ for tls@megatron.ietf.org; Mon, 30 May 2005 04:21:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26893 for ; Mon, 30 May 2005 04:21:13 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcfpg-0003Oh-2Q for tls@ietf.org; Mon, 30 May 2005 04:41:16 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j4U8L4Cu021086 for ; Mon, 30 May 2005 10:21:04 +0200 Received: from erle.asw.mchp.siemens.de ([139.25.160.141]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j4U8L4tb016548 for ; Mon, 30 May 2005 10:21:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt Date: Mon, 30 May 2005 10:21:05 +0200 Message-ID: <2F15F0E7E769D74DA160CDF5BC8676C8103899@erle.asw.mchp.siemens.de> Thread-Topic: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt Thread-Index: AcVk8IRwyP5RuPT/Q4uKueon34MTZw== From: "Franke, Markus" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, to be consistent with other structures in chapter 7.4.3 and in A.4.2 the following structure select (SignatureAlgorithm) { case anonymous: struct { }; case rsa: digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature; should be replaced with: struct { select (SignatureAlgorithm) { =20 case anonymous: struct { }; case rsa: digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; }; }; } Signature; Best regards, Markus _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 31 15:47:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCiN-0006PA-CN; Tue, 31 May 2005 15:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCiJ-0006P0-TP for tls@megatron.ietf.org; Tue, 31 May 2005 15:47:50 -0400 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12017 for ; Tue, 31 May 2005 15:47:44 -0400 (EDT) Received: from dhcp238.math.ucalgary.ca [136.159.61.238] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1DdCiE2Z7o-0001CH; Tue, 31 May 2005 21:47:42 +0200 Received: by tau.local (Postfix, from userid 500) id 5169E31AB7; Tue, 31 May 2005 13:47:36 -0600 (MDT) Date: Tue, 31 May 2005 13:47:36 -0600 From: Bodo Moeller To: tls@ietf.org, EKR Subject: Re: [TLS] Closing on ECC/TLS Message-ID: <20050531194735.GA28746@tau.local> References: <20050512170027.A567B8A02C@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512170027.A567B8A02C@laser.networkresonance.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Thu, May 12, 2005 at 09:53:46AM -0700, EKR wrote: > OK, I've reviewed the last call comments for draft-ietf-tls-ecc. > > Here are the issues as I see them: > > 1. Replacing SHA-1 [Medvinsky] > 2. Mixed cert chains [Medvinsky] > 3. Hybrid port format/Format negotiation [Larsch] > > I don't see a lot of support for point (1) and (2) seems to be purely > editorial. However, point (3) seems like it deserves more discussion. An updated ID is now available: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-10.txt This takes into account points (2) and (3). (Hybrid format no longer appears in the specification, and format negotation now distinguishes between the compressed formats for prime curves and characteristic-2 curves.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 31 15:54:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCoY-0008AR-5q; Tue, 31 May 2005 15:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCoT-00087V-8e; Tue, 31 May 2005 15:54:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13258; Tue, 31 May 2005 15:54:07 -0400 (EDT) Message-Id: <200505311954.PAA13258@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 31 May 2005 15:54:07 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites for TLS Author(s) : V. Gupta, et al. Filename : draft-ietf-tls-ecc-10.txt Pages : 35 Date : 2005-5-31 This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-31155809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-31155809.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue May 31 20:15:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGti-0006Y2-87; Tue, 31 May 2005 20:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGtg-0006Xx-Ir for tls@megatron.ietf.org; Tue, 31 May 2005 20:15:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12261 for ; Tue, 31 May 2005 20:15:47 -0400 (EDT) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHDO-0006ye-4W for tls@ietf.org; Tue, 31 May 2005 20:36:11 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7D58E1E8CCD; Tue, 31 May 2005 17:15:33 -0700 (PDT) To: yngve@opera.com Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt References: <200505181951.PAA01480@ietf.org> From: EKR Date: Tue, 31 May 2005 17:15:33 -0700 In-Reply-To: (Yngve Nysaeter Pettersen's message of "Tue, 24 May 2005 20:29:25 +0200") Message-ID: <86fyw3sziy.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Yngve Nysaeter Pettersen" writes: > Hello all, > > A couple of question and comments: > > Sec. 6 says "If a TLS implementation receives a record type it does not > understand, it SHOULD just ignore it." > > If such a record is received after the parties have started encrypting > the records, should it try to decrypt the data, or should the > implementation throw the record away immediately? Well, for RC4 you have to at least skip ahead to the next section of keystream. With the block ciphers in TLS 1.1 you can just discard the record. Otherwise, I think it's implementation dependent. > Sec A.5 specifically forbids the negotiation of 40 bit export ciphers. > > Does this also apply to the 56 bit export ciphers that was defined > just before the export restrictions were eased? My reading of the > document indicates "Yes". But should not also the single DES suites > (e.g. TLS_RSA_WITH_DES_CBC_SHA) and perhaps also IDEA also be phased > out in a similar manner? My read of this is no. > About compatibility: Back in August/September 2004 Opera Software > performed a test where we released a Technology Preview version of > Opera with TLS 1.1 and TLS Extensions enabled. During this test our > users identified more than 120 services (including major banks) that > did not interoperate with a client using either TLS 1.1 or TLS > Extensions, or both. I have so far not been able to find out what is > causing the problem. You mean aside from noone actually implementing them? :) Was there some other problem? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 31 23:53:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKIc-0005Ab-Qa; Tue, 31 May 2005 23:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdKIa-0005AW-Rb for tls@megatron.ietf.org; Tue, 31 May 2005 23:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23748 for ; Tue, 31 May 2005 23:53:42 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdKcJ-0000Nj-Df for tls@ietf.org; Wed, 01 Jun 2005 00:14:09 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 473AB1705C; Tue, 31 May 2005 21:03:46 -0700 (PDT) To: "Yngve N. Pettersen (Developer Opera Software ASA)" Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt References: <200505181951.PAA01480@ietf.org> <86fyw3sziy.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Tue, 31 May 2005 21:03:46 -0700 In-Reply-To: (Yngve N. Pettersen's message of "Wed, 01 Jun 2005 03:38:58 +0200") Message-ID: <86hdgibu59.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Yngve N. Pettersen (Developer Opera Software ASA)" writes: > Yes. The mentioned servers (or their surround support systems) did not > tolerate clients that used TLS 1.1, or TLS extensions, or both. The > most common response (but not the only one) to a Client Hello > including one or both of them is to shut down the connection, without > any alert messages whatsoever. > > There are a number of variations, some servers would accept either, > but not both; others would accept TLS 1.1 and extensions, but not TLS > 1.0 with extensions, and so on. I classified 5 major types of > problems. > > Some minor variations also existed: One TLS 1.0 capable server > actually negotiated SSL v3 when the client asked for TLS 1.1. Another > used an incorrect version number (the negotiated) when checking the > RSA Premaster Secret. > > In one case I saw one server that initially only cut the connection > when a TLS 1.1 Hello was sent change to also cutting the connection > when TLS Extensions were used, a few weeks later. > > See the top post in > http://my.opera.com/forums/showthread.php?s=&threadid=65055 for more > examples. > > For those interested, Opera 8.0 ships with TLS 1.1 (it still support > export ciphers) and TLS Server Name Extension support, both controlled > by the TLS 1.1 setting, which is disabled by default. Hmm... That's too bad to hear. That said, I think the documentation on what one is supposed to do is pretty clear, so I'm not sure that more specification can help. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 09 16:17:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgTTQ-00049k-Rc; Thu, 09 Jun 2005 16:17:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dblw4-0005Xo-Pr for tls@megatron.ietf.org; Fri, 27 May 2005 17:00:04 -0400 Received: from carter-zimmerman.mit.edu (STRATTON-TWO-FIFTEEN.MIT.EDU [18.187.5.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03699 for ; Fri, 27 May 2005 17:00:02 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2E4B6E0063; Fri, 27 May 2005 16:59:58 -0400 (EDT) To: tls@ietf.org From: Sam Hartman Date: Fri, 27 May 2005 16:59:58 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 09 Jun 2005 16:17:55 -0400 Cc: iesg@ietf.org Subject: [TLS] draft-ietf-tls-psk and identity 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi. The PSK draft is now before the IESG for final approval. As one of the people reviewing the draft, I have two questions I'd like to ask. The first is why is the identity not labeled. In other cases where we've had a lot of name spaces, we have chosen to label the identity with which name space it comes from. Why did you choose to just have an opaque string? How frequent will it be that identities from one namespace might be confused with identities from another namespace. It seems like for example NAIs and email addresses might be confused. These seem like they might both be commonly used. Other identities look similar to email addresses. What would the costs of labeling be? Would it be worth the cost? Secondly, I'm concerned about internationalization. Scetion 5.4 says that an appropriate stringprep profile should be used but does not say what this profile is. The PSK draft seems to want client management interface to be able to take arbitrary identity forms without knowing about these identity forms. However the preparation and normalization strategy the IETF has adopted assume that the entity processing an ID needs to apply ID-form-specific normalization to that ID. What alternatives have been considered for internationalization? Who has reviewed the internationalization concerns of this draft? Would things work better if the client management interface preserved the ID and never normalized, requiring that the server use some stringprep (and possibly other) normalization/canonicalization after determing the appropriate ID form? Thanks for considering these issues, --Sam _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls