From mailman-bounces@ietf.org Sat Jan 1 05:27:15 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 FAA06167 for ; Sat, 1 Jan 2005 05:27:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkgfM-0006b3-2k for tls-archive@ietf.org; Sat, 01 Jan 2005 05:39:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg6H-0002bK-Vi for tls-archive@ietf.org; Sat, 01 Jan 2005 05:03:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:50 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for tls-archive@ietf.org: List Password // URL ---- -------- tls@lists.ietf.org akviiw https://www1.ietf.org/mailman/options/tls/tls-archive%40ietf.org From tls-bounces@ietf.org Mon Jan 3 12:18:37 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 MAA14905; Mon, 3 Jan 2005 12:18:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClW2q-0000dK-W5; Mon, 03 Jan 2005 12:31:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVoN-0006Bp-N3; Mon, 03 Jan 2005 12:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVao-0008Mz-6g for tls@megatron.ietf.org; Mon, 03 Jan 2005 12:02:06 -0500 Received: from nik.gnutls.org (foobar@dyn203.kif6.nas.panafonet.gr [62.74.5.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13686 for ; Mon, 3 Jan 2005 12:01:59 -0500 (EST) Received: from [127.0.0.1] (helo=localhost ident=foobar) by nik.gnutls.org with esmtp (Exim 4.34) id 1Cls0V-0000cR-9O for tls@lists.ietf.org; Tue, 04 Jan 2005 18:58:07 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Tue, 4 Jan 2005 18:58:06 +0200 User-Agent: KMail/1.7.1 References: <005f01c4ee85$03058150$c500a8c0@simon> In-Reply-To: <005f01c4ee85$03058150$c500a8c0@simon> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501041858.07038.nmav@gnutls.org> 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: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Thursday 30 December 2004 17:34, Simon Blake-Wilson wrote: > Hi folks, > > We just posted an internet-draft updating the extensions RFC to deal with > the issue of which documents can define new extensions - the current RFC > allows only standards track RFCs while this draft allows any RFC based on > IETF consensus (which basically means IESG review). Since it is being updated I'd suggest to increase the number of valid values for MaxFragmentLength. I think values for up to 2^16 would be ok. -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 3 12:39:17 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 MAA17202; Mon, 3 Jan 2005 12:39:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWN1-0001JV-Gy; Mon, 03 Jan 2005 12:51:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClW7g-0006cW-2p; Mon, 03 Jan 2005 12:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClVtA-0000dH-BI for tls@megatron.ietf.org; Mon, 03 Jan 2005 12:21:04 -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 MAA15142 for ; Mon, 3 Jan 2005 12:21:01 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClW5M-0000fs-Bh for tls@ietf.org; Mon, 03 Jan 2005 12:33:40 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id D62C917029; Mon, 3 Jan 2005 09:20:46 -0800 (PST) To: Nikos Mavrogiannopoulos Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt References: <005f01c4ee85$03058150$c500a8c0@simon> <200501041858.07038.nmav@gnutls.org> From: EKR Date: Mon, 03 Jan 2005 09:20:46 -0800 In-Reply-To: <200501041858.07038.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 4 Jan 2005 18:58:06 +0200") Message-ID: <864qhyo2dt.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: 2.0 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Nikos Mavrogiannopoulos writes: > On Thursday 30 December 2004 17:34, Simon Blake-Wilson wrote: >> Hi folks, >> >> We just posted an internet-draft updating the extensions RFC to deal with >> the issue of which documents can define new extensions - the current RFC >> allows only standards track RFCs while this draft allows any RFC based on >> IETF consensus (which basically means IESG review). > Since it is being updated I'd suggest to increase the number of valid values > for MaxFragmentLength. I think values for up to 2^16 would be ok. That seems like it might create an interop problem, no? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 3 13:02:20 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 NAA20619; Mon, 3 Jan 2005 13:02:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWjJ-00022l-SJ; Mon, 03 Jan 2005 13:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWON-0005Eu-F5; Mon, 03 Jan 2005 12:53:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWM8-0004PM-PA for tls@megatron.ietf.org; Mon, 03 Jan 2005 12:51:00 -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 MAA18828 for ; Mon, 3 Jan 2005 12:50:58 -0500 (EST) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWYI-0001hh-BP for tls@ietf.org; Mon, 03 Jan 2005 13:03:37 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 6CAD9164B98 for ; Mon, 3 Jan 2005 18:50:56 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40127-01 for ; Mon, 3 Jan 2005 18:50:53 +0100 (CET) Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by smtp2.enst.fr (Postfix) with ESMTP id 0F6BD164B5A for ; Mon, 3 Jan 2005 18:50:52 +0100 (CET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with ESMTP id j03Hoqg22479 for ; Mon, 3 Jan 2005 18:50:52 +0100 (MET) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Mon, 3 Jan 2005 18:50:52 +0100 (MET) Message-ID: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> In-Reply-To: <200501041858.07038.nmav@gnutls.org> References: <005f01c4ee85$03058150$c500a8c0@simon> <200501041858.07038.nmav@gnutls.org> Date: Mon, 3 Jan 2005 18:50:52 +0100 (MET) Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt To: tls@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos > Since it is being updated I'd suggest to increase the number of valid > values > for MaxFragmentLength. I think values for up to 2^16 would be ok. Larger than 2^14?... OTOH, is it possible to more explain the following text? paragraph 2.3 ... Nonetheless "server initiated" extensions may be provided in the future within this framework by requiring the client to first send an empty extension to indicate that it supports a particular extension." Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 3 13:24:39 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 NAA22734; Mon, 3 Jan 2005 13:24:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClX4u-0002as-7C; Mon, 03 Jan 2005 13:37:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWla-00055Y-3H; Mon, 03 Jan 2005 13:17:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClW5T-0005rP-1Y for tls@megatron.ietf.org; Mon, 03 Jan 2005 12:33:47 -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 MAA16623 for ; Mon, 3 Jan 2005 12:33:44 -0500 (EST) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWHc-00017S-C3 for tls@ietf.org; Mon, 03 Jan 2005 12:46:23 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id B37DE164FF7; Mon, 3 Jan 2005 18:33:35 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39312-06; Mon, 3 Jan 2005 18:33:32 +0100 (CET) Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by smtp2.enst.fr (Postfix) with ESMTP id 201EF164F4D; Mon, 3 Jan 2005 18:33:31 +0100 (CET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with ESMTP id j03HXVg22150; Mon, 3 Jan 2005 18:33:31 +0100 (MET) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Mon, 3 Jan 2005 18:33:31 +0100 (MET) Message-ID: <62509.127.0.0.1.1104773611.squirrel@127.0.0.1> In-Reply-To: <200501041858.07038.nmav@gnutls.org> References: <005f01c4ee85$03058150$c500a8c0@simon> <200501041858.07038.nmav@gnutls.org> Date: Mon, 3 Jan 2005 18:33:31 +0100 (MET) Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt To: "Nikos Mavrogiannopoulos" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 03 Jan 2005 13:17:17 -0500 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.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos > Since it is being updated I'd suggest to increase the number of valid > values > for MaxFragmentLength. I think values for up to 2^16 would be ok. Larger than 2^14?... Is it possible to more explain the following text? paragraph 2.3 ... Nonetheless "server initiated" extensions may be provided in the future within this framework by requiring the client to first send an empty extension to indicate that it supports a particular extension." Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 3 17:19:05 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 RAA28282; Mon, 3 Jan 2005 17:19:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clajo-0004Rj-RW; Mon, 03 Jan 2005 17:31:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaFP-0005PU-3r; Mon, 03 Jan 2005 17:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZwt-0004vw-AP for tls@megatron.ietf.org; Mon, 03 Jan 2005 16:41:11 -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 QAA21987 for ; Mon, 3 Jan 2005 16:41:09 -0500 (EST) Received: from tomts36-srv.bellnexxia.net ([209.226.175.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cla8w-0002Yp-Po for tls@ietf.org; Mon, 03 Jan 2005 16:53:50 -0500 Received: from simon ([64.231.176.200]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050103214058.HWNQ1694.tomts36-srv.bellnexxia.net@simon>; Mon, 3 Jan 2005 16:40:58 -0500 From: "Simon Blake-Wilson" To: "'EKR'" , "'Nikos Mavrogiannopoulos'" Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Mon, 3 Jan 2005 16:40:35 -0500 Message-ID: <009901c4f1dc$df45a8c0$c500a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <864qhyo2dt.fsf@romeo.rtfm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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: , Content-Type: multipart/mixed; boundary="===============1204777203==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. --===============1204777203== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0095_01C4F1B2.F218A2B0" This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C4F1B2.F218A2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that this might create an interop problem ... And I don't think we want to get into changes that break backwards compatibility here. BTW ... Am I missing something ... Values up to 2^16 would mean that you can now negotiate to allow longer packets rather than fragment to require shorter packets, wouldn't it? Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of EKR > Sent: Monday, January 03, 2005 12:21 PM > To: Nikos Mavrogiannopoulos > Cc: tls@ietf.org > Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt > > > Nikos Mavrogiannopoulos writes: > > > On Thursday 30 December 2004 17:34, Simon Blake-Wilson wrote: > >> Hi folks, > >> > >> We just posted an internet-draft updating the extensions > RFC to deal > >> with the issue of which documents can define new extensions - the > >> current RFC allows only standards track RFCs while this > draft allows > >> any RFC based on IETF consensus (which basically means > IESG review). > > Since it is being updated I'd suggest to increase the > number of valid > > values > > for MaxFragmentLength. I think values for up to 2^16 would be ok. > > That seems like it might create an interop problem, no? > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_0095_01C4F1B2.F218A2B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJDCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR5MIID4qADAgECAhBQvP6CEfX+K7FeZPKFUBttMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDIyNTAwMDAw MFoXDTA1MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh81iFspBl ua1ZyvbQpRCm13CI/+nUsztcRWpIVVcKLknRA2btu394xi3q/Qmw+hW2QkZmaeVsvULMrNXr171x s/jkxJ4noM8Xx1HPtMKZOeLr1A3IcSpZO5ZNePAoPPLAjGYxb3wJemzG3dBDhZ/BUWiwIMqMhju5 gG4TQoytKwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMG A1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEAFDIEV02jprRnMwLnqOhTeQxHgtI/UHiybRDLo4dba4laCyzJHboTBDSrAs6f LD1+LfBYAgKgAgfTtFPezb2+qQP9uw/5JwnzXE9GlQKX73bafTHJ1qqDhUTQQK80CRxDrvX3y/qt VZDFPONmFhoxMWE9dzQRrknPZVEqCu5KikExggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAbbTAJBgUrDgMCGgUAoIICsjAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAxMDMyMTQwMzRaMCMGCSqG SIb3DQEJBDEWBBQRlOoI/W36yyDjOLbh3wuTMaYzWjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBQvP6CEfX+K7FeZPKFUBttMIH0BgsqhkiG9w0BCRACCzGB 5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAb bTANBgkqhkiG9w0BAQEFAASBgHAHu6tXNrCM2D5PkqsKRTPVWFArMfsmD9zdNTc6p6YcuiBu7aHA 1i+v+2f+ILmq9ChV9G9h9bc6POSip6WplF89iqd+V0ZW5RerS6Hk99Cmdvc+qwy+LNHlFgvC211l HexyO90hatlXfFcwTap/gm8nKsjwtS4I97CA+VRyFWuyAAAAAAAA ------=_NextPart_000_0095_01C4F1B2.F218A2B0-- --===============1204777203== 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 --===============1204777203==-- From tls-bounces@ietf.org Mon Jan 3 17:19:34 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 RAA28314; Mon, 3 Jan 2005 17:19:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClakI-0004S3-Sb; Mon, 03 Jan 2005 17:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaFp-0006Db-06; Mon, 03 Jan 2005 17:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cla01-0006qE-5M for tls@megatron.ietf.org; Mon, 03 Jan 2005 16:44:25 -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 QAA22980 for ; Mon, 3 Jan 2005 16:44:23 -0500 (EST) Received: from tomts16.bellnexxia.net ([209.226.175.4] helo=tomts16-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClaCC-0002uN-Ld for tls@ietf.org; Mon, 03 Jan 2005 16:57:04 -0500 Received: from simon ([64.231.176.200]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050103214420.MHHH1836.tomts16-srv.bellnexxia.net@simon>; Mon, 3 Jan 2005 16:44:20 -0500 From: "Simon Blake-Wilson" To: , Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Mon, 3 Jan 2005 16:44:04 -0500 Message-ID: <00a101c4f1dd$5b8f4940$c500a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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="===============0970752609==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. --===============0970752609== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009C_01C4F1B3.6F0A6A10" This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C4F1B3.6F0A6A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To my mind it means that new extensions cannot specify that the server sends a particular extension type unless the client has included the same extension type in the client hello. But new extensions can get round this by having the client send an empty extension of that type, thereby allowing the server to respond. This text has not changed from RFC3546, but if you think it should be clarified, please suggest some text! Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of badra@infres.enst.fr > Sent: Monday, January 03, 2005 12:51 PM > To: tls@ietf.org > Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt > > > Nikos Mavrogiannopoulos > > Since it is being updated I'd suggest to increase the > number of valid > > values for MaxFragmentLength. I think values for up to 2^16 > would be > > ok. > > Larger than 2^14?... > > OTOH, is it possible to more explain the following text? > > paragraph 2.3 > ... > Nonetheless "server initiated" extensions may be provided in > the future within this framework by requiring the client to > first send an empty extension to indicate that it supports a > particular extension." > > Badra > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_009C_01C4F1B3.6F0A6A10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJDCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR5MIID4qADAgECAhBQvP6CEfX+K7FeZPKFUBttMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDIyNTAwMDAw MFoXDTA1MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh81iFspBl ua1ZyvbQpRCm13CI/+nUsztcRWpIVVcKLknRA2btu394xi3q/Qmw+hW2QkZmaeVsvULMrNXr171x s/jkxJ4noM8Xx1HPtMKZOeLr1A3IcSpZO5ZNePAoPPLAjGYxb3wJemzG3dBDhZ/BUWiwIMqMhju5 gG4TQoytKwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMG A1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEAFDIEV02jprRnMwLnqOhTeQxHgtI/UHiybRDLo4dba4laCyzJHboTBDSrAs6f LD1+LfBYAgKgAgfTtFPezb2+qQP9uw/5JwnzXE9GlQKX73bafTHJ1qqDhUTQQK80CRxDrvX3y/qt VZDFPONmFhoxMWE9dzQRrknPZVEqCu5KikExggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAbbTAJBgUrDgMCGgUAoIICsjAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAxMDMyMTQ0MDNaMCMGCSqG SIb3DQEJBDEWBBRxk37cE7s54rx9+sj0cNxf8XBxVzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBQvP6CEfX+K7FeZPKFUBttMIH0BgsqhkiG9w0BCRACCzGB 5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAb bTANBgkqhkiG9w0BAQEFAASBgA3IxXQw3LJzm3RdvJhLqoHathr45wqIJK1sxVcm7S5UccTqmS44 1svkwXjBQEi+mfhW84fvV9eFzL2Z0Wl1SgwbnoOEr7wNzS0snB+4SPZ7LzgsE0HV57JnYhpzUct4 WZ0dRvxOwHwD8HPEWesZgB+1lJTifF1q/zXlWIenkPRqAAAAAAAA ------=_NextPart_000_009C_01C4F1B3.6F0A6A10-- --===============0970752609== 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 --===============0970752609==-- From tls-bounces@ietf.org Mon Jan 3 19:46:47 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 TAA10315; Mon, 3 Jan 2005 19:46:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cld2l-0007hQ-T8; Mon, 03 Jan 2005 19:59:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClcoP-0001UO-Uk; Mon, 03 Jan 2005 19:44:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClcaC-0003Zr-3B for tls@megatron.ietf.org; Mon, 03 Jan 2005 19:29:56 -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 TAA09070 for ; Mon, 3 Jan 2005 19:29:53 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClcmP-0007F7-5i for tls@ietf.org; Mon, 03 Jan 2005 19:42:36 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j040TpVu026346 for ; Mon, 3 Jan 2005 17:29:51 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9R00IBPO1R84@edgemail1.Central.Sun.COM> for tls@ietf.org; Mon, 03 Jan 2005 17:29:51 -0700 (MST) Received: from [129.146.72.235] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9R0050OO1QUK@mail.sun.net> for tls@ietf.org; Mon, 03 Jan 2005 17:29:51 -0700 (MST) Date: Mon, 03 Jan 2005 16:29:57 -0800 From: Vipul Gupta Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt In-reply-to: To: EKR Message-id: <41D9E385.3030204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) References: <20041023055852.90063718B@sierra.rtfm.com> <200410270758.20372.nmav@gnutls.org> <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT 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: 4.2 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Hi Eric, Now that RFC 3546-bis is out with changes that allow informational RFCs (developed with WG consensus) to define new TLS extensions, can we proceed in parallel with a working group last call on draft-ietf-tls-ecc-07.txt? thank you, vipul On 11/2/04, Eric Rescorla wrote: > You'd need to create a new document to revise 3546 and get WG > consensus behind it. The documents should proceed in parallel. > > WG members: > I'd like to get opinions on this proposed change to RFC 3546. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 3 23:40:32 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 XAA23812; Mon, 3 Jan 2005 23:40:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clgh2-0003Xr-Id; Mon, 03 Jan 2005 23:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClgNC-0004eP-4s; Mon, 03 Jan 2005 23:32:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClgMT-00043h-5p for tls@megatron.ietf.org; Mon, 03 Jan 2005 23:32:01 -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 XAA23241 for ; Mon, 3 Jan 2005 23:31:58 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 48053100D8; Mon, 3 Jan 2005 23:31:30 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 0C92E10161 for ; Mon, 3 Jan 2005 23:31:30 -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 32222-37 for ; Mon, 3 Jan 2005 23:31:18 -0500 (EST) Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by mail.ca.certicom.com (Postfix) with ESMTP id 81F53100D8 for ; Mon, 3 Jan 2005 23:31:17 -0500 (EST) Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.12.10/3.7W-NTTSOFT-SUR2.0) id j044V6B7024712; Tue, 4 Jan 2005 13:31:06 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from helene.ms.ntts.co.jp (localhost [127.0.0.1]) by mail26.silk.ntts.co.jp (8.12.10/8.12.10/mail26-5.3) with ESMTP id j044V6Fc018696; Tue, 4 Jan 2005 13:31:06 +0900 (JST) Received: from [127.0.0.1] (green [10.8.3.17]) by helene.ms.ntts.co.jp (Postfix) with ESMTP id 55D691FFC26; Tue, 4 Jan 2005 13:31:05 +0900 (JST) Date: Tue, 04 Jan 2005 13:31:05 +0900 From: KATO Akihiro To: Kais.Belgaied@Sun.COM Subject: Re: [TLS] Last Call: 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard In-Reply-To: <41D25F20.6070503@Sun.COM> References: <41D25F20.6070503@Sun.COM> Message-Id: <20050104132137.8B77.AKATO@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] Content-Transfer-Encoding: 7bit Cc: ietf-tls@lists.certicom.com, 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.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi Kais. Cipher suites number on TLS is not controled by IANA. When we posted draft-ietf-tls-camellia-06, numbers contiguously after the *_CAMELLIA_128_* was held by draft-ietf-tls-ecc-06 and other draft. On Wed, 29 Dec 2004 15:39:12 +0800 Kais Belgaied wrote: > (sorry for the nit-picking) > the ({0x00,0x47}-{0x00,0x4D}) range seems available. Any reason for not choosing > the *_CAMELLIA_256_* numbers contiguously after the *_CAMELLIA_128_* ones? > > Kais. > > The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG to > > consider the following document: > > > > - 'Addition of Camellia Ciphersuites to 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-01-10. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-06.txt > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls -- - KATO Akihiro + NTT Software Corporation +81 45 212 7934 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 04:15:37 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 EAA25352; Tue, 4 Jan 2005 04:15:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClkzH-0000QJ-4J; Tue, 04 Jan 2005 04:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClklV-0003lD-Dk; Tue, 04 Jan 2005 04:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClkjU-000395-5h; Tue, 04 Jan 2005 04:12:04 -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 EAA25183; Tue, 4 Jan 2005 04:12:02 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clkvn-0000LL-Lh; Tue, 04 Jan 2005 04:24:49 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j049BnY22241; Tue, 4 Jan 2005 11:11:51 +0200 (EET) X-Scanned: Tue, 4 Jan 2005 11:11:32 +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 j049BWCF006627; Tue, 4 Jan 2005 11:11:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QlQj8P; Tue, 04 Jan 2005 11:11:30 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 j049BSU16695; Tue, 4 Jan 2005 11:11:29 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jan 2005 11:11:11 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jan 2005 11:11:11 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jan 2005 11:11:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Tue, 4 Jan 2005 11:11:10 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783F2@esebe056.ntc.nokia.com> Thread-Topic: Re: Last Call: 'Addition of SEED Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard Thread-Index: AcTyPVSin/lIo21dTaOLErUHlX+2tw== To: , X-OriginalArrivalTime: 04 Jan 2005 09:11:10.0984 (UTC) FILETIME=[55377080:01C4F23D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: jilee@kisa.or.kr, jhyoon@kisa.or.kr, jiinii@kisa.or.kr Subject: [TLS] Re: Last Call: 'Addition of SEED Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable This draft defines the following ciphersuites (Section 2): CipherSuite TLS_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x60}; CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA =3D { 0x00,0x61); CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x62); CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA =3D { 0x00,0x63}; CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x64}; CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA =3D { 0x00,0x65} These numbers (0x00,0x60..0x65) are already used by various "EXPORT1024" ciphersuites (expired I-D draft-ietf-tls-56-bit- ciphersuites). Although that draft never became an RFC, these=20 ciphersuites are quite widely implemented (in e.g. OpenSSL,=20 Netscape/Mozilla NSS, and some Microsoft and Cisco products),=20 so reusing the same numbers is probably not a good idea.=20 This conflict was pointed out a while ago on the TLS WG=20 mailing list, but apparently the authors didn't notice it. Based on the list of various TLS numbers I've collected (http://people.nokia.net/~pasi/tls-numbers.txt), I'd=20 suggest renumbering these ciphersuites to 0x00,0x96..0x9B. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 09:01:20 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 JAA12221; Tue, 4 Jan 2005 09:01:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClpRp-0005pQ-0V; Tue, 04 Jan 2005 09:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClpCp-0004ZF-W7; Tue, 04 Jan 2005 08:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClpBy-0004E8-FR for tls@megatron.ietf.org; Tue, 04 Jan 2005 08:57:46 -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 IAA11942 for ; Tue, 4 Jan 2005 08:57:44 -0500 (EST) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClpOL-0005lC-KQ for tls@ietf.org; Tue, 04 Jan 2005 09:10:34 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 445D6164B7C; Tue, 4 Jan 2005 14:57:42 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92572-03; Tue, 4 Jan 2005 14:57:39 +0100 (CET) Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by smtp2.enst.fr (Postfix) with ESMTP id E3C62164B2C; Tue, 4 Jan 2005 14:57:38 +0100 (CET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with ESMTP id j04Dvbg16009; Tue, 4 Jan 2005 14:57:38 +0100 (MET) Received: from tripolis.enst.fr ([137.194.192.26]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Tue, 4 Jan 2005 14:57:38 +0100 (MET) Message-ID: <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> In-Reply-To: <00a101c4f1dd$5b8f4940$c500a8c0@simon> References: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> <00a101c4f1dd$5b8f4940$c500a8c0@simon> Date: Tue, 4 Jan 2005 14:57:38 +0100 (MET) Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt To: "Simon Blake-Wilson" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.3 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Hi Simon, It may be sufficient to add somewhere in the text that an empty extension has no type and that, if the client receives one or more extensions and i= t wants to negotiate them, it must re-send an extended client hello with th= e selected extensions. Best regards, Badra > To my mind it means that new extensions cannot specify that the server > sends a particular extension type unless the client has included the sa= me > extension type in the client hello. But new extensions can get round th= is > by having the client send an empty extension of that type, thereby > allowing the server to respond. > > This text has not changed from RFC3546, but if you think it should be > clarified, please suggest some text! > > Best regards. Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 12:34:53 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 MAA00294; Tue, 4 Jan 2005 12:34:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClsmW-0002AR-Jd; Tue, 04 Jan 2005 12:47:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClsXG-0001ax-VM; Tue, 04 Jan 2005 12:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClsQ7-0007KA-Md for tls@megatron.ietf.org; Tue, 04 Jan 2005 12:24:35 -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 MAA28662 for ; Tue, 4 Jan 2005 12:24:32 -0500 (EST) Received: from tomts22.bellnexxia.net ([209.226.175.184] helo=tomts22-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClscU-0001nz-GD for tls@ietf.org; Tue, 04 Jan 2005 12:37:25 -0500 Received: from simon ([64.231.78.130]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050104172423.BMLL1919.tomts22-srv.bellnexxia.net@simon>; Tue, 4 Jan 2005 12:24:23 -0500 From: "Simon Blake-Wilson" To: Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Tue, 4 Jan 2005 12:21:54 -0500 MIME-Version: 1.0 Message-ID: <001f01c4f281$e9fe32f0$c500a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 2.2 (++) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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: , Content-Type: multipart/mixed; boundary="===============0970490091==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This is a multi-part message in MIME format. --===============0970490091== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_001B_01C4F257.F6D61BC0"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C4F257.F6D61BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Badra, I think your reading is still different from mine. Perhaps this means the text could use clarification. In my thinking, an empty extension is not "type-less". New extensions, say of type x, that are essentially server driven would require clients to include an extension of type x in the client hello with extension data empty. The server can then include an extension of type x in the server hello and put any relevant info about the extension in the extension data. Of course, this limits the amount of "negotiation" that can occur between the server and the client. To clarify this, I'd propose the following rewording of the paragraph: "Nonetheless "server initiated" extensions may be provided in the future within this framework - such an extension, say of type x, would require the client to first send an extension of type x in the (extended) client hello with empty extension_data to indicate that it supports the extension type." Best regards. Simon > -----Original Message----- > From: badra@infres.enst.fr [mailto:badra@infres.enst.fr] > Sent: Tuesday, January 04, 2005 8:58 AM > To: Simon Blake-Wilson > Cc: tls@ietf.org > Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt > > > Hi Simon, > > It may be sufficient to add somewhere in the text that an > empty extension has no type and that, if the client receives > one or more extensions and it wants to negotiate them, it > must re-send an extended client hello with the selected extensions. > > Best regards, > Badra > > > To my mind it means that new extensions cannot specify that > the server > > sends a particular extension type unless the client has > included the > > same extension type in the client hello. But new extensions can get > > round this by having the client send an empty extension of > that type, > > thereby allowing the server to respond. > > > > This text has not changed from RFC3546, but if you think it > should be > > clarified, please suggest some text! > > > > Best regards. Simon > > > ------=_NextPart_000_001B_01C4F257.F6D61BC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJDCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR5MIID4qADAgECAhBQvP6CEfX+K7FeZPKFUBttMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDIyNTAwMDAw MFoXDTA1MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh81iFspBl ua1ZyvbQpRCm13CI/+nUsztcRWpIVVcKLknRA2btu394xi3q/Qmw+hW2QkZmaeVsvULMrNXr171x s/jkxJ4noM8Xx1HPtMKZOeLr1A3IcSpZO5ZNePAoPPLAjGYxb3wJemzG3dBDhZ/BUWiwIMqMhju5 gG4TQoytKwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMG A1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEAFDIEV02jprRnMwLnqOhTeQxHgtI/UHiybRDLo4dba4laCyzJHboTBDSrAs6f LD1+LfBYAgKgAgfTtFPezb2+qQP9uw/5JwnzXE9GlQKX73bafTHJ1qqDhUTQQK80CRxDrvX3y/qt VZDFPONmFhoxMWE9dzQRrknPZVEqCu5KikExggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAbbTAJBgUrDgMCGgUAoIICsjAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAxMDQxNzIxNDlaMCMGCSqG SIb3DQEJBDEWBBSOzGtZuK0DIPSc8Uq6pgK7yQoptDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBQvP6CEfX+K7FeZPKFUBttMIH0BgsqhkiG9w0BCRACCzGB 5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAb bTANBgkqhkiG9w0BAQEFAASBgBPo+YlZyP+4k2k9+Ty13MvXxG7ubI+TQIY1yOYmYCHEhMlvf7j0 vLJcwenMzk+k3jnJbF7zztb/bHeGHiWPuhZ43of7En5JW7gyqb4Yr8GWBogsINGwFyH1ftjJiAPp cyD6lL3nUpGbhzrCGXuAFfH4gSMBmTKSGagGcijCUd4KAAAAAAAA ------=_NextPart_000_001B_01C4F257.F6D61BC0-- --===============0970490091== 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 --===============0970490091==-- From tls-bounces@ietf.org Tue Jan 4 14:16: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 OAA09445; Tue, 4 Jan 2005 14:16:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CluNG-0004sM-AP; Tue, 04 Jan 2005 14:29:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clu8h-000346-74; Tue, 04 Jan 2005 14:14:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CltdF-000584-8M; Tue, 04 Jan 2005 13:42:13 -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 NAA06439; Tue, 4 Jan 2005 13:42:12 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cltpe-0003v5-0A; Tue, 04 Jan 2005 13:55:03 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j04Ifevk015245; Tue, 4 Jan 2005 13:41:40 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j04IfeAl238516; Tue, 4 Jan 2005 13:41:40 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j04IfepR011472; Tue, 4 Jan 2005 13:41:40 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.211.15]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j04IfeQv011457; Tue, 4 Jan 2005 13:41:40 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id j04Ig6th014837; Tue, 4 Jan 2005 13:42:07 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j04Ig5mH014833; Tue, 4 Jan 2005 13:42:06 -0500 Message-Id: <200501041842.j04Ig5mH014833@rotala.raleigh.ibm.com> To: Pasi.Eronen@nokia.com In-Reply-To: Message from Pasi.Eronen@nokia.com of "Tue, 04 Jan 2005 11:11:10 +0200." <125EA890549C8641A72F3809CB80DCCD1783F2@esebe056.ntc.nokia.com> Date: Tue, 04 Jan 2005 13:42:05 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Tue, 04 Jan 2005 14:14:42 -0500 Cc: jiinii@kisa.or.kr, jilee@kisa.or.kr, jhyoon@kisa.or.kr, tls@ietf.org, iesg@ietf.org Subject: [TLS] Re: Last Call: 'Addition of SEED Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard 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: 50a516d93fd399dc60588708fd9a3002 Caveat: I know nothing about TLS registries, per se. However, more generally, if keeping track of numbers that are in use is important enough (e.g., to prevent interoperability problems) that someone has to maintain a private registry, that strongly suggests to me that IANA should be maintaining such a registry. That is why IANA exists, after all. Having IANA maintain the registry doesn't mean it has to be hard to obtain numbers. They could be assigned FCFS, if that is appropriate. Indeed, Pasi's page could be used as the initial starting point with IANA handling all future registrations. What am I missing? Thomas Pasi.Eronen@nokia.com writes: > This draft defines the following ciphersuites (Section 2): > CipherSuite TLS_RSA_WITH_SEED_CBC_SHA = { 0x00,0x60}; > CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA = { 0x00,0x61); > CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA = { 0x00,0x62); > CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA = { 0x00,0x63}; > CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA = { 0x00,0x64}; > CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA = { 0x00,0x65} > These numbers (0x00,0x60..0x65) are already used by various > "EXPORT1024" ciphersuites (expired I-D draft-ietf-tls-56-bit- > ciphersuites). Although that draft never became an RFC, these > ciphersuites are quite widely implemented (in e.g. OpenSSL, > Netscape/Mozilla NSS, and some Microsoft and Cisco products), > so reusing the same numbers is probably not a good idea. > This conflict was pointed out a while ago on the TLS WG > mailing list, but apparently the authors didn't notice it. > Based on the list of various TLS numbers I've collected > (http://people.nokia.net/~pasi/tls-numbers.txt), I'd > suggest renumbering these ciphersuites to 0x00,0x96..0x9B. > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 14:33:56 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 OAA10617; Tue, 4 Jan 2005 14:33:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cludj-0005Aq-0i; Tue, 04 Jan 2005 14:46:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CluKQ-000805-Jv; Tue, 04 Jan 2005 14:26:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CluGm-0006bB-6W; Tue, 04 Jan 2005 14:23:04 -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 OAA09987; Tue, 4 Jan 2005 14:23:02 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CluT8-0004yF-Ap; Tue, 04 Jan 2005 14:35:54 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 7ED3F1702E; Tue, 4 Jan 2005 11:22:30 -0800 (PST) To: Thomas Narten Subject: Re: [TLS] Re: Last Call: 'Addition of SEED Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard References: <200501041842.j04Ig5mH014833@rotala.raleigh.ibm.com> From: EKR Date: Tue, 04 Jan 2005 11:22:30 -0800 In-Reply-To: <200501041842.j04Ig5mH014833@rotala.raleigh.ibm.com> (Thomas Narten's message of "Tue, 04 Jan 2005 13:42:05 -0500") Message-ID: <86sm5hm22x.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: d6b246023072368de71562c0ab503126 Cc: jhyoon@kisa.or.kr, iesg@ietf.org, jilee@kisa.or.kr, jiinii@kisa.or.kr, 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Thomas Narten writes: > Caveat: I know nothing about TLS registries, per se. > > However, more generally, if keeping track of numbers that are in use > is important enough (e.g., to prevent interoperability problems) that > someone has to maintain a private registry, that strongly suggests to > me that IANA should be maintaining such a registry. That is why IANA > exists, after all. > > Having IANA maintain the registry doesn't mean it has to be hard to > obtain numbers. They could be assigned FCFS, if that is > appropriate. Indeed, Pasi's page could be used as the initial starting > point with IANA handling all future registrations. > > What am I missing? Nothing. The TLS 1.1 I-D specifies such a registry. It just hasn't quite wound its way through the process yet. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 18:21: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 SAA02730; Tue, 4 Jan 2005 18:21:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClyCI-0003CZ-6c; Tue, 04 Jan 2005 18:34:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clxxs-0003Hs-FF; Tue, 04 Jan 2005 18: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 1Clxtk-0008Ga-8B for tls@megatron.ietf.org; Tue, 04 Jan 2005 18:15: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 SAA02041 for ; Tue, 4 Jan 2005 18:15:29 -0500 (EST) Received: from gateway.britestream.com ([216.30.135.75] helo=gateway.layern.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cly6B-00035u-4v for tls@ietf.org; Tue, 04 Jan 2005 18:28:24 -0500 Received: from [192.168.14.125] (VM-RGOBLE.ad.britestream.com [192.168.14.125]) by gateway.layern.com (8.12.11/8.12.11) with ESMTP id j04NEbP1005629; Tue, 4 Jan 2005 17:14:37 -0600 Message-ID: <41DB235C.3050802@LayerN.com> Date: Tue, 04 Jan 2005 17:14:36 -0600 From: Richard Goble User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Blake-Wilson Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt References: <001f01c4f281$e9fe32f0$c500a8c0@simon> In-Reply-To: <001f01c4f281$e9fe32f0$c500a8c0@simon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.43 X-Spam-Score: 2.0 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit 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: 2.0 (++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Simon, This implies that client code would have to include all possible server extensions before the TLS server could take advantage of the extensions that increased its efficiency. It is doubtful that developers will be given the time to insert new extensions if there is not a known need. In Badra's example, where the client would send another client hello w/ extensions the handshake ends up looking a lot like a SGC style handshake, which has implications on the hash of the handshake messages. Or you could create a new client response to the server initiated extensions that would be sent as the first response to the server after the server hello done is sent. If the client can't / won't accept the server extension it simply proceeds as normal. The server would then decide if it wanted to terminate the handshake. Best Regards, Richard Goble Simon Blake-Wilson wrote: >Hi Badra, > >I think your reading is still different from mine. Perhaps this means the >text could use clarification. > >In my thinking, an empty extension is not "type-less". New extensions, say >of type x, that are essentially server driven would require clients to >include an extension of type x in the client hello with extension data >empty. The server can then include an extension of type x in the server >hello and put any relevant info about the extension in the extension data. >Of course, this limits the amount of "negotiation" that can occur between >the server and the client. > >To clarify this, I'd propose the following rewording of the paragraph: > >"Nonetheless "server initiated" extensions may be provided in the future >within this framework - such an extension, say of type x, would require >the client to first send an extension of type x in the (extended) client >hello with empty extension_data to indicate that it supports the extension >type." > >Best regards. Simon > > > >>-----Original Message----- >>From: badra@infres.enst.fr [mailto:badra@infres.enst.fr] >>Sent: Tuesday, January 04, 2005 8:58 AM >>To: Simon Blake-Wilson >>Cc: tls@ietf.org >>Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt >> >> >>Hi Simon, >> >>It may be sufficient to add somewhere in the text that an >>empty extension has no type and that, if the client receives >>one or more extensions and it wants to negotiate them, it >>must re-send an extended client hello with the selected extensions. >> >>Best regards, >>Badra >> >> >> >>>To my mind it means that new extensions cannot specify that >>> >>> >>the server >> >> >>>sends a particular extension type unless the client has >>> >>> >>included the >> >> >>>same extension type in the client hello. But new extensions can get >>>round this by having the client send an empty extension of >>> >>> >>that type, >> >> >>>thereby allowing the server to respond. >>> >>>This text has not changed from RFC3546, but if you think it >>> >>> >>should be >> >> >>>clarified, please suggest some text! >>> >>>Best regards. Simon >>> >>> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>TLS mailing list >>TLS@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Jan 4 21:38:47 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 VAA15519; Tue, 4 Jan 2005 21:38:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1Gw-0006yC-9g; Tue, 04 Jan 2005 21:51:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm11e-0001b1-Dh; Tue, 04 Jan 2005 21:35:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm10F-0000xH-DA for tls@megatron.ietf.org; Tue, 04 Jan 2005 21:34:27 -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 VAA15062 for ; Tue, 4 Jan 2005 21:34:25 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm1Cj-0006ql-E2 for tls@ietf.org; Tue, 04 Jan 2005 21:47:21 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j052YIoh047416 for ; Tue, 4 Jan 2005 18:34:19 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 4 Jan 2005 18:34:23 -0800 To: tls@ietf.org From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [TLS] Small comment on the TLS 1.1 draft 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 Although it doesn't seem like much is changing between 1.0 and 1.1, a summary of the actual changes would be very handy, hopefully near the top of the document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 5 17:33:35 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 RAA26482; Wed, 5 Jan 2005 17:33:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmJvL-0003Zd-Vw; Wed, 05 Jan 2005 17:46:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmJgt-00065V-GM; Wed, 05 Jan 2005 17:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmJYQ-0003YA-To for tls@megatron.ietf.org; Wed, 05 Jan 2005 17:22:59 -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 RAA25540 for ; Wed, 5 Jan 2005 17:22:55 -0500 (EST) Received: from [144.202.240.3] (helo=woodstock.binhost.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmJky-0001Eo-Fc for tls@ietf.org; Wed, 05 Jan 2005 17:36:00 -0500 Received: (qmail 2617 invoked by uid 0); 5 Jan 2005 22:22:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.163.142) by woodstock.binhost.com with SMTP; 5 Jan 2005 22:22:40 -0000 Message-Id: <6.2.0.14.2.20050105172142.08501a70@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 05 Jan 2005 17:22:44 -0500 To: Paul Hoffman / VPNC , tls@ietf.org From: Russ Housley Subject: Re: [TLS] Small comment on the TLS 1.1 draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 The IESG has been requiring a change summary when one standards-track document obsoletes a previous one. I suggest that this be added before the document is sent forward. Russ At 09:34 PM 1/4/2005, Paul Hoffman / VPNC wrote: >Although it doesn't seem like much is changing between 1.0 and 1.1, a >summary of the actual changes would be very handy, hopefully near the top >of the document. > >--Paul Hoffman, Director >--VPN Consortium > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 5 22:14: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 WAA18188; Wed, 5 Jan 2005 22:14:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmOIu-0006jc-GW; Wed, 05 Jan 2005 22:27:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmNqO-0003lJ-Jm; Wed, 05 Jan 2005 21:57:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmNpQ-0003Qj-JJ for tls@megatron.ietf.org; Wed, 05 Jan 2005 21:56:48 -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 VAA16999 for ; Wed, 5 Jan 2005 21:56:45 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 2273810311; Wed, 5 Jan 2005 21:56:17 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 8BA5D100E0 for ; Wed, 5 Jan 2005 21:56:16 -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 21771-47 for ; Wed, 5 Jan 2005 21:56:04 -0500 (EST) Received: from mail.f5.com (mulder.f5.com [205.229.151.150]) by mail.ca.certicom.com (Postfix) with ESMTP id B531B10311 for ; Wed, 5 Jan 2005 21:56:03 -0500 (EST) Received: from exchfour.olympus.f5net.com ([192.168.11.152]) by mail.f5.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jan 2005 18:55:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2005 18:55:58 -0800 Message-ID: <3D8E54E3CAA3864295233C618F53F2ADDE6F7C@exchfour.olympus.f5net.com> Thread-Topic: [Tsvwg] Looking for feedback on DTLS Thread-Index: AcTtAwMazIeCMnhxRKWwaIIQodusowA7EJXA From: "Amit Jain" To: "EKR" X-OriginalArrivalTime: 06 Jan 2005 02:55:59.0901 (UTC) FILETIME=[406444D0:01C4F39B] Content-Transfer-Encoding: quoted-printable Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org Subject: [TLS] RE: [Tsvwg] Looking for feedback on DTLS 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: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Thanks for your replies. My thoughts inline: >> I think another approach worth considering may be to introduce a thin >> layer inside record layer which takes care of fragmentation, >> reliability, in-order delivery to record layer. In this approach: >Yes. We considered this approach. However, we were concerned about >designing a generic reliability layer. Designing reliable transport >protocols is difficult, as evidenced by the fact that we're still >working on TCP after 20+ years. Our feeling was that as the only real >requirement was to make the handshake reliable it was best to tie the >reliability into the handshake process and thus avoid the complexity >and rathole potential of trying to design something more >general. Moreover, there is experience with this kind of state machine >from IKE and other similar protocols. As you described, we need a very simple reliability mechanism for handshake signaling, I think moving this simple reliable mechanism to record layer will make it further simple in terms of implementation. It may also make it more efficient in terms of buffer requirements for retransmissions and the bytes needed to retransmit in case of packet loss since we can track the reliability per UDP datagram instead of a flight of handshake messages.=20 I did not mean that we need to have a reliable layer as extensive as TCP in record layer. >> 2: Records are fragmented and is converted to UDP datagram.=20 >> =20 >> These UDP data-grams are then transmitted reliably to other end in the >> handshake phase using a very thin layer (built into record layer). It >> may be analogous to a simple reliable variant of UDP (something like >> TFTP). Here the reliability is tracked for each UDP datagram and only >> the missing UDP datagram is re-transmitted. >> >> This may provide following advantages: >> =20 >> 1: Handshake layer will be similar to the TLS. There won't be any change >> needed in the implementation of state machine and the specification of >> handshake messages. >That's sort of correct, except that the handshake state machine >will need to do signalling to the record layer about when it wants >reliability. It's also important to note that the DTLS handshake >reliability layer lives mostly at the level of the DTLS handshake >wrapper. The handshake payloads themselves don't change. My thought on this is that there is already a content type field in the record layer. It probably can be used for providing different types of services to different content types. I agree that it has additional complexity. One thought which comes at this point is that do we also need to make alert reliable? What if the close notify alert gets lost? Will it affect the protection against truncation attack? When do we stop reusing the DTLS session information? Or how do we differentiate an abrupt closure from a graceful closure? Having reliability in record layer can make it possible for the alerts to be transmitted reliably. >> 3: Having a thin reliability layer in Record layer will allow greater >> flexibility and extensibility. Reliability layer can be replaced with >> other reliability mechanism like DCCP in future for providing >> reliability/congestion control. >Well, DCCP wouldn't do the job here since it ONLY provides congestion >control and not reliability. DTLS will of course run fine over DCCP. >It just doesn't make the problem any easier. Michael Tuexen and I >are currently talking about the interaction of DTLS and SCTP, but >I don't think that's a universal solution. My bad here. Short on knowledge on DCCP =3D). But the point I wanted to convey here was that it is the record layer which interfaces with the transport, so any kind of transport adaptation should possibly be in record layer. Of course it is the first thought which comes to anybody when thinking about adapting TLS to different transports and it needs to be evaluated based on all other design criteria. Thanks for your replies. -amit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 5 23:57:14 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 XAA24938; Wed, 5 Jan 2005 23:57:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmPuj-0005vJ-7S; Thu, 06 Jan 2005 00:10:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmPaA-0000L7-6O; Wed, 05 Jan 2005 23:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmPTY-0007Ep-3B for tls@megatron.ietf.org; Wed, 05 Jan 2005 23:42:20 -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 XAA24180 for ; Wed, 5 Jan 2005 23:42:16 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 38D8210152; Wed, 5 Jan 2005 23:41:49 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 037E71026D for ; Wed, 5 Jan 2005 23:41:49 -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 21759-72 for ; Wed, 5 Jan 2005 23:41:36 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by mail.ca.certicom.com (Postfix) with ESMTP id C0A6410152 for ; Wed, 5 Jan 2005 23:41:35 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id 0E1C217029; Wed, 5 Jan 2005 20:41:50 -0800 (PST) To: "Amit Jain" References: <3D8E54E3CAA3864295233C618F53F2ADDE6F7C@exchfour.olympus.f5net.com> From: EKR Date: Wed, 05 Jan 2005 20:41:49 -0800 In-Reply-To: <3D8E54E3CAA3864295233C618F53F2ADDE6F7C@exchfour.olympus.f5net.com> (Amit Jain's message of "Wed, 5 Jan 2005 18:55:58 -0800") Message-ID: <86ekgzkw36.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 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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: 3002fc2e661cd7f114cb6bae92fe88f1 "Amit Jain" writes: >>Yes. We considered this approach. However, we were concerned about >>designing a generic reliability layer. Designing reliable transport >>protocols is difficult, as evidenced by the fact that we're still >>working on TCP after 20+ years. Our feeling was that as the only real >>requirement was to make the handshake reliable it was best to tie the >>reliability into the handshake process and thus avoid the complexity >>and rathole potential of trying to design something more >>general. Moreover, there is experience with this kind of state machine >>from IKE and other similar protocols. > > As you described, we need a very simple reliability mechanism for > handshake signaling, I think moving this simple reliable mechanism to > record layer will make it further simple in terms of implementation. I doubt the difference will be significant. As noted in the original DTLS paper, the incremental effort involved was quite small. And, of course, the reliability mechanism for DTLS has already been designed and tested. > It > may also make it more efficient in terms of buffer requirements for > retransmissions and the bytes needed to retransmit in case of packet > loss since we can track the reliability per UDP datagram instead of a > flight of handshake messages. As I indicated in my responses to Murali Bashyam, the amount of overhead involved here is really quite small. In any case, the performance difference isn't a result of where the reliability layer is, it's a result of whether you have explicit ACKs as oppposed to the implicit ACK of receiving the next message from the peer that DTLS currently uses. We decided not to add them in DTLS for complexity reasons (see S 4.4 of the paper for discussion). > I did not mean that we need to have a reliable layer as extensive as TCP > in record layer. OK. But one of the hazards of doing a generic layer that includes coverage of the data records is that it's hard to know where to stop. >>That's sort of correct, except that the handshake state machine >>will need to do signalling to the record layer about when it wants >>reliability. It's also important to note that the DTLS handshake >>reliability layer lives mostly at the level of the DTLS handshake >>wrapper. The handshake payloads themselves don't change. > > My thought on this is that there is already a content type field in the > record layer. It probably can be used for providing different types of > services to different content types. I agree that it has additional > complexity. Yes. It also requires some substantial layer traversal to make it work--in TLS and DTLS, the record layer is more-or-less agnostic about what data its carrying. > One thought which comes at this point is that do we also need to make > alert reliable? We don't believe so, no. > What if the close notify alert gets lost? Will it affect > the protection against truncation attack? When do we stop reusing the > DTLS session information? Or how do we differentiate an abrupt closure > from a graceful closure? In general, in an environment where the data is unreliable, it's not clear what the meaning of a connection closure is, so I would tend to expect this to happen at the application layer in general. In any case, TLS 1.1 relaxes the requirement not to resume if you don't see a close_notify. > My bad here. Short on knowledge on DCCP =). But the point I wanted to > convey here was that it is the record layer which interfaces with the > transport, so any kind of transport adaptation should possibly be in > record layer. Yep. It's certainly a reasonable first thought, but I think at the end of the day it's the wrong way to go. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Jan 6 03:34:05 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 DAA20890; Thu, 6 Jan 2005 03:34:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmTIa-0000xi-MC; Thu, 06 Jan 2005 03:47:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmT3Z-0001Hn-Km; Thu, 06 Jan 2005 03:31:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmSxl-0008Sh-Re for tls@megatron.ietf.org; Thu, 06 Jan 2005 03:25:45 -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 DAA20613 for ; Thu, 6 Jan 2005 03:25:44 -0500 (EST) Received: from smtp-out3.blueyonder.co.uk ([195.188.213.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmTAV-0005oa-LI for tls@ietf.org; Thu, 06 Jan 2005 03:38:56 -0500 Received: from [127.0.0.1] ([82.42.16.116]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 08:26:13 +0000 Message-ID: <41DCF5ED.7020201@blueyonder.co.uk> Date: Thu, 06 Jan 2005 08:25:17 +0000 From: David Hopwood User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt References: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> <00a101c4f1dd$5b8f4940$c500a8c0@simon> <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> In-Reply-To: <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jan 2005 08:26:13.0608 (UTC) FILETIME=[62480680:01C4F3C9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit badra@infres.enst.fr wrote: > Hi Simon, > > It may be sufficient to add somewhere in the text that an empty extension > has no type and that, if the client receives one or more extensions and it > wants to negotiate them, it must re-send an extended client hello with the > selected extensions. The assumption when the extensions spec was designed was that a client would know in advance what extensions it could possibly support. So it should never need to re-send a hello for that reason. The text seems quite clear to me, but since I wrote that part originally I may not be the best person to judge. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Jan 6 07:31:31 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 HAA03238; Thu, 6 Jan 2005 07:31:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmX0N-0005Ry-KX; Thu, 06 Jan 2005 07:44:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmWdQ-0008CD-R2; Thu, 06 Jan 2005 07:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmWbJ-0007kl-8A for tls@megatron.ietf.org; Thu, 06 Jan 2005 07:18:49 -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 HAA02540 for ; Thu, 6 Jan 2005 07:18:48 -0500 (EST) From: badra@infres.enst.fr Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWo2-00084r-6M for tls@ietf.org; Thu, 06 Jan 2005 07:32:01 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id B2BFE5F0; Thu, 6 Jan 2005 13:18:37 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71191-10; Thu, 6 Jan 2005 13:18:18 +0100 (CET) Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by smtp2.enst.fr (Postfix) with ESMTP id 70E335F5; Thu, 6 Jan 2005 13:05:59 +0100 (CET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with ESMTP id j06C5wg06924; Thu, 6 Jan 2005 13:05:58 +0100 (MET) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Thu, 6 Jan 2005 13:05:58 +0100 (MET) Message-ID: <59790.127.0.0.1.1105013158.squirrel@127.0.0.1> In-Reply-To: <41DCF5ED.7020201@blueyonder.co.uk> References: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> <00a101c4f1dd$5b8f4940$c500a8c0@simon> <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> <41DCF5ED.7020201@blueyonder.co.uk> Date: Thu, 6 Jan 2005 13:05:58 +0100 (MET) Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt To: david.nospam.hopwood@blueyonder.co.uk User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable david.nospam.hopwood@blueyonder.co.uk wrote: > The assumption when the extensions spec was designed was that a client > would > know in advance what extensions it could possibly support. So it should > never need to re-send a hello for that reason. > > The text seems quite clear to me, but since I wrote that part originall= y I > may not be the best person to judge. Beyond the text, I wanted to say that the client may "interrogate" the server to know what are the extensions supported by the server, by sendin= g an empty and "magic" extension with no-type. Thus, the client should re-send an Extended Client Hello with the selected extensions. Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Jan 6 11:11:40 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 LAA19308; Thu, 6 Jan 2005 11:11:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmaRU-0005ZP-KV; Thu, 06 Jan 2005 11:24:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cma8P-0003Fd-OM; Thu, 06 Jan 2005 11:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cma4F-00025x-JP for tls@megatron.ietf.org; Thu, 06 Jan 2005 11:00:55 -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 LAA18491 for ; Thu, 6 Jan 2005 11:00:53 -0500 (EST) Received: from tomts36.bellnexxia.net ([209.226.175.93] helo=tomts36-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmaH2-00072j-K3 for tls@ietf.org; Thu, 06 Jan 2005 11:14:10 -0500 Received: from simon ([64.231.153.128]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050106160044.LKVU1694.tomts36-srv.bellnexxia.net@simon>; Thu, 6 Jan 2005 11:00:44 -0500 From: "Simon Blake-Wilson" To: , Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Thu, 6 Jan 2005 11:00:10 -0500 Message-ID: <019501c4f408$d0519620$c500a8c0@simon> X-Priority: 3 (Normal) MIME-Version: 1.0 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <59790.127.0.0.1.1105013158.squirrel@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Content-Type: multipart/mixed; boundary="===============1990969441==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. --===============1990969441== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0190_01C4F3DE.E3DF0670" This is a multi-part message in MIME format. ------=_NextPart_000_0190_01C4F3DE.E3DF0670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Badra, I guess I'm struggling to see the benefit of that unless the number of extensions grows by a couple of orders of magnitude. Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of badra@infres.enst.fr > Sent: Thursday, January 06, 2005 7:06 AM > To: david.nospam.hopwood@blueyonder.co.uk > Cc: tls@ietf.org > Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt > > > david.nospam.hopwood@blueyonder.co.uk wrote: > > The assumption when the extensions spec was designed was > that a client > > would know in advance what extensions it could possibly > support. So it > > should never need to re-send a hello for that reason. > > > > The text seems quite clear to me, but since I wrote that part > > originally I may not be the best person to judge. > > Beyond the text, I wanted to say that the client may > "interrogate" the server to know what are the extensions > supported by the server, by sending an empty and "magic" > extension with no-type. Thus, the client should re-send an > Extended Client Hello with the selected extensions. > > Badra > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_0190_01C4F3DE.E3DF0670 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJDCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR5MIID4qADAgECAhBQvP6CEfX+K7FeZPKFUBttMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDIyNTAwMDAw MFoXDTA1MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh81iFspBl ua1ZyvbQpRCm13CI/+nUsztcRWpIVVcKLknRA2btu394xi3q/Qmw+hW2QkZmaeVsvULMrNXr171x s/jkxJ4noM8Xx1HPtMKZOeLr1A3IcSpZO5ZNePAoPPLAjGYxb3wJemzG3dBDhZ/BUWiwIMqMhju5 gG4TQoytKwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMG A1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEAFDIEV02jprRnMwLnqOhTeQxHgtI/UHiybRDLo4dba4laCyzJHboTBDSrAs6f LD1+LfBYAgKgAgfTtFPezb2+qQP9uw/5JwnzXE9GlQKX73bafTHJ1qqDhUTQQK80CRxDrvX3y/qt VZDFPONmFhoxMWE9dzQRrknPZVEqCu5KikExggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAbbTAJBgUrDgMCGgUAoIICsjAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAxMDYxNjAwMTBaMCMGCSqG SIb3DQEJBDEWBBQdPD5L+QgXpj4MY+oNBWrTPwmzAjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBQvP6CEfX+K7FeZPKFUBttMIH0BgsqhkiG9w0BCRACCzGB 5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAb bTANBgkqhkiG9w0BAQEFAASBgIxTnBwuLYtHAr1gIxwdXGJotWWqs5nBBGoZqXnvUYe2HXMmOmkd YcwcRUZFcZpmS8gXHCP4yj02nGJYx5qcRhGNkseqL/l7LLudEG3HMdbEdb/aDE90XbNjesRW3III ZCMHqSqo0I7FSmNm12WOdYA05oZeEvGFFDPHyx9raEyAAAAAAAAA ------=_NextPart_000_0190_01C4F3DE.E3DF0670-- --===============1990969441== 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 --===============1990969441==-- From tls-bounces@ietf.org Thu Jan 6 13:44: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 NAA00570; Thu, 6 Jan 2005 13:44:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmcpd-0007nA-N4; Thu, 06 Jan 2005 13:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcXM-0002Jh-Fy; Thu, 06 Jan 2005 13:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcSI-0000cR-9k for tls@megatron.ietf.org; Thu, 06 Jan 2005 13:33:54 -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 NAA29772 for ; Thu, 6 Jan 2005 13:33:53 -0500 (EST) Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmcf5-0007IQ-Hx for tls@ietf.org; Thu, 06 Jan 2005 13:47:10 -0500 Received: from [127.0.0.1] ([82.42.16.116]) by smtp-out5.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 18:34:19 +0000 Message-ID: <41DD8473.7030605@blueyonder.co.uk> Date: Thu, 06 Jan 2005 18:33:23 +0000 From: David Hopwood User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt References: <63536.127.0.0.1.1104774652.squirrel@127.0.0.1> <00a101c4f1dd$5b8f4940$c500a8c0@simon> <3406.137.194.192.26.1104847058.squirrel@137.194.192.26> <41DCF5ED.7020201@blueyonder.co.uk> <59790.127.0.0.1.1105013158.squirrel@127.0.0.1> In-Reply-To: <59790.127.0.0.1.1105013158.squirrel@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jan 2005 18:34:19.0998 (UTC) FILETIME=[55DD4FE0:01C4F41E] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit badra@infres.enst.fr wrote: > david.nospam.hopwood@blueyonder.co.uk wrote: > >>The assumption when the extensions spec was designed was that a client >>would know in advance what extensions it could possibly support. So it >>should never need to re-send a hello for that reason. >> >>The text seems quite clear to me, but since I wrote that part originally I >>may not be the best person to judge. > > Beyond the text, I wanted to say that the client may "interrogate" the > server to know what are the extensions supported by the server, by sending > an empty and "magic" extension with no-type. Thus, the client should > re-send an Extended Client Hello with the selected extensions. This seems unnecessary, because the client can simply send its desired parameters for each extension as if the server supported it. There are no interactions between different extensions such that the client would need to know whether the server supported one extension before deciding on the parameters for another. IIRC, this exact issue was considered by the authors and discussed on the TLS list. A more complicated multi-round negotiation could have been designed, but the current simple mechanism won out in the discussion. If a client implementor disagrees with this reasoning and decides that a multi-round negotiation is worth the additional complexity, then the possibility of reconnecting and sending another hello is obvious, and not prohibited by the current text. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 12 07:27:41 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 HAA06653; Wed, 12 Jan 2005 07:27:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CohpC-0003kR-BE; Wed, 12 Jan 2005 07:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CohWt-0004VV-CL; Wed, 12 Jan 2005 07:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CohUS-0003w9-SQ for tls@megatron.ietf.org; Wed, 12 Jan 2005 07:20:44 -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 HAA06408 for ; Wed, 12 Jan 2005 07:20:42 -0500 (EST) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CohiT-0003dd-P3 for tls@ietf.org; Wed, 12 Jan 2005 07:35:14 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 8AD2C164E14 for ; Wed, 12 Jan 2005 13:20:32 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66159-10 for ; Wed, 12 Jan 2005 13:20:24 +0100 (CET) Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by smtp2.enst.fr (Postfix) with ESMTP id 3391A164E06 for ; Wed, 12 Jan 2005 13:20:24 +0100 (CET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with ESMTP id j0CCKNg08207 for ; Wed, 12 Jan 2005 13:20:23 +0100 (MET) Received: from stdi.iut.univ-paris5.fr ([193.51.93.89]) (proxying for unknown) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Wed, 12 Jan 2005 13:20:23 +0100 (MET) Message-ID: <7747.193.51.93.89.1105532423.squirrel@193.51.93.89> Date: Wed, 12 Jan 2005 13:20:23 +0100 (MET) To: tls@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050112132023_33699" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [TLS] [Fwd: I-D ACTION:draft-hajjeh-tls-sign-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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 ------=_20050112132023_33699 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ---------------------------- Message original ---------------------------= - Object: I-D ACTION:draft-hajjeh-tls-sign-00.txt From: Internet-Drafts@ietf.org Date: Wed 11 january 2005 21:37 To: i-d-announce@ietf.org -------------------------------------------------------------------------= - A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TLS Sign Author(s) : I. Hajjeh, et al. Filename : draft-hajjeh-tls-sign-00.txt Pages : 9 Date : 2005-1-11 TLS protocol provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to perform non-repudiation service. This document defines extensions to the TLS protocol to allow it to=20 perform non-repudiation service. It is based on [TLSSign] and it=20 provides the client and the server the ability to sign by TLS,=20 handshake and applications data using certificates such as X.509. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hajjeh-tls-sign-00.txt ------=_20050112132023_33699 Content-Type: message/external-body; name="untitled-2.1" Content-Disposition: attachment; filename="untitled-2.1" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-1-11160600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hajjeh-tls-sign-00.txt ------=_20050112132023_33699 Content-Type: message/external-body; name="draft-hajjeh-tls-sign-00.txt" Content-Disposition: attachment; filename="draft-hajjeh-tls-sign-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-1-11160600.I-D@ietf.org> ------=_20050112132023_33699 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------=_20050112132023_33699-- From tls-bounces@ietf.org Wed Jan 19 17:54:35 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 RAA05266; Wed, 19 Jan 2005 17:54:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrOyH-0001qJ-Dt; Wed, 19 Jan 2005 18:10:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrOfB-0002hQ-Pf; Wed, 19 Jan 2005 17:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrOZc-0001gc-B8 for tls@megatron.ietf.org; Wed, 19 Jan 2005 17:45:12 -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 RAA04727 for ; Wed, 19 Jan 2005 17:45:09 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id C7AD210477; Wed, 19 Jan 2005 17:44:41 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 951E2101F6 for ; Wed, 19 Jan 2005 17:44:41 -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 19280-19 for ; Wed, 19 Jan 2005 17:44:30 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by mail.ca.certicom.com (Postfix) with ESMTP id C668B10477 for ; Wed, 19 Jan 2005 17:44:29 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id F0E561702E; Wed, 19 Jan 2005 14:44:51 -0800 (PST) To: Murali Bashyam References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> <86k6r2f488.fsf@romeo.rtfm.com> <41D1E445.1000805@cisco.com> <868y7hg0mt.fsf@romeo.rtfm.com> <41EEE1E9.9040707@cisco.com> From: EKR Date: Wed, 19 Jan 2005 14:44:51 -0800 In-Reply-To: <41EEE1E9.9040707@cisco.com> (Murali Bashyam's message of "Wed, 19 Jan 2005 14:40:41 -0800") Message-ID: <86651tyr6k.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 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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: 856eb5f76e7a34990d1d457d8e8e5b7f Murali Bashyam writes: > On a different note, how are the firewall requirements addressed here? > Are there well-known ports involved (such as 443 for HTTPS) to > traverse the firewall? I would expect that application layer protocols over DTLS would get their own ports, just as with TLS. > How are dynamically negotiated ports handled? Badly, as with TLS :) I think that's out of scope... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 19 23:05:49 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 XAA00912; Wed, 19 Jan 2005 23:05:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTpW-0000vO-St; Wed, 19 Jan 2005 23:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrTVy-0007eQ-JK; Wed, 19 Jan 2005 23:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrOW2-0000an-1N for tls@megatron.ietf.org; Wed, 19 Jan 2005 17:41:30 -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 RAA04396 for ; Wed, 19 Jan 2005 17:41:27 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 1E9AC100F1; Wed, 19 Jan 2005 17:40:59 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id DFA94101D1 for ; Wed, 19 Jan 2005 17:40:58 -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 17536-79 for ; Wed, 19 Jan 2005 17:40:46 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.ca.certicom.com (Postfix) with ESMTP id DEC02100F1 for ; Wed, 19 Jan 2005 17:40:45 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2005 14:45:23 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0JMegNt009639; Wed, 19 Jan 2005 14:40:42 -0800 (PST) Received: from cisco.com ([171.69.42.231]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAU21878; Wed, 19 Jan 2005 14:40:41 -0800 (PST) Message-ID: <41EEE1E9.9040707@cisco.com> Date: Wed, 19 Jan 2005 14:40:41 -0800 From: Murali Bashyam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> <86k6r2f488.fsf@romeo.rtfm.com> <41D1E445.1000805@cisco.com> <868y7hg0mt.fsf@romeo.rtfm.com> X-Mailman-Approved-At: Wed, 19 Jan 2005 23:01:44 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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="===============1232538361==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd --===============1232538361== Content-Type: multipart/alternative; boundary="------------020003050008060305010508" --------------020003050008060305010508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric On a different note, how are the firewall requirements addressed here? Are there well-known ports involved (such as 443 for HTTPS) to traverse the firewall? How are dynamically negotiated ports handled? Murali EKR wrote: >Murali Bashyam writes: > > > >>EKR wrote: >> >> >> >>>Murali Bashyam writes: >>> >>> >>> >>>>I had a question on the congestion control aspect of the handshake >>>>protocol in DTLS. The draft doesn't seem to address the congestion >>>>control requirements of the handshake protocol such as how soon is it >>>>okay to send an entire flight of packets into the network without >>>>overloading it. >>>> >>>> >>>> >>>We suggest a retransmit timer on the order of 500-1000 ms. >>> >>> >>> >>I was referring more to the TCP capability of slow-start, where TCP >>tries to probe the network >>and expands its flight of packets gradually as opposed to sending the >>entire flight in 1 shot. >> >> >That's true, but note that the current TCP initial window >as specified in RFC 3390 is 3 packets with a 1460-byte MSS >and 4 packets with a 512-byte MSS. This looks pretty similar >to what you would see out of a DTLS implementation initially >(though the TCP implementation would back off faster). > > > >>Of course the point which u bring up that the >>flight typically fits in 1-2 packets is true for 1500 MSS probably but >>when MSS is 512 (the common MSS value on the Internet), this >>immediately becomes 6 packets. >> >> > >Well, since we're talking about 2k-sized flights here, it's 4 packets, >not 6 for a 512-byte MSS. 512 bytes is actually fairly conservative >in the modern network. According to CAIDA's measurements [1], >over half the TCP traffic by volume uses a 1500-byte packet size: > > The primary features of this distribution originate in the way > common TCP implementations divide a data stream into > packets. Approximately 85% of the traffic in these traces is TCP, > and a large proportion of this TCP traffic is generated by bulk > transfer applications such as HTTP and FTP. Consequently, the > majority of the packets seen are one of three sizes: 40 byte > packets (the minimum packet size for TCP) which carry TCP > acknowledgments but no payload; 1500 byte packets (the maximum > Ethernet payload size) from TCP implementations that use path MTU > discovery; and 552 byte and 576 byte packets from TCP > implementations that do not use path MTU discovery. > > > > >>I just want to highlight that by >>avoiding TCP for handshaking and implementing retransmissions and >>timers solves only the reliability problem but doesn't address >>congestion control including efficient retransmission possibilities >>too. >> >> >I don't agree that we're not addressing congestion control. We >recommend an initial timer value of 500 ms with a typical doubling >exponential backoff with each retransmit. (I know this isn't exactly >what I said earlier, but I had to look it up to refresh my >memory). Given the small amounts of data involved here, I think that's >fairly congestion friendly. > >As for efficient retransmission, it's true that DTLS could be smarter >(though with 1500 byte packets and medium-sized (order 1k) server cert >payloads, there's not really much room for improvement) >but the overall improvement would be fairly modest and would introduce >substantial additional complexity. > > > >>>Of course, but we're talking extremely small amounts of data here. >>>It's important to remember that in your average SSL handshake the >>>total number of bytes exchanged is generally less than 3k and that >>>the largest single flight (ServerHello ... ServerHelloDone) is >>>typically less than 2k [1]. In most cases it will fit in 1-2 MTUs. >>> >>> >>> >>True when the MSS is 1500, not when the MSS is negotiated to be >>512. What about large certificates being sent by the server, that >>would increase the number of messages? >> >> > >1k is a fairly large certificate. It's quite uncommon to see a certificate >chain larger than two certificates. That's where I got 2k from. > >-Ekr > >[1] http://www.caida.org/outreach/papers/2000/AIX0005/AIX0005.html#plen_hist > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > --------------020003050008060305010508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Eric

On a different note, how are the firewall requirements addressed here? Are there well-known ports involved (such as 443 for HTTPS) to traverse the firewall? How are dynamically negotiated ports handled?

Murali

EKR wrote:
Murali Bashyam <mbashyam@cisco.com> writes:

  
EKR wrote:

    
Murali Bashyam <mbashyam@cisco.com> writes:

      
I had a question on the congestion control aspect of the handshake
protocol in DTLS. The draft doesn't seem to address the congestion
control requirements of the handshake protocol such as how soon is it
okay to send an entire flight of packets into the network without
overloading it.

        
We suggest a retransmit timer on the order of 500-1000 ms.

      
I was referring more to the TCP capability of slow-start, where TCP
tries to probe the network
and expands its flight of packets gradually as opposed to sending the
entire flight in 1 shot.
    
That's true, but note that the current TCP initial window
as specified in RFC 3390 is 3 packets with a 1460-byte MSS
and 4 packets with a 512-byte MSS. This looks pretty similar
to what you would see out of a DTLS implementation initially
(though the TCP implementation would back off faster).

  
Of course the point which u bring up that the
flight typically fits in 1-2 packets is true for 1500 MSS probably but
when MSS is 512 (the common MSS value on the Internet), this
immediately becomes 6 packets. 
    

Well, since we're talking about 2k-sized flights here, it's 4 packets,
not 6 for a 512-byte MSS. 512 bytes is actually fairly conservative
in the modern network. According to CAIDA's measurements [1],
over half the TCP traffic by volume uses a 1500-byte packet size:

     The primary features of this distribution originate in the way
     common TCP implementations divide a data stream into
     packets. Approximately 85% of the traffic in these traces is TCP,
     and a large proportion of this TCP traffic is generated by bulk
     transfer applications such as HTTP and FTP. Consequently, the
     majority of the packets seen are one of three sizes: 40 byte
     packets (the minimum packet size for TCP) which carry TCP
     acknowledgments but no payload; 1500 byte packets (the maximum
     Ethernet payload size) from TCP implementations that use path MTU
     discovery; and 552 byte and 576 byte packets from TCP
     implementations that do not use path MTU discovery.


  
I just want to highlight that by
avoiding TCP for handshaking and implementing retransmissions and
timers solves only the reliability problem but doesn't address
congestion control including efficient retransmission possibilities
too.
    
I don't agree that we're not addressing congestion control.  We
recommend an initial timer value of 500 ms with a typical doubling
exponential backoff with each retransmit. (I know this isn't exactly
what I said earlier, but I had to look it up to refresh my
memory). Given the small amounts of data involved here, I think that's
fairly congestion friendly.

As for efficient retransmission, it's true that DTLS could be smarter
(though with 1500 byte packets and medium-sized (order 1k) server cert
payloads, there's not really much room for improvement) 
but the overall improvement would be fairly modest and would introduce
substantial additional complexity.

  
Of course, but we're talking extremely small amounts of data here.
It's important to remember that in your average SSL handshake the
total number of bytes exchanged is generally less than 3k and that
the largest single flight (ServerHello ... ServerHelloDone) is
typically less than 2k [1]. In most cases it will fit in 1-2 MTUs.

      
True when the MSS is 1500, not when the MSS is negotiated to be
512. What about large certificates being sent by the server, that
would increase the number of messages?
    

1k is a fairly large certificate. It's quite uncommon to see a certificate
chain larger than two certificates. That's where I got 2k from.

-Ekr

[1] http://www.caida.org/outreach/papers/2000/AIX0005/AIX0005.html#plen_hist

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

--------------020003050008060305010508-- --===============1232538361== 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 --===============1232538361==-- From tls-bounces@ietf.org Fri Jan 21 00:24:53 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 AAA17908; Fri, 21 Jan 2005 00:24:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrrXo-0007lO-ID; Fri, 21 Jan 2005 00:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrDa-0003de-G6; Fri, 21 Jan 2005 00:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrAV-0002E6-8N for tls@megatron.ietf.org; Fri, 21 Jan 2005 00:17:11 -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 AAA17363 for ; Fri, 21 Jan 2005 00:17:08 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 4A0501017C; Fri, 21 Jan 2005 00:16:40 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 1B443101B5 for ; Fri, 21 Jan 2005 00:16:40 -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 03449-13 for ; Fri, 21 Jan 2005 00:16:28 -0500 (EST) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mail.ca.certicom.com (Postfix) with ESMTP id 2AF311017C for ; Fri, 21 Jan 2005 00:16:28 -0500 (EST) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id BA68F33C2E; Fri, 21 Jan 2005 05:16:26 +0000 (GMT) Message-ID: <41F09032.2020509@algroup.co.uk> Date: Fri, 21 Jan 2005 05:16:34 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murali Bashyam Subject: Re: [TLS] Re: [Tsvwg] Looking for feedback on DTLS References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> <86k6r2f488.fsf@romeo.rtfm.com> <41D1E445.1000805@cisco.com> <868y7hg0mt.fsf@romeo.rtfm.com> <41EEE1E9.9040707@cisco.com> In-Reply-To: <41EEE1E9.9040707@cisco.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Murali Bashyam wrote: > > Eric > > On a different note, how are the firewall requirements addressed here? > Are there well-known ports involved (such as 443 for HTTPS) to traverse > the firewall? How are dynamically negotiated ports handled? Don't forget that using well-known ports for TLS versions of protocols is deprecated. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Jan 21 16:54: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 QAA26769; Fri, 21 Jan 2005 16:54:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6zV-0003CK-IK; Fri, 21 Jan 2005 17:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6bX-000668-Uv; Fri, 21 Jan 2005 16:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0DY-0005P5-Or for tls@megatron.ietf.org; Fri, 21 Jan 2005 09:56:57 -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 JAA16460 for ; Fri, 21 Jan 2005 09:56:53 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 04550100DE; Fri, 21 Jan 2005 09:56:23 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id B7BFC105C0 for ; Fri, 21 Jan 2005 09:56:22 -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 07747-37 for ; Fri, 21 Jan 2005 09:56:11 -0500 (EST) Received: from mail45.e.nsc.no (mail45.e.nsc.no [193.213.115.45]) by mail.ca.certicom.com (Postfix) with ESMTP id D4578100DE for ; Fri, 21 Jan 2005 09:56:10 -0500 (EST) Received: from epostleser.online.no (epostleser13.frisurf.no [148.122.3.21]) by mail45.nsc.no (8.12.11/8.12.11) with ESMTP id j0LEu88h023312 for ; Fri, 21 Jan 2005 15:56:08 +0100 (CET) X-WebMail-UserID: kankedu@online.no Date: Fri, 21 Jan 2005 15:56:08 +0100 From: kankedu To: ietf-tls@lists.certicom.com X-EXP32-SerialNo: 50000140 Message-ID: <41F1E8C5@epostleser.online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 Jan 2005 16:46:03 -0500 Subject: [TLS] TLS revisions? 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello. I wonder if there are any revisions of TLS out there, or if 1.0 is the only one. Specifically I wonder if TLS still has both the error messages bad_record_mac and decryption_failed, which impose a security threath is some cases (cf. http://www.terminodes.org/getDoc.php?docid=449&docnum=1). I know that openSSL does not use both errors (http://www.openssl.org/~bodo/tls-cbc.txt), but is that up to each implementor of TLS to decide, or is it in the protocol? sincerely, Johannes Hoff ps. By the way, the address for subscribing, ietf-tls-request@lists.certicom.com, is broken! _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Jan 21 16:55: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 QAA26872; Fri, 21 Jan 2005 16:55:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs70T-0003Ed-Bd; Fri, 21 Jan 2005 17:11:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6bY-00066E-FZ; Fri, 21 Jan 2005 16:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0Ib-0006IA-EI for tls@megatron.ietf.org; Fri, 21 Jan 2005 10:02:09 -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 KAA16698 for ; Fri, 21 Jan 2005 10:02:06 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 0BE7F105BF; Fri, 21 Jan 2005 10:01:36 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D1AE1105C3 for ; Fri, 21 Jan 2005 10:01:35 -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 06000-62 for ; Fri, 21 Jan 2005 10:01:24 -0500 (EST) Received: from mail45.e.nsc.no (mail45.e.nsc.no [193.213.115.45]) by mail.ca.certicom.com (Postfix) with ESMTP id BD2E6105BF for ; Fri, 21 Jan 2005 10:01:22 -0500 (EST) Received: from epostleser.online.no (epostleser13.frisurf.no [148.122.3.21]) by mail45.nsc.no (8.12.11/8.12.11) with ESMTP id j0LF1Km4024902 for ; Fri, 21 Jan 2005 16:01:20 +0100 (CET) X-WebMail-UserID: kankedu@online.no Date: Fri, 21 Jan 2005 16:01:20 +0100 From: kankedu To: ietf-tls@lists.certicom.com X-EXP32-SerialNo: 50000140 Message-ID: <41F1EBA3@epostleser.online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 Jan 2005 16:46:03 -0500 Subject: [TLS] RE: TLS revisions? 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Just to be explicit: Since (as mentioned in the ps) I cannot subscribe, please put me in the CC for any replies on the subject. Thanks, Johannes Hoff >===== Original Message From kankedu ===== >Hello. > >I wonder if there are any revisions of TLS out there, or if 1.0 is the only >one. > >Specifically I wonder if TLS still has both the error messages bad_record_mac >and decryption_failed, which impose a security threath is some cases (cf. >http://www.terminodes.org/getDoc.php?docid=449&docnum=1). I know that openSSL >does not use both errors (http://www.openssl.org/~bodo/tls-cbc.txt), but is >that up to each implementor of TLS to decide, or is it in the protocol? > >sincerely, >Johannes Hoff > > >ps. By the way, the address for subscribing, >ietf-tls-request@lists.certicom.com, is broken! _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Jan 22 01:06: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 BAA24558; Sat, 22 Jan 2005 01:06:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsEfy-0005Mo-2J; Sat, 22 Jan 2005 01:23:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsEGx-0003Wy-T9; Sat, 22 Jan 2005 00:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsE8x-0001Xo-5K for tls@megatron.ietf.org; Sat, 22 Jan 2005 00:49:07 -0500 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23815 for ; Sat, 22 Jan 2005 00:49:01 -0500 (EST) Received: from phys-ha14sca-1.sfbay.sun.com ([129.145.155.210]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0M5n3dt004512 for ; Fri, 21 Jan 2005 22:49:03 -0700 (MST) Received: from [192.18.148.184] by ha14sca-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTP id <0IAP00EBKETRGBD0@ha14sca-mail1.sfbay.sun.com> for tls@lists.ietf.org; Fri, 21 Jan 2005 21:49:03 -0800 (PST) Date: Fri, 21 Jan 2005 21:48:33 -0800 From: Nelson B Bolyard Subject: Re: [TLS] RE: TLS revisions? In-reply-to: <41F1EBA3@epostleser.online.no> To: Johannes Hoff Message-id: <41F1E931.6010408@bolyard.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <41F1EBA3@epostleser.online.no> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927 Content-Transfer-Encoding: 7bit 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: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Johannes Hoff wrote: >>I wonder if there are any revisions of TLS out there, or if 1.0 is the only >>one. 1.0 is the current standard. There is an Internet Draft of version 1.1 available at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tls-rfc2246-bis-09.txt >>Specifically I wonder if TLS still has both the error messages bad_record_mac >>and decryption_failed, which impose a security threath is some cases (cf. >>http://www.terminodes.org/getDoc.php?docid=449&docnum=1). I know that openSSL >>does not use both errors (http://www.openssl.org/~bodo/tls-cbc.txt), but is >>that up to each implementor of TLS to decide, or is it in the protocol? >>ps. By the way, the address for subscribing, >>ietf-tls-request@lists.certicom.com, is broken! The list server for the IETF TLS mailing list has changed. IINM, the new alias is > TLS@lists.ietf.org and subscriptions are handled through > https://www1.ietf.org/mailman/listinfo/tls Regards, Nelson Bolyard _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 24 16:56:09 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 QAA05831; Mon, 24 Jan 2005 16:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCSV-0000fG-LX; Mon, 24 Jan 2005 17:13:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBwT-0004jW-GA; Mon, 24 Jan 2005 16:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBm4-0005zp-3u for tls@megatron.ietf.org; Mon, 24 Jan 2005 16:29:28 -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 QAA01387 for ; Mon, 24 Jan 2005 16:29:25 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 72B0E106D5; Mon, 24 Jan 2005 16:28:56 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3DF20106DA for ; Mon, 24 Jan 2005 16:28:56 -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 22053-87 for ; Mon, 24 Jan 2005 16:28:45 -0500 (EST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail.ca.certicom.com (Postfix) with ESMTP id E1591106D5 for ; Mon, 24 Jan 2005 16:28:44 -0500 (EST) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CtBag-0004Do-9p; Mon, 24 Jan 2005 16:17:42 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 24 Jan 2005 16:17:42 -0500 Cc: Internet Architecture Board , tls mailing list , RFC Editor Subject: [TLS] Protocol Action: 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard 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: 0bc60ec82efc80c84b8d02f4b0e4de22 The IESG has approved the following document: - 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS) ' as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary This document specifies the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. Working Group Summary The TLS Working Group reached consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 26 06:57: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 GAA14703; Wed, 26 Jan 2005 06:57:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctm4p-0002tK-0Q; Wed, 26 Jan 2005 07:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctlko-00045W-5B; Wed, 26 Jan 2005 06:54:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtlhZ-0003Yo-K5 for tls@megatron.ietf.org; Wed, 26 Jan 2005 06:51:13 -0500 Received: from mail44.e.nsc.no (mail44.e.nsc.no [193.213.115.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14327 for ; Wed, 26 Jan 2005 06:51:07 -0500 (EST) Received: from epostleser.online.no (epostleser13.frisurf.no [148.122.3.21]) by mail44.nsc.no (8.12.11/8.12.11) with ESMTP id j0QBod7t025287 for ; Wed, 26 Jan 2005 12:50:39 +0100 (CET) X-WebMail-UserID: kankedu@online.no Date: Wed, 26 Jan 2005 12:50:39 +0100 From: Johannes Hoff To: tls@ietf.org X-EXP32-SerialNo: 50000140 Message-ID: <41F80313@epostleser.online.no> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62 Content-Transfer-Encoding: 7bit Subject: [TLS] Comments on alerts decrytion_failed and bad_record_mac 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit In rfc2246-bis-09: > bad_record_mac > This alert is returned if a record is received with an incorrect > MAC. This alert also MUST be returned if an alert is sent because > a TLSCiphertext decrypted in an invalid way: either it wasn't an > even multiple of the block length, or its padding values, when > checked, weren't correct. This message is always fatal. > > decryption_failed > This alert MAY be returned if a TLSCiphertext decrypted in an > invalid way: either it wasn't an even multiple of the block > length, or its padding values, when checked, weren't correct. > This message is always fatal. > NB: Differentiating between bad_record_mac and decryption_failed > alerts may permit certain attacks against CBC mode as used in TLS > [CBCATT]. It is preferable to uniformly use the bad_record_mac > alert to hide the specific type of the error. If I understand this correctly, the following situation occur when I discover a padding error: * I MUST send a bad_record_mac alert. * I MAY also send a decryption_failed alert. (even though it's not recommended) If this is true, it's a great security risks, as it gives very easy access to the error channel (as is the point in Vaudenay et.al.'s attack (CRYPTO2003)). If a server choose to send both messages, there is a trivial mapping from * 1 error message -> bad MAC * 2 error messages -> bad padding or not an even multiple of the block length. My suggestion would be dropping the decryption_failed code from the standard. Any comments? Or maybe someone can point out where I misunderstand :) And a little question on the side: When will TLS1.1 go from a working draft to a proper standard? - Johannes Hoff _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 26 10:20:49 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 KAA05384; Wed, 26 Jan 2005 10:20:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtpFN-0001EI-QU; Wed, 26 Jan 2005 10:38:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctov2-0005ul-Vq; Wed, 26 Jan 2005 10:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctoln-0001uM-9r for tls@megatron.ietf.org; Wed, 26 Jan 2005 10:07:47 -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 KAA03521 for ; Wed, 26 Jan 2005 10:07:44 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctp2h-0000p0-TY for tls@ietf.org; Wed, 26 Jan 2005 10:25:17 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id D622717039; Wed, 26 Jan 2005 07:07:38 -0800 (PST) To: Johannes Hoff Subject: Re: [TLS] Comments on alerts decrytion_failed and bad_record_mac References: <41F80313@epostleser.online.no> From: EKR Date: Wed, 26 Jan 2005 07:07:38 -0800 In-Reply-To: <41F80313@epostleser.online.no> (Johannes Hoff's message of "Wed, 26 Jan 2005 12:50:39 +0100") Message-ID: <864qh4teit.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: 69a74e02bbee44ab4f8eafdbcedd94a1 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Johannes Hoff writes: > In rfc2246-bis-09: >> bad_record_mac >> This alert is returned if a record is received with an incorrect >> MAC. This alert also MUST be returned if an alert is sent because >> a TLSCiphertext decrypted in an invalid way: either it wasn't an >> even multiple of the block length, or its padding values, when >> checked, weren't correct. This message is always fatal. >> >> decryption_failed >> This alert MAY be returned if a TLSCiphertext decrypted in an >> invalid way: either it wasn't an even multiple of the block >> length, or its padding values, when checked, weren't correct. >> This message is always fatal. >> NB: Differentiating between bad_record_mac and decryption_failed >> alerts may permit certain attacks against CBC mode as used in TLS >> [CBCATT]. It is preferable to uniformly use the bad_record_mac >> alert to hide the specific type of the error. > If I understand this correctly, the following situation occur when I discover > a padding error: > * I MUST send a bad_record_mac alert. > * I MAY also send a decryption_failed alert. (even though it's not > recommended) I think this is confusing writing on my part. You should send EITHER alert, not both. > My suggestion would be dropping the decryption_failed code from the standard. I'd prefer to simply deprecate it a bit harder and tighten up this language. > And a little question on the side: When will TLS1.1 go from a > working draft to a proper standard? We've finished WGLC and should be forwarding it to IESG RSN. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 26 15:03:35 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 PAA07631; Wed, 26 Jan 2005 15:03:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cttf3-0001cK-La; Wed, 26 Jan 2005 15:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttI9-0006Mz-RC; Wed, 26 Jan 2005 14:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CthD4-0003r6-5s for tls@megatron.ietf.org; Wed, 26 Jan 2005 02:03:26 -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 CAA28538 for ; Wed, 26 Jan 2005 02:03:23 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id DBE8C10321; Wed, 26 Jan 2005 02:02:53 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id A2E1E10302 for ; Wed, 26 Jan 2005 02:02:53 -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 07054-100 for ; Wed, 26 Jan 2005 02:02:42 -0500 (EST) Received: from sniper.kisa.or.kr (unknown [211.252.150.22]) by mail.ca.certicom.com (Postfix) with SMTP id 2781610321 for ; Wed, 26 Jan 2005 02:02:41 -0500 (EST) Received: (snipe 15744 invoked by alias); 26 Jan 2005 16:02:04 +0900 Received: from jhyoon@kisa.or.kr with Spamsniper 2.83.29 (Processed in 0.009649 secs); Received: from unknown (HELO 5434d1) (172.16.7.114) by unknown with SMTP; 26 Jan 2005 16:02:04 +0900 X-RCPTTO: ietf-tls@lists.certicom.com Message-ID: <002701c50375$0d57c500$720710ac@5434d1> From: "Jaeho Yoon" To: Date: Wed, 26 Jan 2005 16:02:51 +0900 MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Status: No, hits=2.4 tagged_above=0.0 required=5.0 tests=BAYES_10, MIME_BASE64_LATIN, MIME_BASE64_TEXT, UPPERCASE_25_50, X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH X-Spam-Level: ** X-Mailman-Approved-At: Wed, 26 Jan 2005 14:57:28 -0500 Subject: [TLS] SEED Ciphersuites Numbers to 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: , Content-Type: multipart/mixed; boundary="===============0190674697==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0190674697== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBUTFMgR3VydXMsDQoNCkkgc3VibWl0dGVkIHRoaXMgZHJhZnQsICdBZGRpdGlvbiBvZiBT RUVEIENpcGhlcnN1aXRlcyB0byBUTFMnIGFuZCBJIGRlZmluZWQgdGhlIGZvbGxvd2luZyBudW1i ZXJzIGluIHNlY3Rpb24gMi4NCg0KQ2lwaGVyU3VpdGUgVExTX1JTQV9XSVRIX1NFRURfQ0JDX1NI QSAgICAgID0geyAweDAwLDB4NjB9Ow0KQ2lwaGVyU3VpdGUgVExTX0RIX0RTU19XSVRIX1NFRURf Q0JDX1NIQSAgID0geyAweDAwLDB4NjEpOw0KQ2lwaGVyU3VpdGUgVExTX0RIX1JTQV9XSVRIX1NF RURfQ0JDX1NIQSAgID0geyAweDAwLDB4NjIpOw0KQ2lwaGVyU3VpdGUgVExTX0RIRV9EU1NfV0lU SF9TRUVEX0NCQ19TSEEgID0geyAweDAwLDB4NjN9Ow0KQ2lwaGVyU3VpdGUgVExTX0RIRV9SU0Ff V0lUSF9TRUVEX0NCQ19TSEEgID0geyAweDAwLDB4NjR9Ow0KQ2lwaGVyU3VpdGUgVExTX0RIX2Fu b25fV0lUSF9TRUVEX0NCQ19TSEEgID0geyAweDAwLDB4NjV9DQoNCkJ1dCBQYXNpIEVyb25lbiBz dWdnZXN0ZWQgcmVudW1iZXJpbmcgdGhlc2UgY2lwaGVyc3VpdGVzIHRvIDB4MDAsMHg5Ni4uLjB4 OUIuDQoNCkFuZCBvdGhlciBhdXRob3JzIGFuZCBJIGRlY2lkZWQgdG8gYWNjZXB0IFBhc2kncyBz dWdnZXN0aW9uLiANCg0KRG9lcyBhbnlvbmUgaGF2ZSBvdGhlciBvcGluaW9ucyBvbiB0aGVzZSBu dW1iZXJzPyANCg0KVGhhbmtzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkphZWhvIFlvb24sIA0KDQpJbmZyYXN0cnVjdHVyZSBTZWN1cml0 eSBEaXZpc2lvbg0KS29yZWEgSW5mb3JtYXRpb24gU2VjdXJpdHkgQWdlbmN5DQoNCjd0aCBGTCwg V2VzdCBCdWlsZGluZywgSVQgVmVudHVyZSBUb3dlciwgDQo3OCwgR2FyYWsgZG9uZywgU29uZ3Bh IGd1LCBTZW91bCAxMzgtODAzLCBLb3JlYQ0KVEVMIDogKzgyLTItNDA1NS00MzQgIEZBWCA6ICs4 Mi0yLTQwNTUtMjE5DQplLW1haWwgOiBqaHlvb25Aa2lzYS5vci5rcg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --===============0190674697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0190674697==-- From tls-bounces@ietf.org Wed Jan 26 16:12:39 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 QAA19972; Wed, 26 Jan 2005 16:12:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctujt-0005DF-HA; Wed, 26 Jan 2005 16:30:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtttO-0005Zp-FY; Wed, 26 Jan 2005 15:35:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cttqt-00043A-CX for tls@megatron.ietf.org; Wed, 26 Jan 2005 15:33:23 -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 PAA12355 for ; Wed, 26 Jan 2005 15:33:20 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id BC1D8107A8; Wed, 26 Jan 2005 15:32:51 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 97D8F107A7 for ; Wed, 26 Jan 2005 15:32:51 -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 13663-84 for ; Wed, 26 Jan 2005 15:32:40 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id 0833210755 for ; Wed, 26 Jan 2005 15:32:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12297; Wed, 26 Jan 2005 15:32:36 -0500 (EST) Message-Id: <200501262032.PAA12297@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, 26 Jan 2005 15:32:36 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-06.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: 14582b0692e7f70ce7111d04db3781c8 --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 OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-06.txt Pages : 14 Date : 2005-1-26 This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-06.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-openpgp-keys-06.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-openpgp-keys-06.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-1-26155617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-26155617.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 Wed Jan 26 17:20:10 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 RAA28082; Wed, 26 Jan 2005 17:20:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtvnF-0007CT-PP; Wed, 26 Jan 2005 17:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtvUW-0001hO-Sq; Wed, 26 Jan 2005 17:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtvTF-0001Dw-TQ for tls@megatron.ietf.org; Wed, 26 Jan 2005 17:17:05 -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 RAA27887 for ; Wed, 26 Jan 2005 17:17:03 -0500 (EST) Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtvkE-00077i-Rz for tls@ietf.org; Wed, 26 Jan 2005 17:34:40 -0500 Received: from [127.0.0.1] ([82.42.16.116]) by smtp-out5.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jan 2005 22:17:34 +0000 Message-ID: <41F816DA.5080406@blueyonder.co.uk> Date: Wed, 26 Jan 2005 22:16:58 +0000 From: David Hopwood User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Comments on alerts decrytion_failed and bad_record_mac References: <41F80313@epostleser.online.no> In-Reply-To: <41F80313@epostleser.online.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2005 22:17:34.0273 (UTC) FILETIME=[D5BC7B10:01C503F4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Johannes Hoff wrote: > In rfc2246-bis-09: > >>bad_record_mac >> This alert is returned if a record is received with an incorrect >> MAC. This alert also MUST be returned if an alert is sent because >> a TLSCiphertext decrypted in an invalid way: either it wasn't an >> even multiple of the block length, or its padding values, when >> checked, weren't correct. This message is always fatal. >> >>decryption_failed >> This alert MAY be returned if a TLSCiphertext decrypted in an >> invalid way: either it wasn't an even multiple of the block >> length, or its padding values, when checked, weren't correct. >> This message is always fatal. >> NB: Differentiating between bad_record_mac and decryption_failed >> alerts may permit certain attacks against CBC mode as used in TLS >> [CBCATT]. It is preferable to uniformly use the bad_record_mac >> alert to hide the specific type of the error. > > If I understand this correctly, the following situation occur when I discover > a padding error: > * I MUST send a bad_record_mac alert. > * I MAY also send a decryption_failed alert. (even though it's not > recommended) > > If this is true, it's a great security risks, as it gives very easy access to > the error channel (as is the point in Vaudenay et.al.'s attack (CRYPTO2003)). A description of the decryption_failed alert should be retained because previous implementations can generate it, and new implementations must still be prepared to receive it. I suggest the following wording: bad_record_mac This alert MUST be returned if a record is received with an incorrect MAC, or if a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal. decryption_failed Previous versions of TLS (and SSL) allowed this alert to be generated when a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values when checked, weren't correct. However, differentiating between bad_record_mac and decryption_failed alerts may permit certain attacks against CBC mode as used in TLS [CBCATT]. Therefore, decryption_failed MUST NOT be sent in TLS 1.1 sessions. An implementation MUST nevertheless treat a received decryption_failed alert as a fatal error. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 26 17:39:47 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 RAA29214; Wed, 26 Jan 2005 17:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctw6G-0007YS-CU; Wed, 26 Jan 2005 17:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctvmn-0006bQ-Bo; Wed, 26 Jan 2005 17:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctvi8-0005SO-Tj for tls@megatron.ietf.org; Wed, 26 Jan 2005 17:32:29 -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 RAA28793 for ; Wed, 26 Jan 2005 17:32:26 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 07DF0103D9; Wed, 26 Jan 2005 17:31:58 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id C97411054C for ; Wed, 26 Jan 2005 17:31:57 -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 15163-56 for ; Wed, 26 Jan 2005 17:31:46 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.ca.certicom.com (Postfix) with ESMTP id 65484103D9 for ; Wed, 26 Jan 2005 17:31:45 -0500 (EST) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 26 Jan 2005 14:31:50 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 26 Jan 2005 14:31:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jan 2005 14:31:42 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 26 Jan 2005 14:31:43 -0800 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] SEED Ciphersuites Numbers to TLS Date: Wed, 26 Jan 2005 14:31:43 -0800 Message-ID: <077993C42708BA438E9013BB10111C8208C80E35@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [TLS] SEED Ciphersuites Numbers to TLS Thread-Index: AcUD4jeCh2tSHUOVTWKluHbk0uUBxQAFC8bw From: "John Banes" To: "Jaeho Yoon" , X-OriginalArrivalTime: 26 Jan 2005 22:31:43.0426 (UTC) FILETIME=[CFDEF220:01C503F6] 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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Sounds like a good suggestion. Your original numbers conflict with ones defined in the 56-bit cipher suite draft specification. This draft was never pushed through the standard process (because the author got lazy in my opinion); however it has been widely implemented. Regards, John -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Jaeho Yoon Sent: Tuesday, January 25, 2005 11:03 PM To: ietf-tls@lists.certicom.com Subject: [TLS] SEED Ciphersuites Numbers to TLS=20 Importance: High Dear TLS Gurus, I submitted this draft, 'Addition of SEED Ciphersuites to TLS' and I defined the following numbers in section 2. CipherSuite TLS_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x60}; CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA =3D { 0x00,0x61); CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x62); CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA =3D { 0x00,0x63}; CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA =3D { 0x00,0x64}; CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA =3D { 0x00,0x65} But Pasi Eronen suggested renumbering these ciphersuites to 0x00,0x96...0x9B. And other authors and I decided to accept Pasi's suggestion.=20 Does anyone have other opinions on these numbers?=20 Thanks. --------------------------------------------------- Jaeho Yoon,=20 Infrastructure Security Division Korea Information Security Agency 7th FL, West Building, IT Venture Tower,=20 78, Garak dong, Songpa gu, Seoul 138-803, Korea TEL : +82-2-4055-434 FAX : +82-2-4055-219 e-mail : jhyoon@kisa.or.kr --------------------------------------------------- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Jan 26 18:32: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 SAA03552; Wed, 26 Jan 2005 18:32:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtwvV-00006i-4p; Wed, 26 Jan 2005 18:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtwYC-0008M9-RM; Wed, 26 Jan 2005 18:26:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtwUY-0007tW-Dy for tls@megatron.ietf.org; Wed, 26 Jan 2005 18:22:30 -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 SAA02946 for ; Wed, 26 Jan 2005 18:22:27 -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 1CtwlY-0008LS-Hv for tls@ietf.org; Wed, 26 Jan 2005 18:40:04 -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 AC58D2C98; Thu, 27 Jan 2005 00:21:56 +0100 (MET) Received: (from moeller@localhost) by cdc-ultra5.cdc.informatik.tu-darmstadt.de (8.11.7p1+Sun/8.11.7) id j0QNLtM20628; Thu, 27 Jan 2005 00:21:55 +0100 (MET) Date: Thu, 27 Jan 2005 00:21:55 +0100 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] Comments on alerts decrytion_failed and bad_record_mac Message-ID: <20050127002155.A20600@cdc.informatik.tu-darmstadt.de> References: <41F80313@epostleser.online.no> <41F816DA.5080406@blueyonder.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <41F816DA.5080406@blueyonder.co.uk>; from david.nospam.hopwood@blueyonder.co.uk on Wed, Jan 26, 2005 at 10:16:58PM +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: b19722fc8d3865b147c75ae2495625f2 On Wed, Jan 26, 2005 at 10:16:58PM +0000, David Hopwood wrote: > A description of the decryption_failed alert should be retained because > previous implementations can generate it, and new implementations must > still be prepared to receive it. I suggest the following wording: > > bad_record_mac > This alert MUST be returned if a record is received with an > incorrect MAC, or if a TLSCiphertext decrypted in an invalid way: > either it wasn't an even multiple of the block length, or its > padding values, when checked, weren't correct. This message is > always fatal. > > decryption_failed > Previous versions of TLS (and SSL) allowed this alert to be > generated when a TLSCiphertext decrypted in an invalid way: either > it wasn't an even multiple of the block length, or its padding > values when checked, weren't correct. However, differentiating > between bad_record_mac and decryption_failed alerts may permit > certain attacks against CBC mode as used in TLS [CBCATT]. > Therefore, decryption_failed MUST NOT be sent in TLS 1.1 sessions. > An implementation MUST nevertheless treat a received > decryption_failed alert as a fatal error. Just one correction: The decryption_failed alert is not specified for SSL 3.0, so instead of "previous versions of TLS (and SSL)", we should say "TLS version 1.0". _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 31 14:29:00 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 OAA10037; Mon, 31 Jan 2005 14:29:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvhWL-00046i-C7; Mon, 31 Jan 2005 14:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvhD8-0002OH-6I; Mon, 31 Jan 2005 14:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvh48-0001Kg-Ry for tls@megatron.ietf.org; Mon, 31 Jan 2005 14:18:29 -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 OAA09113 for ; Mon, 31 Jan 2005 14:18:27 -0500 (EST) Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvhM8-0003tn-QA for tls@ietf.org; Mon, 31 Jan 2005 14:37:05 -0500 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jan 2005 22:18:28 +0300 Message-ID: <18c201c507c9$a4a031b0$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: References: <6.1.2.0.2.20041023145812.044fa270@mail.binhost.com> Subject: Re: [TLS] PRF Negotiation Date: Mon, 31 Jan 2005 22:18:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 31 Jan 2005 19:18:28.0147 (UTC) FILETIME=[A49C8830:01C507C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Greetings. What bothers me, is that at least in case with GOST, PRF selection is closely tied with ciphersuite choice. We made it an extension just to be compatible with current TLS RFC. Maybe the best way would be just to state that PRF, handshake hash and MAC algorithm selection is also part of ciphersuite, like Dan sujested. That would save some traffic (those extensions can waste up to 100 bytes), and ease implementation. But i'm afraid, it's too late for such modifications to rfc2246bis? Greg ----- Original Message ----- From: "Russ Housley" To: "Dan Simon" ; Sent: Saturday, October 23, 2004 10:06 PM Subject: [TLS] PRF Negotiation > The PRF is not currently negotiated as part of the cipher suite. However, > the draft-ietf-tls-gost-00.txt draft proposes a way to negotiate the PRF, > but it is done independently from the rest of the algorithm negotiations. > > Given that at least one person other than the GOST algorithm specification > authors is interested in PRF negotiation, I would like to see a discussion > about this topic. Have the GOST algorithm specification authors done this > in the best possible way? What are the alternatives? > > The GOST algorithm specification authors' proposal also has an impact on > the Finished message. This leads to other questions. Can one negotiate > which hash function to use when that hash function is in turn used to > protect the integrity of the whole algorithm negotiation process? > > Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Jan 31 14:38:58 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 OAA10861; Mon, 31 Jan 2005 14:38:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvhfz-0004Il-Uc; Mon, 31 Jan 2005 14:57:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvhN3-0003Qf-94; Mon, 31 Jan 2005 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvhLE-0003Jf-Vi for tls@megatron.ietf.org; Mon, 31 Jan 2005 14:36:09 -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 OAA10724 for ; Mon, 31 Jan 2005 14:36:07 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvhdC-0004Ek-6J for tls@ietf.org; Mon, 31 Jan 2005 14:54:45 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 3172C1702E; Mon, 31 Jan 2005 11:35:54 -0800 (PST) To: "Gregory S. Chudov" Subject: Re: [TLS] PRF Negotiation References: <6.1.2.0.2.20041023145812.044fa270@mail.binhost.com> <18c201c507c9$a4a031b0$0644a8c0@cp.ru> From: Eric Rescorla Date: Mon, 31 Jan 2005 11:35:54 -0800 In-Reply-To: <18c201c507c9$a4a031b0$0644a8c0@cp.ru> (Gregory S. Chudov's message of "Mon, 31 Jan 2005 22:18:28 +0300") Message-ID: <86zmyppf1h.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: cf4fa59384e76e63313391b70cd0dd25 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@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 "Gregory S. Chudov" writes: > What bothers me, is that at least in case with GOST, PRF selection > is closely tied with ciphersuite choice. We made it an extension just > to be compatible with current TLS RFC. Maybe the best way would > be just to state that PRF, handshake hash and MAC algorithm selection > is also part of ciphersuite, like Dan sujested. That would save some > traffic (those extensions can waste up to 100 bytes), and ease > implementation. > > But i'm afraid, it's too late for such modifications to rfc2246bis? I think it's *way* too late to make a major technical change like this to RFC 2246-bis. If the only thing one is saving is 100 bytes of traffic, that doesn't seem like that big a win. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls