From tls-bounces@ietf.org Mon Mar 7 03:26:18 2005 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 DAA15019; Mon, 7 Mar 2005 03:26:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Dai-0004FM-SW; Mon, 07 Mar 2005 03:28:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8DY3-00022U-37; Mon, 07 Mar 2005 03:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8DW8-0001rr-A8 for tls@megatron.ietf.org; Mon, 07 Mar 2005 03:23:08 -0500 Received: from universe.uohyd.ernet.in ([202.41.85.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14740 for ; Mon, 7 Mar 2005 03:23:03 -0500 (EST) Received: from ailab.uohyd.ernet.in (ailab.uohyd.ernet.in [202.41.85.117]) by universe.uohyd.ernet.in (8.9.0/8.9.0) with ESMTP id NAA09107 for ; Mon, 7 Mar 2005 13:46:50 -0500 (GMT) Received: from ailab.uohyd.ernet.in (ailab [127.0.0.1]) by ailab.uohyd.ernet.in (8.12.8/8.12.8) with ESMTP id j278KMHM028576 for ; Mon, 7 Mar 2005 13:50:22 +0530 Received: (from apache@localhost) by ailab.uohyd.ernet.in (8.12.8/8.12.8/Submit) id j278KMDP028574; Mon, 7 Mar 2005 13:50:22 +0530 X-Authentication-Warning: ailab.uohyd.ernet.in: apache set sender to hussam@localhost using -f Received: from 172.16.1.2 (proxying for 172.16.17.83) (SquirrelMail authenticated user hussam) by 172.16.17.2 with HTTP; Mon, 7 Mar 2005 13:50:22 +0530 (IST) Message-ID: <42054.172.16.1.2.1110183622.squirrel@172.16.17.2> Date: Mon, 7 Mar 2005 13:50:22 +0530 (IST) From: "Hussam Saeed" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [TLS] exportability 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 8bit what does exportable ciphers (technically) means? or what does EXP1024-RC4-MD5 and EXP-DES-CBC-SHA means? thanks. Hussam. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Mar 11 11:21:01 2005 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 LAA10128; Fri, 11 Mar 2005 11:21:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mvo-0003nz-Lr; Fri, 11 Mar 2005 11:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mrc-0004sZ-Nv; Fri, 11 Mar 2005 11:19:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9bFL-0001ip-P8 for tls@megatron.ietf.org; Thu, 10 Mar 2005 22:55:31 -0500 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12270 for ; Thu, 10 Mar 2005 22:55:28 -0500 (EST) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D9bFI-0006br-00; Fri, 11 Mar 2005 04:55:28 +0100 Received: from [136.159.61.188] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D9bFI-0004Ds-00; Fri, 11 Mar 2005 04:55:28 +0100 Received: by tau.local (Postfix, from userid 500) id ADE232B90A; Thu, 10 Mar 2005 20:55:24 -0700 (MST) Date: Thu, 10 Mar 2005 20:55:24 -0700 From: Bodo Moeller To: tls@ietf.org Message-ID: <20050311035524.GA4386@tau.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Mailman-Approved-At: Fri, 11 Mar 2005 11:19:48 -0500 Subject: [TLS] Some inconsistencies in draft-ietf-tls-rfc2246-bis-09.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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 The following inconstistencies from RFC 2246 still exist in draft-ietf-tls-rfc2246-bis-09.txt (I doubt that the list is complete): 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@ietf.org Wed Mar 16 16:25:50 2005 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 QAA20104; Wed, 16 Mar 2005 16:25:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBg5e-00027M-7h; Wed, 16 Mar 2005 16:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfV4-0008HQ-Cp; Wed, 16 Mar 2005 15:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfV1-0008Gd-2P; Wed, 16 Mar 2005 15:52:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08186; Wed, 16 Mar 2005 15:52:12 -0500 (EST) Message-Id: <200503162052.PAA08186@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, 16 Mar 2005 15:52:12 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-07.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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-07.txt Pages : 17 Date : 2005-3-16 This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-07.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-psk-07.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-psk-07.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-3-16161220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161220.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Thu Mar 17 10:49:46 2005 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 KAA15170; Thu, 17 Mar 2005 10:49:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxK8-0005P7-HK; Thu, 17 Mar 2005 10:54:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxCa-0002y6-Bx; Thu, 17 Mar 2005 10:46:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxCY-0002xp-Cb; Thu, 17 Mar 2005 10:46:22 -0500 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 KAA14614; Thu, 17 Mar 2005 10:46:19 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxGm-0005GV-Lo; Thu, 17 Mar 2005 10:50:47 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2HFkGZ20817; Thu, 17 Mar 2005 17:46:17 +0200 (EET) X-Scanned: Thu, 17 Mar 2005 17:46:06 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j2HFk6LT028765; Thu, 17 Mar 2005 17:46:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00uR6bjS; Thu, 17 Mar 2005 17:46:04 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2HFk2M17373; Thu, 17 Mar 2005 17:46:02 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Mar 2005 17:45:12 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Mar 2005 17:45:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Mar 2005 17:45:10 +0200 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 Date: Thu, 17 Mar 2005 17:45:09 +0200 Message-ID: Thread-Topic: Last call comments about DTLS (mostly editorial) thread-index: AcUrCEzF9erXFndJSgu+1UaTvMwbLA== To: , X-OriginalArrivalTime: 17 Mar 2005 15:45:10.0023 (UTC) FILETIME=[4CEC8970:01C52B08] X-Spam-Score: 0.3 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Subject: [TLS] Last call comments about DTLS (mostly editorial) 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable I've started reviewing draft-rescorla-dtls-03, and=20 here's my first batch of comments (mostly editorial). (I also have a couple of more technical comments, but I haven't finished writing them down yet. I'll send them in a separate message in a couple of days.) 1)=20 Section 2 says that "While the design of the DTLS protocol does not preclude its use in securing arbitrary datagram traffic, it is primarily expected to secure communication based on datagram sockets." What does this mean? That DTLS is primarily intended for UDP, but could be used for other kinds of datagram transports? Suggested change: clarify sentence somehow. 2) In Sections 4.2.1 and 4.3, "Cookie cookie<0..32>;" is not correct, since the document does not define the type "Cookie" (and even if it did, that would mean up to 32 individual cookies). Suggested change: define "opaque Cookie<0..32>;" and change the ClientHello/HelloVerifyRequest field to "Cookie cookie;" 3) Section 4.2.4.1: "RECOMMEND" is not a RFC 2119 keyword, Suggested change: "We RECOMMEND that implementations use..." --> "Implementations SHOULD use..." 4) Section 4.2.4.1: Since [TCP] defines MSL to be 2 minutes, why not just say so? Suggested change "up to twice the TCP Maximum Segment Lifetime. [TCP]" --> "up to 240 seconds (which happens to be twice the TCP Maximum Segment Lifetime in [TCP])" 5) Sections 4.2 and 5 make exaggarated claims about cookies and denial of service attacks. Cookies don't "prevent denial of service attacks"; they make it more difficult to spoof the source IP address, but that's all.=20 For instance, cookies alone do nothing to protect against DoS=20 attacks where the source IP address is not spoofed. Suggested change: explain that cookies give some protection against DoS attacks from spoofed IP addresses. For attacks=20 where the source IP is not spoofed, the DoS situation is=20 the same as in ordinary TLS. 6) Section 4.2.1 says that "If the client does not have a cookie for a given server, it should use a zero-length cookie." Cookies are not specific to a server, but a particular negotiation instance (at least if the server follows the advice given later and includes ClientHello.random in cookie calculation). And even though "should" is an ordinary English word, rather than RFC2119 keyword, it still raises the question when some other choice (than using a zero-length cookie) would make sense. Suggested change: "If the client does not have a cookie for a given server, it should use a zero-length cookie." --> "When sending the first ClientHello, the client does not have a=20 cookie yet; in this case, the Cookie field is left empty=20 (zero length)." =20 7) Section 4.3 is missing the ClientHello message. Suggested change: copy the definition from Section 4.2.1. 8) Section 6 (IANA Considerations): This document defines a new HandshakeType value, so IANA needs to be told about it. Also, the text "Identifiers MAY NOT be assigned for DTLS that conflict with TLS" is quite unclear and probably unnecessary: since we're using the same registries as TLS, how would IANA allocate a conflicting number? (and "MAY NOT" is not a RFC=20 2119 keyword anyway) Suggested text: This document uses the same identifier space as TLS [TLS11], so no new IANA registries are required. This document defines a new handshake message, hello_verify_request, whose value is to be allocated from=20 the TLS HandshakeType registry defined in [TLS11]. The=20 value "3" is suggested. 9) I would probably call [PHOTURIS], [RFC2401], [TCP], and [TLS] informative references rather than normative.=20 10) Section numbering is a bit broken (there are two sections numbered 4.2). And a table of contents wouldn't hurt, since the document is anyway over 20 pages. 11) Complaints from idnits-v1.61: There are 11 instances of too long lines in the document, the=20 longest one being 8 characters in excess of 72. There is 1 instance of lines with control characters in =20 the document. It seems as if not all pages are separated by form feeds -=20 found 0 form feeds but 22 pages Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Mar 17 11:11:44 2005 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 LAA18217; Thu, 17 Mar 2005 11:11:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxfP-0006Dp-CP; Thu, 17 Mar 2005 11:16:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxZz-0001CG-Oz; Thu, 17 Mar 2005 11:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxZy-0001BA-GJ; Thu, 17 Mar 2005 11:10:34 -0500 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 LAA18025; Thu, 17 Mar 2005 11:10:30 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxeC-0006AZ-DQ; Thu, 17 Mar 2005 11:14:58 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 880EB17050; Thu, 17 Mar 2005 08:16:08 -0800 (PST) To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Last call comments about DTLS (mostly editorial) References: From: Eric Rescorla Date: Thu, 17 Mar 2005 08:16:08 -0800 In-Reply-To: (Pasi Eronen's message of "Thu, 17 Mar 2005 17:45:09 +0200") Message-ID: <86ll8m9rjr.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: 944ecb6e61f753561f559a497458fb4f Cc: tls@ietf.org, iesg@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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Pasi, Thanks for your comments. These seem pretty sensible. A few responses below. Pasi.Eronen@nokia.com writes: > I've started reviewing draft-rescorla-dtls-03, and > here's my first batch of comments (mostly editorial). > > (I also have a couple of more technical comments, but > I haven't finished writing them down yet. I'll send > them in a separate message in a couple of days.) We look forward to seeing them. > 1) > > Section 2 says that "While the design of the DTLS protocol does > not preclude its use in securing arbitrary datagram traffic, it > is primarily expected to secure communication based on datagram > sockets." > > What does this mean? That DTLS is primarily intended for UDP, > but could be used for other kinds of datagram transports? No, that you could use it for an DTLS tunnelled VPN a la IPsec, but we mostly expect it to be used for application-layer traffic a la TLS. > Suggested change: clarify sentence somehow. Suggested change: strike insane sentence entirely. > In Sections 4.2.1 and 4.3, "Cookie cookie<0..32>;" is not > correct, since the document does not define the type "Cookie" > (and even if it did, that would mean up to 32 individual > cookies). > > Suggested change: define "opaque Cookie<0..32>;" and change the > ClientHello/HelloVerifyRequest field to "Cookie cookie;" Good catch. > 3) > > Section 4.2.4.1: "RECOMMEND" is not a RFC 2119 keyword, > > Suggested change: "We RECOMMEND that implementations use..." --> > "Implementations SHOULD use..." Sheesh. It's recommended. > 4) > > Section 4.2.4.1: Since [TCP] defines MSL to be 2 minutes, why > not just say so? > > Suggested change "up to twice the TCP Maximum Segment Lifetime. > [TCP]" --> "up to 240 seconds (which happens to be twice the TCP > Maximum Segment Lifetime in [TCP])" I have some memory that not all real TCP systems use 2 minutes, which is why I added the indirection. > 5) > > Sections 4.2 and 5 make exaggarated claims about cookies and > denial of service attacks. > > Cookies don't "prevent denial of service attacks"; they make it > more difficult to spoof the source IP address, but that's all. > For instance, cookies alone do nothing to protect against DoS > attacks where the source IP address is not spoofed. > > Suggested change: explain that cookies give some protection > against DoS attacks from spoofed IP addresses. For attacks > where the source IP is not spoofed, the DoS situation is > the same as in ordinary TLS. Ouch. My brain was on vacation that day. > I would probably call [PHOTURIS], [RFC2401], [TCP], and [TLS] > informative references rather than normative. RFC 2401 is needed as normative because it specifies in part the anti-replay algorithm. TCP specifies MSL, and since this is a delta from TLS, we need to specify TLS as normative. > 10) > > Section numbering is a bit broken (there are two sections > numbered 4.2). And a table of contents wouldn't hurt, since > the document is anyway over 20 pages. Good catch. > 11) > > Complaints from idnits-v1.61: > > There are 11 instances of too long lines in the document, the > longest one being 8 characters in excess of 72. > There is 1 instance of lines with control characters in > the document. > It seems as if not all pages are separated by form feeds - > found 0 form feeds but 22 pages I don't know what's going on here, since I do have form feeds. :( Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Mar 17 14:05:43 2005 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 OAA07449; Thu, 17 Mar 2005 14:05:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0Nn-00030w-Bk; Thu, 17 Mar 2005 14:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0Id-0000eV-UV; Thu, 17 Mar 2005 14:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0Ic-0000eQ-B2 for tls@megatron.ietf.org; Thu, 17 Mar 2005 14:04:50 -0500 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07375 for ; Thu, 17 Mar 2005 14:04:48 -0500 (EST) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 73E6210091 for ; Thu, 17 Mar 2005 14:04:19 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29090-12 for ; Thu, 17 Mar 2005 14:04:07 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id B929110079 for ; Thu, 17 Mar 2005 14:04:07 -0500 (EST) To: tls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 17 Mar 2005 13:55:01 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/17/2005 01:54:55 PM, Serialize complete at 03/17/2005 01:54:55 PM Subject: [TLS] draft-ietf-tls-ecc-07 - errors in sample extension octets 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="===============0961934800==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multipart message in MIME format. --===============0961934800== Content-Type: multipart/alternative; boundary="=_alternative 0068FA7D85256FC7_=" This is a multipart message in MIME format. --=_alternative 0068FA7D85256FC7_= Content-Type: text/plain; charset="US-ASCII" >From section 5.1 As an example, a client that only supports secp192r1 (aka NIST P-192) and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would include an elliptic_curves extension with the following octets: 00 ?? 02 13 15 If "00 ??" is the the ExtensionType and "02 13 15" is the length and named curves, then the 2-byte length ("00 03") of the extension_data field from RFC 3546 appears to be missing from this example. Shouldn't the correct encoding be "00 ?? 00 03 02 13 15"? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 0068FA7D85256FC7_= Content-Type: text/html; charset="US-ASCII"
From section 5.1

   As an example, a client that only supports secp192r1 (aka NIST P-192)
   and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
   include an elliptic_curves extension with the following octets:

        00 ?? 02 13 15


  If "00 ??" is the the ExtensionType and "02 13 15" is the length and
 named curves, then the 2-byte length ("00 03") of the extension_data
 field from RFC 3546 appears to be missing from this example.

 Shouldn't the correct encoding be "00 ?? 00 03 02 13 15"?



-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com --=_alternative 0068FA7D85256FC7_=-- --===============0961934800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0961934800==-- From tls-bounces@ietf.org Fri Mar 18 11:05:55 2005 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 LAA21910; Fri, 18 Mar 2005 11:05:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCK3X-0002wd-Bl; Fri, 18 Mar 2005 11:10:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJyZ-0006Lp-RW; Fri, 18 Mar 2005 11:05:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJyU-0006KV-Dt for tls@megatron.ietf.org; Fri, 18 Mar 2005 11:05:22 -0500 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21876 for ; Fri, 18 Mar 2005 11:05:19 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DCJyT-0002nn-Fb; Fri, 18 Mar 2005 11:05:21 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 18 Mar 2005 11:05:21 -0500 Cc: tls@ietf.org Subject: [TLS] Last Call: 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)' 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) ' 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-04-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-07.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Mar 18 15:49:03 2005 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 PAA27148; Fri, 18 Mar 2005 15:49:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOTa-0007b6-5X; Fri, 18 Mar 2005 15:53:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOGr-0002sX-IA; Fri, 18 Mar 2005 15:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOGn-0002rf-2m; Fri, 18 Mar 2005 15:40:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25223; Fri, 18 Mar 2005 15:40:30 -0500 (EST) Message-Id: <200503182040.PAA25223@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, 18 Mar 2005 15:40:30 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-09.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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-09.txt Pages : 22 Date : 2005-3-18 This memo presents a technique for using the SRP (Secure Remote Password) protocol ([SRP], [SRP-6]) as an authentication method for the TLS (Transport Layer Security) protocol [TLS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-09.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-srp-09.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-srp-09.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-3-18153953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-18153953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Fri Mar 18 17:05:50 2005 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 RAA13776; Fri, 18 Mar 2005 17:05:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPft-0005pl-Hr; Fri, 18 Mar 2005 17:10:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPZG-0004TV-1f; Fri, 18 Mar 2005 17:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPZE-0004TQ-IJ for tls@megatron.ietf.org; Fri, 18 Mar 2005 17:03:40 -0500 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 RAA13640 for ; Fri, 18 Mar 2005 17:03:37 -0500 (EST) Received: from cdc-info.cdc.informatik.tu-darmstadt.de ([130.83.167.3] helo=mail.cdc.informatik.tu-darmstadt.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPdk-0005jK-1O for tls@ietf.org; Fri, 18 Mar 2005 17:08:21 -0500 Received: from cdc-ultra5.cdc.informatik.tu-darmstadt.de (cdc-ultra5 [130.83.167.9]) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 13FB52CA9; Fri, 18 Mar 2005 23:03:18 +0100 (MET) Received: (from moeller@localhost) by cdc-ultra5.cdc.informatik.tu-darmstadt.de (8.11.7p1+Sun/8.11.7) id j2IM3HR26716; Fri, 18 Mar 2005 23:03:17 +0100 (MET) Date: Fri, 18 Mar 2005 23:03:17 +0100 From: Bodo Moeller To: Rob Dugal Subject: Re: [TLS] draft-ietf-tls-ecc-07 - errors in sample extension octets Message-ID: <20050318230316.A26699@cdc.informatik.tu-darmstadt.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from RDugal@certicom.com on Thu, Mar 17, 2005 at 01:55:01PM -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Thu, Mar 17, 2005 at 01:55:01PM -0500, Rob Dugal wrote: > From section 5.1 > > As an example, a client that only supports secp192r1 (aka NIST P-192) > and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would > include an elliptic_curves extension with the following octets: > > 00 ?? 02 13 15 > Shouldn't the correct encoding be "00 ?? 00 03 02 13 15"? True. Thanks for pointing out the error in draft-ietf-tls-ecc-07.txt! _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Mar 22 12:10:50 2005 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 MAA06175; Tue, 22 Mar 2005 12:10:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmzN-0003MT-SY; Tue, 22 Mar 2005 12:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmtl-0007hr-QE; Tue, 22 Mar 2005 12:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmtk-0007hS-7A; Tue, 22 Mar 2005 12:10:32 -0500 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 MAA06082; Tue, 22 Mar 2005 12:10:29 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmyz-0003KP-D4; Tue, 22 Mar 2005 12:16:01 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2MHAAo14349; Tue, 22 Mar 2005 19:10:10 +0200 (EET) X-Scanned: Tue, 22 Mar 2005 19:09:11 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2MH9B8L016991; Tue, 22 Mar 2005 19:09:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00nUEnlX; Tue, 22 Mar 2005 19:08:35 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2MH8ZU02407; Tue, 22 Mar 2005 19:08:35 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Mar 2005 19:08:20 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Mar 2005 19:08:20 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Mar 2005 19:08:20 +0200 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] Last call comments about DTLS (mostly editorial) Date: Tue, 22 Mar 2005 19:08:18 +0200 Message-ID: Thread-Topic: [TLS] Last call comments about DTLS (mostly editorial) thread-index: AcUrDDUy6Pm7PBpxRIGY0Wd1jK+OqwD71R2w To: X-OriginalArrivalTime: 22 Mar 2005 17:08:20.0540 (UTC) FILETIME=[BF91BFC0:01C52F01] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, iesg@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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Eric Rescorla writes: > > Pasi, >=20 > Thanks for your comments. These seem pretty sensible.=20 > A few responses below. > > I would probably call [PHOTURIS], [RFC2401], [TCP], and=20 > > [TLS] informative references rather than normative.=20 >=20 > RFC 2401 is needed as normative because it specifies in > part the anti-replay algorithm. TCP specifies MSL, and > since this is a delta from TLS, we need to specify TLS > as normative. [TLS11] is certainly normative, but probably not [TLS]? And here comes the next batch of comments: 12) DTLS seems to assume a connection-oriented datagram transport (or at least a transport that has some idea of connections) since the transport is responsible for mapping incoming packets to correct TLS sessions (unlike, for instance, IPsec/IKE that have explicit SPI fields). Presumably for UDP, this would happen using the source and=20 destination IP addresses and port numbers. Suggested change: Describe this explicitly (perhaps somewhere around 4.1.1 would be a good place). 13) The last paragraph of Section 4.1.2.5 suggests that DTLS handles incorrect MACs differently than normal TLS 1.1 (where they're always a fatal error).=20 Suggested change: Describe this explicitly (maybe in=20 Section 4.1.2.1). 14) Section 4.2.1 says that "The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt." (where "those values" refers to the fields from ClientHello) But obviously the most important piece of data to include in the cookie calculation is the client's IP address. Even though this is somewhat obvious, perhaps it should be still mentioned explicitly. Come to think of it, Section 2.6 of draft-ietf-ipsec-ikev2-17 has some good advice about how to calculate cookies and verify them in a way that does not require server-side state. Maybe some of that text could be copied here, with suitable changes. 15) It seems that the handshake will unnecessarily fail if the client ever sends an a cookie that the server rejects (for whatever reason, e.g. restarted server process). It looks like the server could just send a new HelloVerifyRequest with a new cookie, but it won't work.=20 The client sends a new ClientHello with that cookie; the server=20 will accept the cookie this time, and the handshake will continue... until it fails when the Finished message is verified. This is because the Finished message includes both the old and new ClientHello (according to 4.2.6); and this means the server has to remember the old ClientHello (which is precisely what we tried to avoid with cookies). Suggested change: when using cookies, don't include the first ClientHello and HelloVerifyRequest when calculating the Finished message (this is the way IKEv2 handles the same problem, BTW). 16) According to Section 4.2.4, it seems both the client and the server do retransmissions based on timer. I'm not quite sure how good idea this is. Especially having the server to retransmit HelloVerifyRequest repeatedly sounds like=20 a very bad idea: the server must keep state (while the idea of cookies was to avoid state at this stage), and can be used as=20 an "amplifier". This particular problem could be fixed by just making an exception for HelloVerifyRequest, but perhaps it would be simpler to avoid timers on the server side completely=20 (whenever possible). For the full handshake, all the timer-based retransmissions could be easily done by the client (server retransmits only=20 when receiving a retransmitted message from client). For session resumption, the last handshake message is sent=20 by the client, so to make it work, DTLS would have to add=20 one more message to acknowledge that. This way, the server would not need to do timer-based retransmissions for anything else except HelloRequest messages (which, BTW, are not covered by the current state machine in Section 4.2.4). 17) It seems that Alert messages are not retransmitted at all (ChangeCipherSpec is not technically a handshake message=20 either, but that's listed as exception in 4.2.5). Does this cause some problems? (at least it should be mentioned explicitly) 18) Section 4.2.2 says that message_seq (in Handshake structure) stays the same when a message is retransmitted. What about DTLSPlaintext.sequence_number? (If the retransmissions are done by the "handshake layer", then it=20 seems logical that sequence_number would be incremented for retransmissions, since they're new messages from the record layer point of view.) 19) It seems that replay protection should not be used before ChangeCipherSpec has been sent (i.e. during handshake)? Perhaps this should be mentioned explicitly. I've got a couple of comments more that I haven't fully gone through yet; I'll send them tomorrow.. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Mar 23 07:28:21 2005 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 HAA07452; Wed, 23 Mar 2005 07:28:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE53j-0004UH-FV; Wed, 23 Mar 2005 07:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE4uy-0003eK-9p; Wed, 23 Mar 2005 07:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE4uv-0003e4-Ty; Wed, 23 Mar 2005 07:24:57 -0500 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 HAA07193; Wed, 23 Mar 2005 07:24:54 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE50N-0004Pd-U7; Wed, 23 Mar 2005 07:30:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2NCOro17701; Wed, 23 Mar 2005 14:24:54 +0200 (EET) X-Scanned: Wed, 23 Mar 2005 14:24:10 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2NCOAvi008920; Wed, 23 Mar 2005 14:24:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00reh02B; Wed, 23 Mar 2005 14:24:07 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2NCO7U01514; Wed, 23 Mar 2005 14:24:07 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Mar 2005 14:24:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Mar 2005 14:24:02 +0200 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] Last call comments about DTLS (mostly editorial) Date: Wed, 23 Mar 2005 14:18:09 +0200 Message-ID: Thread-Topic: [TLS] Last call comments about DTLS (mostly editorial) thread-index: AcUrDDUy6Pm7PBpxRIGY0Wd1jK+OqwD71R2wACdcFbA= To: , X-OriginalArrivalTime: 23 Mar 2005 12:24:02.0521 (UTC) FILETIME=[329C5C90:01C52FA3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Here's my last batch of comments about DTLS: 20) The document does a reasonably good job at making the distinction between (UDP) "datagrams" and "IP packets". However, there are a couple of instances where they are mixed up: - Section 3.2.3 says "By contrast, UDP datagrams are often=20 limited to <1500 bytes." This probably depends on your definition of "often", but many operating systems (Windows, Linux, ..) support UDP datagrams=20 of up to around 65000 bytes (which, of course, get fragmented to several IP packets). - 4.1.1 "DTLS implementations SHOULD provide a way for=20 applications to determine the value of the MTU (optimally the=20 maximum application datagram size, which is the PMTU minus the=20 DTLS per-record overhead)." I think this sentence has some kind of grammar problem... or at least I would expect that normally the maximum application=20 datagram size is the maximum UDP datagram size minus DTLS overhead,=20 but that does not depend on the PMTU. 21) Section 4.1.1 says that "If the application attempts to send=20 a record larger than the MTU, the DTLS implementation MUST either=20 generate an error or fragment the packet." It seems DTLS does not provide fragmentation for application data,=20 so the fragmentation is really done by the IP/UDP implementation,=20 not DTLS? 22) I'm not very comfortable with the way PMTUD is done. PMTUD is most useful when the transport or application can use the PMTU value to adjust how large "segments" they send. Since DTLS does not provide fragmentation for application data, the whole PMTUD stuff is useful only for the handshake messages and the small class of applications that can vary how large=20 application datagrams they supply to DTLS. (The discovery process also requires this kind of adjustments, since it involves sending packets both smaller and larger than the actual (and at that point, unknown) PMTU value. How are these adjustments done? Is the application responsible for supplying suitably sized application datagrams, or does DTLS somehow "manufacture" the packets used for PMTUD?) Furthermore, the "classical PMTU" approach described in 4.1.1.1 is seriously broken, because firewalls filter the ICMP messages. The "new PMTU algorithm" (draft-ietf-pmtud-method) does not have this problem, but it requires some kind of acknowledgements to determine which packets were lost (and thus would not work for DTLS application data). I see at least couple of ways how this could be made more logical. One possibility would be to leave PMTU to applications (draft-ietf-pmtd-method does talk about that possibility as well): applications that can adjust the segment size probably have some kind of acknowledgement structure already, and DTLS would be responsible only for setting the DF bit when requested by the application. (And the handshake messages could be handled by always fragmenting them to some small size.) Another possibility would be to add fragmentation of application data (and thus the possibility to adjust packet boundaries) to DTLS. This way, PMTU value would be taken into account by DTLS, not the application. But this would also require some kind of acknowledgements (that would be used only for PMTU adjustment, not retransmitting the data) so that the "new PMTU" algorithm would work. (I think the former approach would be simpler.) 23) Last but not least: although I've sent a long list of somewhat negative sounding comments, my overall impression of this document is quite positive. There are no major problems in the spec, and I expect that DTLS will a useful protocol in many environments. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Mar 23 14:56:02 2005 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 OAA26331; Wed, 23 Mar 2005 14:56:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC30-0000a3-Vy; Wed, 23 Mar 2005 15:01:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBuD-0006Gf-5y; Wed, 23 Mar 2005 14:52:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBu7-0006G9-HW; Wed, 23 Mar 2005 14:52:39 -0500 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 OAA25613; Wed, 23 Mar 2005 14:52:33 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBzd-0000Kv-M7; Wed, 23 Mar 2005 14:58:18 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 813281705D; Wed, 23 Mar 2005 07:08:49 -0800 (PST) To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Last call comments about DTLS (mostly editorial) References: From: Eric Rescorla Date: Wed, 23 Mar 2005 07:08:49 -0800 In-Reply-To: (Pasi Eronen's message of "Wed, 23 Mar 2005 14:18:09 +0200") Message-ID: <86ll8e4cxq.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.7 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: tls@ietf.org, iesg@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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Pasi.Eronen@nokia.com writes: > Here's my last batch of comments about DTLS: > > 20) > > The document does a reasonably good job at making the distinction > between (UDP) "datagrams" and "IP packets". However, there are a > couple of instances where they are mixed up: > > - Section 3.2.3 says "By contrast, UDP datagrams are often > limited to <1500 bytes." > > This probably depends on your definition of "often", but many > operating systems (Windows, Linux, ..) support UDP datagrams > of up to around 65000 bytes (which, of course, get fragmented > to several IP packets). Right. I should add "without fragmentation" here. > - 4.1.1 "DTLS implementations SHOULD provide a way for > applications to determine the value of the MTU (optimally the > maximum application datagram size, which is the PMTU minus the > DTLS per-record overhead)." > > I think this sentence has some kind of grammar problem... or > at least I would expect that normally the maximum application > datagram size is the maximum UDP datagram size minus DTLS overhead, > but that does not depend on the PMTU. Yes, I'll correct. > 21) > > Section 4.1.1 says that "If the application attempts to send > a record larger than the MTU, the DTLS implementation MUST either > generate an error or fragment the packet." > > It seems DTLS does not provide fragmentation for application data, > so the fragmentation is really done by the IP/UDP implementation, > not DTLS? Absolutely. > 22) > > I'm not very comfortable with the way PMTUD is done. > > PMTUD is most useful when the transport or application can use > the PMTU value to adjust how large "segments" they send. Since > DTLS does not provide fragmentation for application data, the > whole PMTUD stuff is useful only for the handshake messages and > the small class of applications that can vary how large > application datagrams they supply to DTLS. > > (The discovery process also requires this kind of adjustments, > since it involves sending packets both smaller and larger than > the actual (and at that point, unknown) PMTU value. How are > these adjustments done? Is the application responsible for > supplying suitably sized application datagrams, or does DTLS > somehow "manufacture" the packets used for PMTUD?) > > Furthermore, the "classical PMTU" approach described in 4.1.1.1 > is seriously broken, because firewalls filter the ICMP messages. > The "new PMTU algorithm" (draft-ietf-pmtud-method) does not have > this problem, but it requires some kind of acknowledgements to > determine which packets were lost (and thus would not work > for DTLS application data). > > I see at least couple of ways how this could be made more > logical. > > One possibility would be to leave PMTU to applications > (draft-ietf-pmtd-method does talk about that possibility as > well): applications that can adjust the segment size probably > have some kind of acknowledgement structure already, and DTLS > would be responsible only for setting the DF bit when requested > by the application. (And the handshake messages could be handled > by always fragmenting them to some small size.) Our approach is basically similar to this. We assume that any application which runs over UDP at all must somehow handle PMTU discovery (or send small fragments). So, as far as application data is concerned our job is not to inhibit that. This means: 1. Setting DF if required by the app (this isn't explicitly stated in the spec. I'll add it) 2. Handling ICMP messages and adjusting our estimate of PMTU so we can inform the application if the app tries to send a too large message). Ordinarily the app would do this, but of course we're consuming any such messages. (This is explicitly stated). However, this only gets half the job done because weneed to also handle handshake. Our approach is slightly different from the one you suggest: we start with the interface MTU and then back off either due to ICMP messages or due to too much timeout (see S 4.1.1). These aren't "small" messages, but the interface MTU is generally the Ethernet MTU which is the current recommendation for starting PMTU... > Last but not least: although I've sent a long list of somewhat > negative sounding comments, my overall impression of this > document is quite positive. There are no major problems in the > spec, and I expect that DTLS will a useful protocol in many > environments. Thanks! -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sun Mar 27 15:24:08 2005 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 PAA03212; Sun, 27 Mar 2005 15:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFePE-0002jc-S2; Sun, 27 Mar 2005 15:30:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFeIb-0006PZ-UP; Sun, 27 Mar 2005 15:23:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFeIa-0006PU-RO for tls@megatron.ietf.org; Sun, 27 Mar 2005 15:23:52 -0500 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 PAA03175 for ; Sun, 27 Mar 2005 15:23:51 -0500 (EST) Received: from [213.4.129.48] (helo=tfdsmtp1.mail.isp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFeOw-0002ih-Vg for tls@ietf.org; Sun, 27 Mar 2005 15:30:27 -0500 Received: from teleline.es ([10.20.4.99]) by tfdsmtp1.mail.isp (Netscape Messaging Server 4.15 tfdsmtp1 Mar 14 2002 21:29:48) with ESMTP id IE11ZF01.PXN for ; Sun, 27 Mar 2005 22:23:39 +0200 From: DANIELLLANO To: tls@ietf.org Message-ID: <8d21c8fbe5.8fbe58d21c@teleline.es> Date: Sun, 27 Mar 2005 20:23:39 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Re: [TLS] Last Call: 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)' to Proposed Standard X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 3.1 (+++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit The IESG wrote: > The IESG has received a request from the Transport Layer Security WG to > consider the following document: > > - 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) ' > 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-04-01. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-07.txt > o First, TLS may be used in performance-constrained environments > where the CPU power needed for public key operations is not > available. Could you give some example of performance-constrained environment? All the new cell phones from Nokia and Siemens have a full TLS stack, so you are not talking about using this in cell phones for sure. > o Second, pre-shared keys may be more convenient from a key > management point of view. For instance, in closed environments > where the connections are mostly configured manually in advance, > it may be easier to configure a PSK than to use certificates. > Another case is when the parties already have a mechanism for > setting up a shared secret key, and that mechanism could be used > to "bootstrap" a key for authenticating a TLS connection. Why instead of using certificates you just put the public keys of the peers and trust them? If you start using a shared symmetric key for lots of peers you always risk that if one attacker gets the key everything is lost, but if you use a PKI you don't have this problem as the attacker would have to get the private keys of all the peers. I'm totally opposed to this becoming a standard. It just calls for problems. Please, don't take steps back. It was hard to get here. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Mar 28 11:29:45 2005 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 LAA08397; Mon, 28 Mar 2005 11:29:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxE8-0003Qc-Vt; Mon, 28 Mar 2005 11:36:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwnN-0000DB-5G; Mon, 28 Mar 2005 11:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwnI-0000CN-7h; Mon, 28 Mar 2005 11:08:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01788; Mon, 28 Mar 2005 11:08:45 -0500 (EST) Message-Id: <200503281608.LAA01788@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Mar 2005 11:08:44 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-08.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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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-08.txt Pages : 33 Date : 2005-3-25 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-08.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-08.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-08.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-3-28113434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-28113434.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Thu Mar 31 00:58:22 2005 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 AAA13136; Thu, 31 Mar 2005 00:58:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGsoI-0001xc-Qy; Thu, 31 Mar 2005 01:05:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGsf9-0005fI-1I; Thu, 31 Mar 2005 00:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGsf5-0005eL-PV for tls@megatron.ietf.org; Thu, 31 Mar 2005 00:56:12 -0500 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 AAA12871 for ; Thu, 31 Mar 2005 00:56:09 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGsm9-0001tn-Lc for tls@ietf.org; Thu, 31 Mar 2005 01:03:29 -0500 Received: by rproxy.gmail.com with SMTP id a41so299965rng for ; Wed, 30 Mar 2005 21:56:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=g6ZQPGk5P6PIKQcxaScG7bwYGvvoRtHmE2/+X1727rgLRib1NF3Yvja5+dYKI5Tw5ADErdCvoFDEZG34XfoCa3MflmfkJLll59JLMUobnaF5q13Zodj+kv9k538VNk/84DtbpxHNgWqe+TXvEo+ZluwK+x1ErqP1GdTBFJmUC4w= Received: by 10.38.87.21 with SMTP id k21mr1220038rnb; Wed, 30 Mar 2005 21:56:10 -0800 (PST) Received: by 10.38.152.67 with HTTP; Wed, 30 Mar 2005 21:56:10 -0800 (PST) Message-ID: <76443a3e050330215618764cd8@mail.gmail.com> Date: Thu, 31 Mar 2005 00:56:10 -0500 From: Lakshminath Dondeti To: pasi.eronen@nokia.com, Hannes.Tschofenig@siemens.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: gen-art@alvestrand.no, tls@ietf.org Subject: [TLS] Review of draft-ietf-tls-psk-07.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lakshminath Dondeti 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit I am reviewing this I-D as part of the Gen-Art IETF LC review process. Summary -------------- This draft is basically ready for publication, but has nits that should be fixed before publication. idnits output ------------------ -bash-2.05b$ ./idnits --verbose draft-ietf-tls-psk-07.txt idnits 1.61 draft-ietf-tls-psk-07.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : * The document seems to lack an Authors' Addresses Section. Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. You might ignore this, as the script seems to have missed the Authors' and Contributors' Addresses section in the I-D. * The document is more than 15 pages and seems to lack a Table of Contents. Please include a table of contents. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Review ---------- I followed the WGLC discussion on this draft, and had a chance to review Pasi's summary of the issues and resolutions. This draft has received the due review in the WG. However, I do have some additional editorial comments to further improve the I-D. 1. The motivation might need to be revised. The first reason seems to be at odds with the RSA_PSK ciphersuites and DKE_PSK ciphersuites. The second reason makes sense in that the proposed protocol provides a solution for environments where PSKs are already in place. (On the issue of small devices and performance constraints, with Moore's law, performance constraints of today might be invalid in a few years. Of course, with Moore's law the requisite key lengths etc., also increase. Then comes the question of how PSKs compare with public key operations with shorter keys. It might be worthwhile for this I-D, and the eventual RFC to include such a discussion). 2. In the last paragraph of Section 1, delete with in "with RSA_PSK key exchange algorithm" replace "mutual" with "client" 3. The Applicability Statement needs work. Please rewrite the applicability statement to clearly state the intended use alone. The alternatives, self-signed certs and SRP ciphersuites can go elsewhere, perhaps in the Security Considerations section. 4. Replace all occurrences of "an uint16" with "a uint16" 5. On "See [8] for a more detailed rationale.": Considering [8] is an email, please summarize the rationale in the I-D for completeness. 6. In Page 6, please add the following to the second to last paragraph. PreMaster Secret = length-of-Z-in-octets || Z || length-of-PSK-in-octets || PSK where the "length" fields are of type unit16 or something like that. 7. In Section 4, the paragraph starting with "The EncryptedPreMasterSecret ..." needs some work. Perhaps including a line similar to the one suggested above might help. PreMasterSecret = length-of-EncryptedPreMasterSecret-in-octets || EncryptedPreMasterSecrtet || length-of-PSK || PSK 8. In Section 7.2, it might be worthwhile to include a passphrase to PSK generation function for easy reference. 9. As noted earlier, please suggest alternatives to PSKs in Section 7.2 or in a separate subsection in Section 7. That section should say something along the lines of: PSKs should only be used after other alternatives such as xx (self-signed certs?) and yy (TLS-SRP?) have been ruled out either due to performance constraints or deployment constraints etc. best regards, Lakshminath _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls