From tls-bounces@lists.ietf.org Sat Jun 03 12:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYpp-0000Vd-Rk; Sat, 03 Jun 2006 12:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYpo-0000VV-Nh for tls@ietf.org; Sat, 03 Jun 2006 12:18:44 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYpn-0001lC-8S for tls@ietf.org; Sat, 03 Jun 2006 12:18:44 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k53GIZ5k014541; Sat, 3 Jun 2006 19:18:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Jun 2006 19:18:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Jun 2006 19:18:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Review of draft-housley-tls-authz-extns-05 Date: Sat, 3 Jun 2006 19:18:40 +0300 Message-ID: In-Reply-To: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-housley-tls-authz-extns-05 Thread-Index: AcaE/epmezPHxon2Q4OfOpB8xYlb+ACK2/aw From: To: X-OriginalArrivalTime: 03 Jun 2006 16:18:40.0345 (UTC) FILETIME=[602A9490:01C68729] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: hartmans-ietf@mit.edu, mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > >The part about X.509 attribute certificates looks fine, but > >at least the SAML part still needs some work: > > > >1) I think the document needs to discuss the security considerations > > of bearer SAML assertions in more detail. While the > > countermeasures described in 3.3.2 may help against passive > > eavesdroppers, they still allow an active MiTM to "steal" the > > permission. This is IMHO a significant difference to typical > > SAML usage with HTTP-over-TLS, where the server is > > authenticated before the bearer assertion is sent. >=20 > Does this proposed text solve your concern? >=20 > The use of bearer SAML assertions allows an eavesdropper or a > man-in-the-middle to capture the SAML assertion and try to reuse > it in another context. The constraints discussed in Section > 3.3.2 might be effective against an eavesdropper, but they are > less likely to be effective against a man-in-the-middle. > Authentication of both parties in the TLS session, which > involves the use of client authentication, will prevent an > undetected man-in the-middle, and the use of the double > handshake illustrated in Figure 2 will prevent the disclosure of > the bearer SAML assertion to any party other than the TLS peer. Yes, this is significantly better. > >2) Section 3.3.2: "When SAMLAssertion is used, the field contains=20 > > XML constructs with a nested structure defined in > > [SAML1.1][SAML2.0]." This needs to be much more specific than > > "some XML from these documents". What element/elements? Is this > > an XML document (with XML declaration etc.), or just a > > "fragment"? Which encoding? And so on... >=20 > Does this proposed text solve your concern? >=20 > When SAMLAssertion is used, the field contains an XML-encoded > element using the AssertionType complex type as > defined in [SAML1.1][SAML2.0]. We also need to specify the character-to-octet encoding (UTF-8 would be the most logical alternative). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 03 13:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaBP-0007Kv-Ie; Sat, 03 Jun 2006 13:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaBO-0007Kq-HG for tls@ietf.org; Sat, 03 Jun 2006 13:45:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaBN-0001nD-7I for tls@ietf.org; Sat, 03 Jun 2006 13:45:06 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2FAEFE000C; Sat, 3 Jun 2006 13:44:56 -0400 (EDT) To: Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05 References: From: Sam Hartman Date: Sat, 03 Jun 2006 13:44:56 -0400 In-Reply-To: (Pasi Eronen's message of "Sat, 3 Jun 2006 19:18:40 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org >>>>> "p" == writes: p> Russ Housley wrote: >> >The part about X.509 attribute certificates looks fine, but >> >at least the SAML part still needs some work: >> When SAMLAssertion is used, the field contains an XML-encoded >> element using the AssertionType complex type as >> defined in [SAML1.1][SAML2.0]. p> We also need to specify the character-to-octet encoding (UTF-8 p> would be the most logical alternative). It's my understanding that saying it is XML already gives us that: mandatory UTF8 or UTF16 support at the encoder's option. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 03 14:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmaz3-0003SF-4T; Sat, 03 Jun 2006 14:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmaz1-0003SA-IF for tls@ietf.org; Sat, 03 Jun 2006 14:36:23 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fmaz0-0006Nc-B6 for tls@ietf.org; Sat, 03 Jun 2006 14:36:23 -0400 Received: (qmail 6309 invoked by uid 0); 3 Jun 2006 18:36:17 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.46) by woodstock.binhost.com with SMTP; 3 Jun 2006 18:36:17 -0000 Message-Id: <7.0.0.16.2.20060603143541.0700f438@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 03 Jun 2006 14:36:13 -0400 To: From: Russ Housley Subject: RE: [TLS] Review of draft-housley-tls-authz-extns-05 In-Reply-To: References: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: hartmans-ietf@mit.edu, mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org Great. I'll make these updates and submit the revised document. Russ At 12:18 PM 6/3/2006, Pasi.Eronen@nokia.com wrote: >Russ Housley wrote: > > > >The part about X.509 attribute certificates looks fine, but > > >at least the SAML part still needs some work: > > > > > >1) I think the document needs to discuss the security considerations > > > of bearer SAML assertions in more detail. While the > > > countermeasures described in 3.3.2 may help against passive > > > eavesdroppers, they still allow an active MiTM to "steal" the > > > permission. This is IMHO a significant difference to typical > > > SAML usage with HTTP-over-TLS, where the server is > > > authenticated before the bearer assertion is sent. > > > > Does this proposed text solve your concern? > > > > The use of bearer SAML assertions allows an eavesdropper or a > > man-in-the-middle to capture the SAML assertion and try to reuse > > it in another context. The constraints discussed in Section > > 3.3.2 might be effective against an eavesdropper, but they are > > less likely to be effective against a man-in-the-middle. > > Authentication of both parties in the TLS session, which > > involves the use of client authentication, will prevent an > > undetected man-in the-middle, and the use of the double > > handshake illustrated in Figure 2 will prevent the disclosure of > > the bearer SAML assertion to any party other than the TLS peer. > >Yes, this is significantly better. > > > >2) Section 3.3.2: "When SAMLAssertion is used, the field contains > > > XML constructs with a nested structure defined in > > > [SAML1.1][SAML2.0]." This needs to be much more specific than > > > "some XML from these documents". What element/elements? Is this > > > an XML document (with XML declaration etc.), or just a > > > "fragment"? Which encoding? And so on... > > > > Does this proposed text solve your concern? > > > > When SAMLAssertion is used, the field contains an XML-encoded > > element using the AssertionType complex type as > > defined in [SAML1.1][SAML2.0]. > >We also need to specify the character-to-octet encoding (UTF-8 would >be the most logical alternative). > >Best regards, >Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 03 14:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmbAF-00077z-VF; Sat, 03 Jun 2006 14:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmbAE-00077u-Lz for tls@ietf.org; Sat, 03 Jun 2006 14:47:58 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmbAD-0007Jd-Eq for tls@ietf.org; Sat, 03 Jun 2006 14:47:58 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B8CF0E000C; Sat, 3 Jun 2006 14:47:50 -0400 (EDT) To: Russ Housley Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05 References: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> <7.0.0.16.2.20060603143541.0700f438@vigilsec.com> From: Sam Hartman Date: Sat, 03 Jun 2006 14:47:50 -0400 In-Reply-To: <7.0.0.16.2.20060603143541.0700f438@vigilsec.com> (Russ Housley's message of "Sat, 03 Jun 2006 14:36:13 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org >>>>> "Russ" == Russ Housley writes: Russ> Great. I'll make these updates and submit the revised Russ> document. Russ Russ, please confirm with an XML expert that restricting to UTF8 is acceptable. In the past Scott would object to that. My preference is for you to say nothing about character encoding unless you need to do so to be unambiguous. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 03 17:51:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fme1s-0001xR-HJ; Sat, 03 Jun 2006 17:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fme1q-0001pS-Sm for tls@ietf.org; Sat, 03 Jun 2006 17:51:30 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fme1p-0001Y2-LY for tls@ietf.org; Sat, 03 Jun 2006 17:51:30 -0400 Received: (qmail 29055 invoked by uid 0); 3 Jun 2006 21:51:22 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.46) by woodstock.binhost.com with SMTP; 3 Jun 2006 21:51:22 -0000 Message-Id: <7.0.0.16.2.20060603174655.06f9fa30@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 03 Jun 2006 17:48:41 -0400 To: Sam Hartman From: Russ Housley Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05 In-Reply-To: References: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> <7.0.0.16.2.20060603143541.0700f438@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org The text that I proposed said noting. Here is my proposed way forward: Post the test that I proposed, then ask Scott to look at it. If he recommends a character set statement, we'll add it during IESG Evaluation, probably with an RFC Editor note. Russ At 02:47 PM 6/3/2006, Sam Hartman wrote: > >>>>> "Russ" == Russ Housley writes: > > Russ> Great. I'll make these updates and submit the revised > Russ> document. Russ > >Russ, please confirm with an XML expert that restricting to UTF8 is >acceptable. In the past Scott would object to that. My preference is >for you to say nothing about character encoding unless you need to do >so to be unambiguous. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 05 05:00:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnAwX-0005ay-9b; Mon, 05 Jun 2006 05:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnAwW-0005as-BI for tls@ietf.org; Mon, 05 Jun 2006 05:00:12 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnAwU-0000uR-UU for tls@ietf.org; Mon, 05 Jun 2006 05:00:12 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k55908bc002042; Mon, 5 Jun 2006 12:00:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 12:00:08 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 12:00:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Review of draft-housley-tls-authz-extns-05 Date: Mon, 5 Jun 2006 12:00:06 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-housley-tls-authz-extns-05 Thread-Index: AcaHNX30nUMsvvFoShSwXEL/SDYhlgBRkQuw From: To: X-OriginalArrivalTime: 05 Jun 2006 09:00:08.0537 (UTC) FILETIME=[71EECC90:01C6887E] X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org Sam Hartman wrote: > p> We also need to specify the character-to-octet encoding (UTF-8 > p> would be the most logical alternative). >=20 > It's my understanding that saying it is XML already gives us that: > mandatory UTF8 or UTF16 support at the encoder's option. Yes, but the recipient has to know which encoding was used (others=20 than UTF8/UTF16 are permitted).=20 In a complete XML document, the XML declaration usually contains=20 this information (e.g. "">, but currently the AuthorizationData contains just one Assertion element, not a complete document. I'm not really an XML expert, but I think the options available to use would be including this information in the "transport" (e.g., specify it's UTF-8, or include a field for encoding name), or mandating that AuthorizationData has to include the XML text declaration before the Assertion element. Any opinions from XML experts? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 05 07:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnCqM-0003Ft-In; Mon, 05 Jun 2006 07:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnCqL-0003Fn-4S for tls@ietf.org; Mon, 05 Jun 2006 07:01:57 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnCqJ-0006Y7-RL for tls@ietf.org; Mon, 05 Jun 2006 07:01:57 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id k55B4gJC023820; Mon, 5 Jun 2006 07:04:55 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 07:01:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Review of draft-housley-tls-authz-extns-05 Date: Mon, 5 Jun 2006 07:01:22 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070152A5E0@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-housley-tls-authz-extns-05 Thread-Index: AcaHNX30nUMsvvFoShSwXEL/SDYhlgBRkQuwAASzKAA= From: "Hollenbeck, Scott" To: , X-OriginalArrivalTime: 05 Jun 2006 11:01:21.0196 (UTC) FILETIME=[60C67EC0:01C6888F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Monday, June 05, 2006 5:00 AM > To: hartmans-ietf@mit.edu > Cc: mark@redphonesecurity.com; tls@ietf.org > Subject: RE: [TLS] Review of draft-housley-tls-authz-extns-05 >=20 > Sam Hartman wrote: >=20 > > p> We also need to specify the character-to-octet encoding (UTF-8 > > p> would be the most logical alternative). > >=20 > > It's my understanding that saying it is XML already gives us that: > > mandatory UTF8 or UTF16 support at the encoder's option. >=20 > Yes, but the recipient has to know which encoding was used (others=20 > than UTF8/UTF16 are permitted).=20 >=20 > In a complete XML document, the XML declaration usually contains=20 > this information (e.g. "">, but currently > the AuthorizationData contains just one Assertion element, not > a complete document. >=20 > I'm not really an XML expert, but I think the options available > to use would be including this information in the "transport" > (e.g., specify it's UTF-8, or include a field for encoding name), > or mandating that AuthorizationData has to include the XML text > declaration before the Assertion element. >=20 > Any opinions from XML experts? Section 5.1 of RFC 3470/BCP 70 includes relevant text. In a nutshell, UTF-8 is a MUST if you're using XML. UTF-16 is recommended since you get it for free with XML parsers, but it's not required. An XML declaration is not needed if you're using either UTF-8 or UTF-16. A byte order mark is required with UTF-16. Other encodings are possible, but if something else is used it must be identified with an appropriate XML declaration. -Scott- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 05 09:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFF7-0004h5-KW; Mon, 05 Jun 2006 09:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFEn-0004Nz-Kz for tls@ietf.org; Mon, 05 Jun 2006 09:35:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnDft-00060m-Ax for tls@ietf.org; Mon, 05 Jun 2006 07:55:13 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnDYq-0006La-BB for tls@ietf.org; Mon, 05 Jun 2006 07:47:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k55BlrV4026524; Mon, 5 Jun 2006 14:47:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 14:47:54 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 14:47:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Review of draft-housley-tls-authz-extns-05 Date: Mon, 5 Jun 2006 14:47:56 +0300 Message-ID: In-Reply-To: <046F43A8D79C794FA4733814869CDF070152A5E0@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-housley-tls-authz-extns-05 Thread-Index: AcaHNX30nUMsvvFoShSwXEL/SDYhlgBRkQuwAASzKAAAAIvrIA== From: To: , X-OriginalArrivalTime: 05 Jun 2006 11:47:54.0355 (UTC) FILETIME=[E1A0BC30:01C68895] X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mark@redphonesecurity.com, 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: , Errors-To: tls-bounces@lists.ietf.org Scott Hollenbeck wrote: > Section 5.1 of RFC 3470/BCP 70 includes relevant text. In a > nutshell, UTF-8 is a MUST if you're using XML. UTF-16 is > recommended since you get it for free with XML parsers, but it's not > required. An XML declaration is not needed if you're using either > UTF-8 or UTF-16. A byte order mark is required with UTF-16. Other > encodings are possible, but if something else is used it must be > identified with an appropriate XML declaration. Thanks for the pointer; it looks like Section 4.1 of the document=20 is also relevant: In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set. Protocol specifications must be clear about use of XML declarations. XML [8] notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16. =20 Since the latter paragraph says that XML declaration must always be allowed, the simplest approach would be to always require it here. In other words, draft-housley-tls-authz-extns should say something like this, right? "When SAMLAssertion is used, the field contains an XML text declaration, followed by an element using the AssertionType complex type as defined in [SAML1.1][SAML2.0].=20 The field MUST also follow the rules of [XML] for including the Byte Order Mark (BOM) in encoded entities." Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 06 15:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhYx-0001fp-L1; Tue, 06 Jun 2006 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhYw-0001fB-CR; Tue, 06 Jun 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhYw-0005hX-1y; Tue, 06 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k56Jo1Hp022986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnhYv-0007Lu-IZ; Tue, 06 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-10.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-10.txt Pages : 11 Date : 2006-6-6 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-openpgp-keys-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-openpgp-keys-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-6115537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-6115537.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Jun 14 07:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTN8-0003nK-8L; Wed, 14 Jun 2006 07:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTN7-0003my-3T for tls@ietf.org; Wed, 14 Jun 2006 07:17:17 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqTN5-00080K-QT for tls@ietf.org; Wed, 14 Jun 2006 07:17:17 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for stiedprmail1.ietf.org [156.154.16.150]) with SMTP; Wed, 14 Jun 2006 07:16:19 -0400 Received: from sdtihq24.securid.com by hyperion.na.rsa.net with ESMTP id CPH81968; Wed, 14 Jun 2006 07:21:41 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k5EBH9DU002707 for ; Wed, 14 Jun 2006 07:17:14 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68FA4.12B1DABC" Date: Wed, 14 Jun 2006 07:17:06 -0400 Message-ID: X-MS-Has-Attach: yes Thread-Topic: OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYA From: "Linn, John" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= Subject: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-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: , Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FA4.12B1DABC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This recent I-D constitutes a profile layered on TLS-PSK, intended to = authenticate TLS connections with the general class of One-Time Password = (OTP) methods. We'd like to invite review and comment in the TLS WG. =20 --jl -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, June 07, 2006 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linn-otp-tls-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : OTP Methods for TLS Author(s) : J. Linn, M. Nystroem Filename : draft-linn-otp-tls-00.txt Pages : 21 Date : 2006-6-7 =09 This document describes means for applying One-Time Password (OTP) methods to authenticate Transport Layer Security sessions, operating in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use with TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linn-otp-tls-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-linn-otp-tls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-linn-otp-tls-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C68FA4.12B1DABC Content-Type: application/octet-stream; name="ATT1189699.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1189699.TXT Content-Disposition: attachment; filename="ATT1189699.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTcxMTEyMjQuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGlubi1vdHAtdGxzLTAwLnR4 dA0K ------_=_NextPart_001_01C68FA4.12B1DABC Content-Type: application/octet-stream; name="draft-linn-otp-tls-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-linn-otp-tls-00.URL Content-Disposition: attachment; filename="draft-linn-otp-tls-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW5uLW90cC10bHMtMDAudHh0DQo= ------_=_NextPart_001_01C68FA4.12B1DABC Content-Type: text/plain; name="ATT1189700.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1189700.txt Content-Disposition: attachment; filename="ATT1189700.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C68FA4.12B1DABC Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------_=_NextPart_001_01C68FA4.12B1DABC-- From tls-bounces@lists.ietf.org Wed Jun 14 07:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTQm-0006Tt-3N; Wed, 14 Jun 2006 07:21:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTQl-0006Tn-0j for tls@ietf.org; Wed, 14 Jun 2006 07:21:03 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTQj-0000D7-Fi for tls@ietf.org; Wed, 14 Jun 2006 07:21:03 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5EBL0gE009338; Wed, 14 Jun 2006 13:21:00 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5EBL0Ql006308; Wed, 14 Jun 2006 13:21:00 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 13:21:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Wed, 14 Jun 2006 13:20:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAACWSUtA= From: "Tschofenig, Hannes" To: "Linn, John" , X-OriginalArrivalTime: 14 Jun 2006 11:21:00.0128 (UTC) FILETIME=[9D30FE00:01C68FA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= 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: , Errors-To: tls-bounces@lists.ietf.org Since OTP is available via EAP methods it is also possible to use=20 http://www.tschofenig.com/drafts/draft-funk-tls-inner-application-extensi= on-02.txt This would avoid putting every single EAP method inside the TLS = handshake. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Linn, John [mailto:jlinn@rsasecurity.com]=20 > Gesendet: Mittwoch, 14. Juni 2006 13:17 > An: tls@ietf.org > Cc: Nystr=F6m, Magnus > Betreff: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > This recent I-D constitutes a profile layered on TLS-PSK,=20 > intended to authenticate TLS connections with the general=20 > class of One-Time Password (OTP) methods. We'd like to=20 > invite review and comment in the TLS WG. =20 >=20 > --jl >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, June 07, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-linn-otp-tls-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : OTP Methods for TLS > Author(s) : J. Linn, M. Nystroem > Filename : draft-linn-otp-tls-00.txt > Pages : 21 > Date : 2006-6-7 > =09 > This document describes means for applying One-Time Password (OTP) > methods to authenticate Transport Layer Security sessions, operating > in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use > with TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-linn-otp-tls-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-linn-otp-tls-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-linn-otp-tls-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 16 15:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKg-0007en-4Q; Fri, 16 Jun 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKR-0007YL-AY; Fri, 16 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKKQ-0000er-NU; Fri, 16 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5GJo2Rx030938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FrKKQ-0004sl-Do; Fri, 16 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ctr-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Counter Mode Cipher Suites for TLS and DTLS Author(s) : N. Modadugu, E. Rescorla Filename : draft-ietf-tls-ctr-01.txt Pages : 10 Date : 2006-6-16 This document describes the use of the Advanced Encryption Standard (AES) Counter Mode for use as a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ctr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ctr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-16144325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ctr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ctr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-16144325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Fri Jun 16 16:30:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKxF-0000cF-Qi; Fri, 16 Jun 2006 16:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKxE-0000cA-Jn for tls@ietf.org; Fri, 16 Jun 2006 16:30:08 -0400 Received: from smtp3-g19.free.fr ([212.27.42.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKxD-0005qw-55 for tls@ietf.org; Fri, 16 Jun 2006 16:30:08 -0400 Received: from enst.fr (mar92-11-82-245-209-5.fbx.proxad.net [82.245.209.5]) by smtp3-g19.free.fr (Postfix) with ESMTP id 2C03D49818 for ; Fri, 16 Jun 2006 22:30:06 +0200 (CEST) Message-ID: <449314C8.6090301@enst.fr> Date: Fri, 16 Jun 2006 22:30:00 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: tls Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-01.txt] X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear all, A new version of MTLS (TLS Multiplexing) is available at=20 http://www.ietf.org/internet-drafts/draft-badra-hajjeh-mtls-01.txt Comments are welcome... Best regards, Badra -------- Message d'origine -------- Sujet: I-D ACTION:draft-badra-hajjeh-mtls-01.txt Date: Fri, 16 Jun 2006 15:50:02 -0400 De: Internet-Drafts@ietf.org R=E9pondre-A: internet-drafts@ietf.org A: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : MTLS: TLS Multiplexing Author(s) : M. Badra, I. Hajjeh Filename : draft-badra-hajjeh-mtls-01.txt Pages : 9 Date : 2006-6-16 =09 The Transport Layer Security (TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex application data over a single TLS session. This document defines MTLS, a new TLS sub-protocol running over TLS (or DTLS) Record protocol. The MTLS design provides application multiplexing over a single TLS (or DTLS) session. Therefore, instead of associating a TLS connection with each application, MTLS allows several applications to protect their exchanges over a single TLS session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-badra-hajjeh-mtls-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 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 usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-badra-hajjeh-mtls-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-badra-hajjeh-mtls-01.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 19 08:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIjA-0006aZ-7W; Mon, 19 Jun 2006 08:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIj8-0006aU-U5 for tls@ietf.org; Mon, 19 Jun 2006 08:19:34 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIj8-00023a-Jk for tls@ietf.org; Mon, 19 Jun 2006 08:19:34 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for stiedprmail1.ietf.org [156.154.16.150]) with ESMTP; Mon, 19 Jun 2006 08:18:36 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPN14164; Mon, 19 Jun 2006 08:11:17 +0500 (GMT-5) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k5JC9PDU017773; Mon, 19 Jun 2006 08:09:25 -0400 (EDT) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 08:09:25 -0400 Received: from localhost ([10.129.13.11]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 05:09:32 -0700 Date: Mon, 19 Jun 2006 14:09:47 +0200 (W. Europe Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: "Tschofenig, Hannes" Subject: Re: AW: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] In-Reply-To: Message-ID: References: X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="17534373-32636-1150718987=:5356" X-OriginalArrivalTime: 19 Jun 2006 12:09:33.0024 (UTC) FILETIME=[397A6600:01C69399] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: magnus@rsasecurity.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --17534373-32636-1150718987=:5356 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Hannes, Yes, the cited I-D would, if implemented, enable another method of using=20 OTPs within TLS - one could do EAP-POTP within the EAP-Message etc. RADIUS= =20 attributes, encapsulated in the IA phase of TLS-IA. It seems, however, to complicate deployments quite a lot to introduce a=20 requirement for EAP as well as elements of RADIUS and Diameter just to=20 support OTPs in TLS now that TLS-PSK exists. And, contrary to what is=20 stated in the TLS-IA I-D, TLS-PSK does allow use of a server certificate=20 in conjunction with PSKs. We therefore feel that the draft provides some=20 advantages over the alternative of using EAP-POTP within TLS-IA. -- Magnus On Wed, 14 Jun 2006, Tschofenig, Hannes wrote: > Since OTP is available via EAP methods it is also possible to use=20 > http://www.tschofenig.com/drafts/draft-funk-tls-inner-application-extensi= on-02.txt > > This would avoid putting every single EAP method inside the TLS=20 > handshake. > > Ciao > Hannes > >> -----Urspr=FCngliche Nachricht----- >> Von: Linn, John [mailto:jlinn@rsasecurity.com] >> Gesendet: Mittwoch, 14. Juni 2006 13:17 >> An: tls@ietf.org >> Cc: Nystr=F6m, Magnus >> Betreff: [TLS] OTP-TLS I-D [Was: FW: I-D >> ACTION:draft-linn-otp-tls-00.txt] >> >> This recent I-D constitutes a profile layered on TLS-PSK, >> intended to authenticate TLS connections with the general >> class of One-Time Password (OTP) methods. We'd like to >> invite review and comment in the TLS WG. >> >> --jl >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Wednesday, June 07, 2006 3:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-linn-otp-tls-00.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> =09Title=09=09: OTP Methods for TLS >> =09Author(s)=09: J. Linn, M. Nystroem >> =09Filename=09: draft-linn-otp-tls-00.txt >> =09Pages=09=09: 21 >> =09Date=09=09: 2006-6-7 >> >> This document describes means for applying One-Time Password (OTP) >> methods to authenticate Transport Layer Security sessions, operating >> in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use >> with TLS. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-linn-otp-tls-00.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 >> =09"get draft-linn-otp-tls-00.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: >> =09mailserv@ietf.org. >> In the body type: >> =09"FILE /internet-drafts/draft-linn-otp-tls-00.txt". >> >> NOTE:=09The mail server at ietf.org can return the document in >> =09MIME-encoded form by using the "mpack" utility. To use this >> =09feature, insert the command "ENCODING mime" before the "FILE" >> =09command. To decode the response(s), you will need "munpack" or >> =09a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> =09exhibit different behavior, especially when dealing with >> =09"multipart" MIME messages (i.e. documents which have been split >> =09up into multiple messages), so check your local documentation on >> =09how 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. >> > --17534373-32636-1150718987=:5356 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --17534373-32636-1150718987=:5356-- From tls-bounces@lists.ietf.org Mon Jun 19 08:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIu3-0003My-6g; Mon, 19 Jun 2006 08:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIu2-0003Mt-FO for tls@ietf.org; Mon, 19 Jun 2006 08:30:50 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIu0-0002gJ-SF for tls@ietf.org; Mon, 19 Jun 2006 08:30:50 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5JCUl6i006138; Mon, 19 Jun 2006 14:30:47 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5JCUkab025600; Mon, 19 Jun 2006 14:30:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 14:30:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Mon, 19 Jun 2006 14:30:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaTmqG/0gWISbKXSP69UXlSKZ15cAAAMcCw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 12:30:46.0519 (UTC) FILETIME=[308A5070:01C6939C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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: , Errors-To: tls-bounces@lists.ietf.org Hi Magnus,=20 > Hello Hannes, >=20 > Yes, the cited I-D would, if implemented, enable another=20 > method of using=20 > OTPs within TLS - one could do EAP-POTP within the=20 > EAP-Message etc. RADIUS=20 > attributes, encapsulated in the IA phase of TLS-IA. Actually, the draft is already implemented. See=20 http://www.gnu.org/software/gnutls/ >=20 > It seems, however, to complicate deployments quite a lot to=20 > introduce a=20 > requirement for EAP as well as elements of RADIUS and=20 > Diameter just to=20 > support OTPs in TLS now that TLS-PSK exists. And, contrary to what is=20 > stated in the TLS-IA I-D, TLS-PSK does allow use of a server=20 > certificate=20 > in conjunction with PSKs. We therefore feel that the draft=20 > provides some=20 > advantages over the alternative of using EAP-POTP within TLS-IA One of the comments we received (from Pasi) was that we should focus = only on the usage of EAP rather than provide a more generic container. = That seems to be fine with me and I am going to soon make these changes = to the draft. The extension will then be a lot simpler.=20 I hope it could then better fit your needs.=20 Ciao Hannes . >=20 > -- Magnus >=20 > On Wed, 14 Jun 2006, Tschofenig, Hannes wrote: >=20 > > Since OTP is available via EAP methods it is also possible to use=20 > >=20 > http://www.tschofenig.com/drafts/draft-funk-tls-inner-applicat > ion-extension-02.txt > > > > This would avoid putting every single EAP method inside the TLS=20 > > handshake. > > > > Ciao > > Hannes > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Linn, John [mailto:jlinn@rsasecurity.com] > >> Gesendet: Mittwoch, 14. Juni 2006 13:17 > >> An: tls@ietf.org > >> Cc: Nystr=F6m, Magnus > >> Betreff: [TLS] OTP-TLS I-D [Was: FW: I-D > >> ACTION:draft-linn-otp-tls-00.txt] > >> > >> This recent I-D constitutes a profile layered on TLS-PSK, > >> intended to authenticate TLS connections with the general > >> class of One-Time Password (OTP) methods. We'd like to > >> invite review and comment in the TLS WG. > >> > >> --jl > >> > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Wednesday, June 07, 2006 3:50 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D ACTION:draft-linn-otp-tls-00.txt > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> > >> Title : OTP Methods for TLS > >> Author(s) : J. Linn, M. Nystroem > >> Filename : draft-linn-otp-tls-00.txt > >> Pages : 21 > >> Date : 2006-6-7 > >> > >> This document describes means for applying One-Time Password (OTP) > >> methods to authenticate Transport Layer Security sessions,=20 > operating > >> in conjunction with Pre-Shared Key (PSK) ciphersuites=20 > defined for use > >> with TLS. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-linn-otp-tls-00.txt > >> > >> To remove yourself from the I-D Announcement list, send a=20 > 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=20 > logging in, > >> type "cd internet-drafts" and then > >> "get draft-linn-otp-tls-00.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-linn-otp-tls-00.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. > >> > > >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 21 04:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsxnb-0001kR-9d; Wed, 21 Jun 2006 04:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxnY-0001h5-IX for tls@ietf.org; Wed, 21 Jun 2006 04:10:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsxeU-00047Y-Jp for tls@ietf.org; Wed, 21 Jun 2006 04:01:32 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5L81TtC007999 for ; Wed, 21 Jun 2006 11:01:29 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:01:29 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:01:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 11:01:29 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda time Thread-Index: AcaVCOchvHsqnqNNRr+Z5k086cOVhw== From: To: X-OriginalArrivalTime: 21 Jun 2006 08:01:29.0043 (UTC) FILETIME=[E6C2A230:01C69508] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Agenda time 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: , Errors-To: tls-bounces@lists.ietf.org Hi, TLS WG is scheduled to meet in Montreal (current slot: Tuesday 1300-1500). If you'd like to present something, drop a note to Eric and me. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 21 20:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCdD-0002vi-9z; Wed, 21 Jun 2006 20:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCdC-0002vd-8g for tls@lists.ietf.org; Wed, 21 Jun 2006 20:01:10 -0400 Received: from sam.opera.com ([193.69.113.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCdA-0000m6-Nu for tls@lists.ietf.org; Wed, 21 Jun 2006 20:01:10 -0400 Received: from lessa-ii.cust.metrofi.net (niflocal.snvacaid.metrofi.net [64.156.212.30]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5M00tMA028873 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Jun 2006 00:01:04 GMT Date: Wed, 21 Jun 2006 17:01:07 -0700 From: "Yngve N. Pettersen" To: "Transport Layer Security working group" References: Organization: Opera Software ASA Content-Type: multipart/mixed; boundary=----------ECzDujFx5EmxTWLYTK1LK6 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.53 (Win32, build 7722) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [TLS] Fwd: I-D ACTION:draft-pettersen-tls-interop-experience-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: , Errors-To: tls-bounces@lists.ietf.org ------------ECzDujFx5EmxTWLYTK1LK6 Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 8bit ------- Forwarded message ------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-pettersen-tls-interop-experience-00.txt Date: Wed, 21 Jun 2006 12:50:01 -0700 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clientside interoperability experiences for the SSL and TLS protocols Author(s) : Y. Pettersen Filename : draft-pettersen-tls-interop-experience-00.txt Pages : 27 Date : 2006-6-21 This document presents a number of problems encountered when implementing TLS 1.0, TLS 1.0 and TLS Extensions for clients, and their consequences. The problems include servers that refuse to connect with clients supporting newer versions of the protocol, or does not handle such negotiation properly. Other problems encountered are incorrect use of values in the protocol messages. The consequences of these problems range from delayed introduction of new protocol versions and features, to fallback mechanisms that may disable protocol security features, to implementations that cannot interoperate with some other implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pettersen-tls-interop-experience-00.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-pettersen-tls-interop-experience-00.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-pettersen-tls-interop-experience-00.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. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** ------------ECzDujFx5EmxTWLYTK1LK6 Content-Disposition: attachment; filename=attachment185.tmp Content-Type: application/octet-stream; name=attachment185.tmp Content-Transfer-Encoding: Base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTIx MTI1NTIxLkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXBldHRlcnNlbi10bHMtaW50ZXJvcC1leHBlcmll bmNlLTAwLnR4dA0K ------------ECzDujFx5EmxTWLYTK1LK6 Content-Disposition: attachment; filename=attachment186.tmp Content-Type: application/octet-stream; name=attachment186.tmp Content-Transfer-Encoding: Base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu bm91bmNlDQo= ------------ECzDujFx5EmxTWLYTK1LK6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------------ECzDujFx5EmxTWLYTK1LK6-- From tls-bounces@lists.ietf.org Sat Jun 24 02:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1IG-00065G-GN; Sat, 24 Jun 2006 02:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1IF-0005vL-E5 for TLS@lists.ietf.org; Sat, 24 Jun 2006 02:06:55 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu1ID-0004OX-N2 for TLS@lists.ietf.org; Sat, 24 Jun 2006 02:06:54 -0400 Received: by nf-out-0910.google.com with SMTP id m19so351961nfc for ; Fri, 23 Jun 2006 23:06:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FIePGRZXh9zWUHg1F8Q5dpFrUFywydigoimjfgiLX1QrCPGMihhzRwtZjGbmrx6vF61486ulCR54iaH3gZSoljxyzs56KORiri7BWifyZujZMdW4HZqwLJmImx99MAvqoKfAvMwgC72vgYWgSQMY+eIWPU0+VrUkIkvyyo7QD8M= Received: by 10.49.54.13 with SMTP id g13mr3162545nfk; Fri, 23 Jun 2006 23:06:48 -0700 (PDT) Received: by 10.48.12.1 with HTTP; Fri, 23 Jun 2006 23:06:48 -0700 (PDT) Message-ID: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> Date: Fri, 23 Jun 2006 23:06:48 -0700 From: "Kyle Hamilton" To: TLS@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [TLS] Comments on TLS extension mechanism 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: , Errors-To: tls-bounces@lists.ietf.org I would like to request that a specific TLS extension number, say 65534, be used as a means of negotiating arbitrary TLS extensions for specific application and research purposes, with the express understanding that this mechanism SHOULD NOT be used unless no other option presents itself, AND the implementor is aware of any potential security issues that may be introduced. The format I propose would be akin to: struct { int extension_ID, OID arbitrary_extension, int extension_data_length(65535) opaque(arbitrary_extension_data) } TlsArbitraryExtensionType; Since section 5 of RFC4366 (and predecessors) states that new extensions shall ONLY be approved through RFCs approved by the IESG, this is the only logical place to propose such that I can find. If this is not the appropriate forum, please let me know. -Kyle Hamilton _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 24 10:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9At-0000X3-Os; Sat, 24 Jun 2006 10:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9As-0000Wy-Cp for tls@ietf.org; Sat, 24 Jun 2006 10:31:50 -0400 Received: from smtp-out3.blueyonder.co.uk ([195.188.213.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu9Ar-0001gc-0p for tls@ietf.org; Sat, 24 Jun 2006 10:31:50 -0400 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Fu9Aq-00048c-EV for tls@ietf.org; Sat, 24 Jun 2006 15:31:48 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1Fu9Ap-0003KG-Iu for tls@ietf.org; Sat, 24 Jun 2006 15:31:47 +0100 Message-ID: <449D4CCF.8070107@blueyonder.co.uk> Date: Sat, 24 Jun 2006 15:31:43 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Comments on TLS extension mechanism References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> In-Reply-To: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Kyle Hamilton wrote: > I would like to request that a specific TLS extension number, say > 65534, be used as a means of negotiating arbitrary TLS extensions for > specific application and research purposes, with the express > understanding that this mechanism SHOULD NOT be used unless no other > option presents itself, AND the implementor is aware of any potential > security issues that may be introduced. The format I propose would be > akin to: > > struct { > int extension_ID, > OID arbitrary_extension, > int extension_data_length(65535) > opaque(arbitrary_extension_data) > } TlsArbitraryExtensionType; > > Since section 5 of RFC4366 (and predecessors) states that new > extensions shall ONLY be approved through RFCs approved by the IESG, > this is the only logical place to propose such that I can find. Why would we want to approve an extension that essentially bypasses the current approval policy, which was agreed by concensus of the TLS WG, and that also increases the parsing complexity of such extensions for no good reason? There is no extension ID scarcity problem. The policy for approval of new extensions is exactly as intended, and the lack of an experimental ID range is quite deliberate: The list of extension types, as defined in Section 2.3, is maintained by the Internet Assigned Numbers Authority (IANA). Thus, an application needs to be made to the IANA in order to obtain a new extension type value. Since there are subtle (and not-so-subtle) interactions that may occur in this protocol between new features and existing features that may result in a significant reduction in overall security, new values SHALL be defined only through the IETF Consensus process specified in [IANA]. (This means that new assignments can be made only via RFCs approved by the IESG.) -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jun 24 17:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuFtC-0005h1-SE; Sat, 24 Jun 2006 17:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuFtC-0005gw-5l for tls@ietf.org; Sat, 24 Jun 2006 17:42:02 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuFtA-00085r-QE for tls@ietf.org; Sat, 24 Jun 2006 17:42:02 -0400 Received: by nf-out-0910.google.com with SMTP id d4so705419nfe for ; Sat, 24 Jun 2006 14:42:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pvA+BhvbBFrXtoPMierPoOQIL/tKrOKcOsCMsaz1BLaNr60t41aNLL0Vurr3UCxhAmJTi/jMvQ/bcW36GHPFgyR29bRJDAEBTQAW9Yx6gS5SH2EKl8xecptsCpsL+jnlldFAR20frVZ8hDRDo4DMNBeXAABjErOCF15c7IFnggA= Received: by 10.49.78.10 with SMTP id f10mr3639434nfl; Sat, 24 Jun 2006 14:42:00 -0700 (PDT) Received: by 10.48.12.1 with HTTP; Sat, 24 Jun 2006 14:41:59 -0700 (PDT) Message-ID: <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> Date: Sat, 24 Jun 2006 14:41:59 -0700 From: "Kyle Hamilton" To: david.nospam.hopwood@blueyonder.co.uk Subject: Re: [TLS] Comments on TLS extension mechanism In-Reply-To: <449D4CCF.8070107@blueyonder.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> <449D4CCF.8070107@blueyonder.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: tls-bounces@lists.ietf.org Because, as I understand it, within every protocol (including IP) there has been a specific item dedicated to research. There is certainly no current shortage of IDs... but there's also nothing in place to provide a mechanism when resource exhaustion occurs. There's also nothing in place to keep experimental IDs from trampling on each other. (In this particular case, I'd like to inform the other end of what security policy this computer must implement, and determine if there is a compatible mapping before continuing the connection. This determination is not something that any current protocol does, and I want to research the security issues with such an action as this before I make any kind of proposal about it.) If you're worried about "increasing the complexity of the current parser", put a length integer just after the extension ID so the parser knows how much to skip if it doesn't understand the extension. Which is, as I understand it, approximately how the extensions are supposed to work anyway. Cordially, -Kyle Hamilton On 6/24/06, David Hopwood wrote: > Kyle Hamilton wrote: > > I would like to request that a specific TLS extension number, say > > 65534, be used as a means of negotiating arbitrary TLS extensions for > > specific application and research purposes, with the express > > understanding that this mechanism SHOULD NOT be used unless no other > > option presents itself, AND the implementor is aware of any potential > > security issues that may be introduced. The format I propose would be > > akin to: > > > > struct { > > int extension_ID, > > OID arbitrary_extension, > > int extension_data_length(65535) > > opaque(arbitrary_extension_data) > > } TlsArbitraryExtensionType; > > > > Since section 5 of RFC4366 (and predecessors) states that new > > extensions shall ONLY be approved through RFCs approved by the IESG, > > this is the only logical place to propose such that I can find. > > Why would we want to approve an extension that essentially bypasses > the current approval policy, which was agreed by concensus of the > TLS WG, and that also increases the parsing complexity of such extensions > for no good reason? > > There is no extension ID scarcity problem. The policy for approval of > new extensions is exactly as intended, and the lack of an experimental > ID range is quite deliberate: > > The list of extension types, as defined in Section 2.3, is maintained > by the Internet Assigned Numbers Authority (IANA). Thus, an > application needs to be made to the IANA in order to obtain a new > extension type value. Since there are subtle (and not-so-subtle) > interactions that may occur in this protocol between new features and > existing features that may result in a significant reduction in > overall security, new values SHALL be defined only through the IETF > Consensus process specified in [IANA]. > > (This means that new assignments can be made only via RFCs approved > by the IESG.) > > -- > David Hopwood > > > > _______________________________________________ > 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@lists.ietf.org Sat Jun 24 19:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuI0G-0002r2-Mb; Sat, 24 Jun 2006 19:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuI0E-0002qx-Lx for tls@ietf.org; Sat, 24 Jun 2006 19:57:26 -0400 Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuI0D-0001mi-9u for tls@ietf.org; Sat, 24 Jun 2006 19:57:26 -0400 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FuI0C-000099-DD for tls@ietf.org; Sun, 25 Jun 2006 00:57:24 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out6.blueyonder.co.uk with esmtp (Exim 4.52) id 1FuI0B-0006zt-UO for tls@ietf.org; Sun, 25 Jun 2006 00:57:24 +0100 Message-ID: <449DD15E.1090100@blueyonder.co.uk> Date: Sun, 25 Jun 2006 00:57:18 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Comments on TLS extension mechanism References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> <449D4CCF.8070107@blueyonder.co.uk> <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> In-Reply-To: <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Kyle Hamilton wrote: > Because, as I understand it, within every protocol (including IP) > there has been a specific item dedicated to research. There is > certainly no current shortage of IDs... but there's also nothing in > place to provide a mechanism when resource exhaustion occurs. When and if 60000 IDs have been exhausted, I promise to revisit this question. (Note that this would require 13 times more RFCs describing TLS extension mechanisms, assuming one RFC per extension, than the current total number of published RFCs.) > There's also nothing in place to keep experimental IDs from trampling > on each other. Assigning IDs for experiments has pros and cons. In general, for numbers where there is no range allocated to experiments, there is an implied obligation on the experimenter to make sure that an implementation that supports the experiment is not used on a public network in such a way that it could cause disruption to other network users. In any case, the time to raise this issue would have been when RFC 4366 was being discussed. The next opportunity to change the policy is when the extension mechanism is incorporated into TLS 1.2. > (In this particular case, I'd like to inform the other end of > what security policy this computer must implement, and determine if > there is a compatible mapping before continuing the connection. This > determination is not something that any current protocol does, and I > want to research the security issues with such an action as this > before I make any kind of proposal about it.) > > If you're worried about "increasing the complexity of the current > parser", put a length integer just after the extension ID so the > parser knows how much to skip if it doesn't understand the extension. The issue is unnecessary complexity for implementations that do understand the extension, not for implementations that do not understand it. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 25 12:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXsZ-0000Fa-QU; Sun, 25 Jun 2006 12:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXsY-0000FU-84 for tls@ietf.org; Sun, 25 Jun 2006 12:54:34 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXsU-00036f-Tx for tls@ietf.org; Sun, 25 Jun 2006 12:54:34 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E4704222425 for ; Sun, 25 Jun 2006 10:02:41 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sun, 25 Jun 2006 09:54:30 -0700 From: Eric Rescorla Message-Id: <20060625170241.E4704222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [TLS] Updated TLS 1.2 I-D 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: , Errors-To: tls-bounces@lists.ietf.org I've submitted an update TLS 1.2 I-D an in the meantime you can find it at: http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt The big thing I know is misisng is replaceable PRFs, which I wanted to discuss on the mailing list before I put in. As people will recall, there was a consensus on replaceable PRFs/KDFs in Dallas but we didn't discuss exactly how to do them. My proposal is as follows: - All PRFs must have the same "API" as the existing TLS PRFs. - New cipher suites MAY have as part of their specification a new PRF. - There is no way to separately negotiate a new PRF for an existing cipher suite. The major alternative is some kind of extension, which makes me uncomfortable. Thoughts? Issues? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 25 13:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuYHh-0004p2-TN; Sun, 25 Jun 2006 13:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuYHg-0004ox-CN for tls@ietf.org; Sun, 25 Jun 2006 13:20:32 -0400 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuYHf-0003hT-02 for tls@ietf.org; Sun, 25 Jun 2006 13:20:32 -0400 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k5PHKU003988 for ; Sun, 25 Jun 2006 19:20:30 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sun, 25 Jun 2006 19:20:30 +0200 (MET DST) Message-ID: <449EC572.4050007@edelweb.fr> Date: Sun, 25 Jun 2006 19:18:42 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> <449D4CCF.8070107@blueyonder.co.uk> <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> In-Reply-To: <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: tls@ietf.org Subject: [TLS] SRP TLS extension status 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="===============0348901132==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0348901132== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040407020003030305090309" This is a cryptographically signed message in MIME format. --------------ms040407020003030305090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit - What is the current status of the identifier that is used for the SRP for TLS extension? Is the number 'reserved', for example? - What is the status of decision making concern the treatment of that SRP-TLS by this group? --------------ms040407020003030305090309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjI1MTcxODQyWjAjBgkqhkiG9w0B CQQxFgQUB5N05kjZa6DX01bDaJIyLhauscIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAPkd5caMs2IzfIS+Y NWCoxDU7kcd2XMY29+bfGi+AFV5ITgu0XraLGawUTHGh7g9B+B0l6PoQsY7vX9LbFF93Yzh6 uzL1QO0aLUFtjiv04Sf2P1FiJoWrOzLd7nuukn+3u7ON1bNd/a0/WNWCm2NswGtx/q3rN7t7 tF6acojGslYAAAAAAAA= --------------ms040407020003030305090309-- --===============0348901132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0348901132==-- From tls-bounces@lists.ietf.org Sun Jun 25 14:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZZo-0000m6-Ak; Sun, 25 Jun 2006 14:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZZn-0000m1-7a for tls@lists.ietf.org; Sun, 25 Jun 2006 14:43:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuZZl-0005pA-Uu for tls@lists.ietf.org; Sun, 25 Jun 2006 14:43:19 -0400 Received: by ug-out-1314.google.com with SMTP id m3so644059uge for ; Sun, 25 Jun 2006 11:43:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=suGd7wQfSdwhWkPjCG+zreZq/e4plnRoWGvuhBjhbSTG0SA4PES42bfJY1MMA2u1A7X86JM0+1E1WAUnTFTx1K850c+9I49MLnDGFzqwOKH6rPoSBBdxXFRJweFK0D0a4Sv+N0DdB0vdc8ziXYSix3q2TNfGlE7z+M8KNfqTpSs= Received: by 10.66.240.12 with SMTP id n12mr4227797ugh; Sun, 25 Jun 2006 11:43:16 -0700 (PDT) Received: from ?172.16.1.227? ( [81.175.93.238]) by mx.gmail.com with ESMTP id k2sm4199476ugf.2006.06.25.11.43.16; Sun, 25 Jun 2006 11:43:16 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] SRP TLS extension status Date: Sun, 25 Jun 2006 20:43:13 +0200 User-Agent: KMail/1.9.1 References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com> <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com> <449EC572.4050007@edelweb.fr> In-Reply-To: <449EC572.4050007@edelweb.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606252043.14122.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: tls-bounces@lists.ietf.org On Sun 25 Jun 2006 19:18, Peter Sylvester wrote: > - What is the current status of the identifier that is used for the > SRP for TLS > extension? Is the number 'reserved', for example? Some weeks ago I tried to contact IANA to reserve it, but they said it was not possible. Now I see that they assigned this number to user mapping extension. > - What is the status of decision making concern the treatment > of that SRP-TLS by this group? A final version of the draft will be issued during the next few days. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 01:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujXI-0000Mg-PB; Mon, 26 Jun 2006 01:21:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujXG-0000Ma-Uv for tls@ietf.org; Mon, 26 Jun 2006 01:21:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FujXE-0006xQ-JP for tls@ietf.org; Mon, 26 Jun 2006 01:21:22 -0400 Received: by nf-out-0910.google.com with SMTP id d4so815066nfe for ; Sun, 25 Jun 2006 22:21:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bXW1u62yowKrFm7bBiGHkIziWQf8fqnSvK7uZ/Wiwa3ptqfd9Gz47vbbGmoQ6D7Qh6dV6a9T7JxlQdq9Ew2r7g9cDxk+qeGE73NXFN0NR/Nd1dVbB9nbjjb3eMEH9wDVKt53JzxjzqW90+cUBMWiAesbKtHGuX9xEt2aq+54LN4= Received: by 10.48.242.3 with SMTP id p3mr4533791nfh; Sun, 25 Jun 2006 22:21:19 -0700 (PDT) Received: by 10.48.12.1 with HTTP; Sun, 25 Jun 2006 22:21:19 -0700 (PDT) Message-ID: <6b9359640606252221g6a26630ew65f34de3beb528d7@mail.gmail.com> Date: Sun, 25 Jun 2006 22:21:19 -0700 From: "Kyle Hamilton" To: "Eric Rescorla" Subject: Re: [TLS] Updated TLS 1.2 I-D In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060625170241.E4704222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: tls-bounces@lists.ietf.org I'm curious, why does having it as an extension make you uncomfortable? The way I see it, the PRF will need to be the same on both sides in order for the handshake to complete, even if it's negotiated via extension. If it's not, then the server (and/or the client) will get what should be the handshake_complete packet, and be unable to decrypt it properly. When they do, they'll run the hash over it, see that it doesn't match, and throw a decrypt_error or decode_error fatal alert. Though this would be a good way for Mallory to mount a DOS attack against the server and/or client (insert an extension to select the PRF), that possibility is already incumbent in the handshake protocol regardless (and has been there since at least TLS 1.0, allowing extra data (which later became 'extensions') after the end of the client_hello). An extension of this type (and let's face it, 'extensions' were introduced so that the protocol could be extended beyond its original capability), even though it is recommended not to be put in place, appears to be cryptographically sound. I've got a couple of comments and questions on the draft (and protocol) itself; I'll put them in a separate email. -Kyle H On 6/25/06, Eric Rescorla wrote: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? > -Ekr > > > > > _______________________________________________ > 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@lists.ietf.org Mon Jun 26 05:56:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Funol-0001MT-KZ; Mon, 26 Jun 2006 05:55:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Funok-0001MO-J2 for tls@ietf.org; Mon, 26 Jun 2006 05:55:42 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Funoj-0007Ug-7A for tls@ietf.org; Mon, 26 Jun 2006 05:55:42 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FunoQ3RXb-0002Rr; Mon, 26 Jun 2006 11:55:35 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 39AB019530; Mon, 26 Jun 2006 11:55:22 +0200 (CEST) Date: Mon, 26 Jun 2006 11:55:22 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Updated TLS 1.2 I-D Message-ID: <20060626095522.GA28012@iota.site> References: <20060625170241.E4704222425@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: tls-bounces@lists.ietf.org On Sun, Jun 25, 2006 at 09:54:30AM -0700, Eric Rescorla wrote: > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? Extensions shouldn't be worse than additional ciphersuites. The problem about additional ciphersuites is that we'd have to duplicate the number of allocated ciphersuites numbers to provide new PRFs for otherwise well-known ciphersuites, and issue a number of boring RFCs to get there. And that's assuming that there's just a single preffered new PRF, since otherwise we might end up triplicating, quadruplicating, ..., the number of allocated ciphersuites (and we only have a 16-bit namespace). My preference would be for a new PRF that automatically is plugged into all existing ciphersuites for the new protocol version. I.e., protocol version negotiation and not ciphersuite negotiation determines the PRF. An extensions could be optional for those who want to negotiate some PRF other than this default. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 08:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqXS-0001N0-AL; Mon, 26 Jun 2006 08:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqXR-0001Ml-Bt for tls@ietf.org; Mon, 26 Jun 2006 08:50:01 -0400 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqXP-0004sm-UB for tls@ietf.org; Mon, 26 Jun 2006 08:50:01 -0400 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k5QCnu001219; Mon, 26 Jun 2006 14:49:56 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Mon, 26 Jun 2006 14:49:56 +0200 (MET DST) Message-ID: <449FD789.8090604@edelweb.fr> Date: Mon, 26 Jun 2006 14:48:09 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [TLS] Updated TLS 1.2 I-D References: <20060625170241.E4704222425@laser.networkresonance.com> In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============1371511378==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1371511378== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050206080804020507030902" This is a cryptographically signed message in MIME format. --------------ms050206080804020507030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Eric Rescorla wrote: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > > The text lists enum { server_name(0), max_fragment_length(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), cert_hash_types(6), (65535) } ExtensionType; According to IANA we have: 6 user_mapping [RFC-santesson-tls-ume-07.txt] and the tls-srp draft has been using 6 since years, too. I also note that IANA has assigned temporarily three alert numbers referencing tls-srp. Well, all that didn' happen on June 6, 2006, but close to. :-) Who will get 7? psk? Have fun. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms050206080804020507030902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjI2MTI0ODA5WjAjBgkqhkiG9w0B CQQxFgQUvc1tHO0osBY+N/Qmwi1ag6BJQs4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAwTuhk5nthflDtqc7 SeyazfddsiujyirRqOLddh9yh9qKvXOnkShW1qeXoXQ9dDZJxUDaoArIng5r6U/5EgexJ1Nl 0SEKcQcXDQ/GAQufl2oluZmdb557eHO91tQlICC+xd1en1YV+eftauPfZnOALJW1RU0K5Xdu Cndhtkh4dYQAAAAAAAA= --------------ms050206080804020507030902-- --===============1371511378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1371511378==-- From tls-bounces@lists.ietf.org Mon Jun 26 09:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurB9-0007Ev-OQ; Mon, 26 Jun 2006 09:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurB9-0007Cg-7I for tls@ietf.org; Mon, 26 Jun 2006 09:31:03 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurB7-0008BL-OE for tls@ietf.org; Mon, 26 Jun 2006 09:31:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QDUxpS022210; Mon, 26 Jun 2006 16:30:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:30:58 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:30:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Updated TLS 1.2 I-D Date: Mon, 26 Jun 2006 16:30:57 +0300 Message-ID: In-Reply-To: <449FD789.8090604@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated TLS 1.2 I-D Thread-Index: AcaZH5tHy3bTiNeEQvSnWm9GRV2CowAAlbIQ From: To: X-OriginalArrivalTime: 26 Jun 2006 13:30:58.0264 (UTC) FILETIME=[C2331D80:01C69924] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: tls-bounces@lists.ietf.org ExtensionType value 6 has also been used in draft-ietf-tls-pathsec (presumably dead, as its from 2001), draft-shacham-tls-fast-track (also dead, from 2002), and some early versions of draft-ietf-tls-ecc, making it the most popular TLS extension number ever :-) But seriously speaking, the numbers are assigned by IANA *after* the=20 document has been approved by IESG; draft authors should just use=20 "TBD-BY-IANA" (and most current drafts, including tls-srp, do this). (BTW, draft-ietf-tls-psk has been RFC 4279 for some while; it=20 did not need an ExtensionType number.) Best regards, Pasi > -----Original Message----- > From: ext Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr]=20 > Sent: 26 June, 2006 15:48 > To: Eric Rescorla > Cc: tls@ietf.org > Subject: Re: [TLS] Updated TLS 1.2 I-D >=20 >=20 > Eric Rescorla wrote: > > I've submitted an update TLS 1.2 I-D an in the meantime > > you can find it at: > > > > > > =20 > The text lists >=20 > enum { > server_name(0), max_fragment_length(1), > client_certificate_url(2), trusted_ca_keys(3), > truncated_hmac(4), status_request(5), > cert_hash_types(6), (65535) > } ExtensionType; >=20 >=20 > According to IANA we have: >=20 > 6 user_mapping [RFC-santesson-tls-ume-07.txt] >=20 > and the tls-srp draft has been using 6 since years, too. >=20 > I also note that IANA has assigned temporarily three alert=20 > numbers referencing tls-srp.=20 >=20 > Well, all that didn' happen on June 6, 2006, but close to. :-) >=20 > Who will get 7? psk? > =20 > Have fun. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 09:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMh-0008B0-Tk; Mon, 26 Jun 2006 09:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMg-00086P-MA for tls@ietf.org; Mon, 26 Jun 2006 09:42:58 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurMe-0000sT-Az for tls@ietf.org; Mon, 26 Jun 2006 09:42:58 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 82D1C1E8C1F; Mon, 26 Jun 2006 06:42:55 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] Updated TLS 1.2 I-D References: <20060625170241.E4704222425@laser.networkresonance.com> <20060626095522.GA28012@iota.site> From: Eric Rescorla Date: Mon, 26 Jun 2006 06:42:55 -0700 In-Reply-To: <20060626095522.GA28012@iota.site> (Bodo Moeller's message of "Mon, 26 Jun 2006 11:55:22 +0200") Message-ID: <86mzc0av8g.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller writes: > On Sun, Jun 25, 2006 at 09:54:30AM -0700, Eric Rescorla wrote: > >> The big thing I know is misisng is replaceable PRFs, which >> I wanted to discuss on the mailing list before I put in. >> As people will recall, there was a consensus on replaceable >> PRFs/KDFs in Dallas but we didn't discuss exactly how to do >> them. >> >> My proposal is as follows: >> >> - All PRFs must have the same "API" as the existing TLS >> PRFs. >> - New cipher suites MAY have as part of their specification >> a new PRF. >> - There is no way to separately negotiate a new PRF for >> an existing cipher suite. >> >> The major alternative is some kind of extension, which makes >> me uncomfortable. >> >> Thoughts? Issues? > > Extensions shouldn't be worse than additional ciphersuites. The > problem about additional ciphersuites is that we'd have to duplicate > the number of allocated ciphersuites numbers to provide new PRFs for > otherwise well-known ciphersuites, and issue a number of boring RFCs > to get there. And that's assuming that there's just a single > preffered new PRF, since otherwise we might end up triplicating, > quadruplicating, ..., the number of allocated ciphersuites (and we > only have a 16-bit namespace). > > My preference would be for a new PRF that automatically is plugged > into all existing ciphersuites for the new protocol version. Yes, that's my plan. > I.e., > protocol version negotiation and not ciphersuite negotiation > determines the PRF. An extensions could be optional for those > who want to negotiate some PRF other than this default. But the flip side of using extensions that way is that we move more and more of the protocol into extensions. I wonder if it's becoming time to consider breaking up the ciphersuite into orthogonal parameters. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 09:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurXZ-0002hf-3M; Mon, 26 Jun 2006 09:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurXX-0002hZ-A0 for tls@ietf.org; Mon, 26 Jun 2006 09:54:11 -0400 Received: from revol1.enst.fr ([137.194.2.7] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurXW-0001Dz-23 for tls@ietf.org; Mon, 26 Jun 2006 09:54:11 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 39B3F164C42; Mon, 26 Jun 2006 15:54:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from enst.fr (mechmech.enst.fr [137.194.164.56]) by smtp2.enst.fr (Postfix) with ESMTP id 1E28D166280; Mon, 26 Jun 2006 15:53:54 +0200 (CEST) Message-ID: <449FE6ED.5030909@enst.fr> Date: Mon, 26 Jun 2006 15:53:49 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Peter Sylvester Subject: Re: [TLS] Updated TLS 1.2 I-D References: <20060625170241.E4704222425@laser.networkresonance.com> <449FD789.8090604@edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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: , Errors-To: tls-bounces@lists.ietf.org > Who will get 7? psk? psk does not use TLS extensions. Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 10:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Furx6-00069C-8x; Mon, 26 Jun 2006 10:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Furx5-000697-2K for tls@ietf.org; Mon, 26 Jun 2006 10:20:35 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Furx3-0003t7-JH for tls@ietf.org; Mon, 26 Jun 2006 10:20:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QEKUlR014806; Mon, 26 Jun 2006 17:20:32 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 17:20:28 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 17:20:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Updated TLS 1.2 I-D Date: Mon, 26 Jun 2006 17:20:27 +0300 Message-ID: In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated TLS 1.2 I-D Thread-Index: AcaYeCTojzNUKMoCQfaSyaM4ID4/dgAscReg From: To: , X-OriginalArrivalTime: 26 Jun 2006 14:20:27.0083 (UTC) FILETIME=[ABC0F1B0:01C6992B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: =20 > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. >=20 > My proposal is as follows: >=20 > - All PRFs must have the same "API" as the existing TLS=20 > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. I like this approach; it's simple, and I'm not convinced that anything more complicated is needed. As was already pointed out some time ago, even the current PRF looks quite secure: if someone really needs a special PRF due to e.g. regulatory requirements, they'll probably=20 need a new ciphersuite anyway. However, I would take the approach even further towards simplicity: use the current TLS PRF for all existing ciphersuites (instead of tying it to the ciphersuite's MAC algorithm). Or in other words: consider PRF as a property of the ciphersuite's key exchange=20 algorithm (instead of the TLS protocol version or a property that can be negotiated independent of key exchange algorithm). (The document would then need a couple of new ciphersuites for=20 the new PRF, but probably not very many combinations; after all, if someone's worried that the current PRF is insecure, they're not likely to use RC4 or IDEA. Maybe these new ciphersuites could be the combined-mode ones.). Best regards,=20 Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 11:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuswC-0003Pc-4O; Mon, 26 Jun 2006 11:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuswA-0003PX-Pr for tls@ietf.org; Mon, 26 Jun 2006 11:23:42 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fusw9-0001El-Bu for tls@ietf.org; Mon, 26 Jun 2006 11:23:42 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QFNefV025290; Mon, 26 Jun 2006 18:23:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:22:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:22:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Mon, 26 Jun 2006 18:22:38 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLA= From: To: , X-OriginalArrivalTime: 26 Jun 2006 15:22:34.0059 (UTC) FILETIME=[593459B0:01C69934] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mnystrom@rsasecurity.com 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: , Errors-To: tls-bounces@lists.ietf.org Since the document quite significantly changes how the PSK ciphersuites work (identity field is re-used to carry a number of other attributes; new alert messages are added; key-exchange related information is carried in new TLS extensions; etc.), I think it would be better to treat OTP as a new TLS key exchange algorithm (and define new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently written, this document certainly is not a "profile" of RFC 4279 in any usual sense of the word... Couple of additional comments: - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents" - Text about "hardening" should give concrete advice on how secure OTP-TLS actuallly is, given some realistic parameter values (just talking about "economically unattractive" is very vague). Best regards, Pasi=20 > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20 > Sent: 14 June, 2006 14:17 > To: tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > This recent I-D constitutes a profile layered on TLS-PSK,=20 > intended to authenticate TLS connections with the general=20 > class of One-Time Password (OTP) methods. We'd like to=20 > invite review and comment in the TLS WG. =20 >=20 > --jl _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 11:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fut6Q-0001ER-Oa; Mon, 26 Jun 2006 11:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fut6P-0001EB-3h for tls@ietf.org; Mon, 26 Jun 2006 11:34:17 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fut6N-0001m2-Mi for tls@ietf.org; Mon, 26 Jun 2006 11:34:17 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1Fut6K1fAY-0008W6; Mon, 26 Jun 2006 17:34:12 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 90CFC19530; Mon, 26 Jun 2006 17:34:11 +0200 (CEST) Date: Mon, 26 Jun 2006 17:34:11 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Updated TLS 1.2 I-D Message-ID: <20060626153411.GA2821@iota.site> References: <20060625170241.E4704222425@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: tls-bounces@lists.ietf.org On Mon, Jun 26, 2006 at 05:20:27PM +0300, Pasi.Eronen@nokia.com wrote: >> My proposal is as follows: >> >> - All PRFs must have the same "API" as the existing TLS >> PRFs. >> - New cipher suites MAY have as part of their specification >> a new PRF. >> - There is no way to separately negotiate a new PRF for >> an existing cipher suite. > I like this approach; it's simple, and I'm not convinced that anything > more complicated is needed. As was already pointed out some time ago, > even the current PRF looks quite secure: if someone really needs a > special PRF due to e.g. regulatory requirements, they'll probably > need a new ciphersuite anyway. > > However, I would take the approach even further towards simplicity: > use the current TLS PRF for all existing ciphersuites (instead of > tying it to the ciphersuite's MAC algorithm). Or in other words: > consider PRF as a property of the ciphersuite's key exchange > algorithm (instead of the TLS protocol version or a property > that can be negotiated independent of key exchange algorithm). If you take into account SSL 3.0, then the PRF already *is* a property of the TLS protocol version, though. And the current TLS PRF, with its input-splitting dual-hash construction, is somewhat bizarre, so a reasonable simple new PRF, based on a wider hash, wouldn't be bad -- providing the advantage that those who want to avoid the current TLS PRF in their favorite ciphersuites won't have to define additional ciphersuites just to get another PRF, as long as they are reasonably happy with the new default if we decide on one. > (The document would then need a couple of new ciphersuites for > the new PRF, but probably not very many combinations; after all, > if someone's worried that the current PRF is insecure, they're > not likely to use RC4 or IDEA. Maybe these new ciphersuites > could be the combined-mode ones.). This wouldn't be too many new ciphersuites if you consider just those that are in the main TLS specification. But then there are other ciphersuites in other RFCs, so we have to expect to see updates of these for the new PRF too if the PRF is not tied to the protocol version. Unless a single RFC does this for the ciphersuites from different existing RFCs (which do not even share a common status), this wouldn't really provide simplicity -- we'd have to expect a multitude of RFCs defining new ciphersuites, possibly most of them using the same PRF, possibly with some hand-tailored PRFs that are slightly optimized for the specific ciphersuites. Even if a single RFC does this for ciphersuites originally coming from different RFCs, the complete ciphersuite table would grow in length and entropy. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 12:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuu79-0007Hy-F8; Mon, 26 Jun 2006 12:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuu78-0007Hl-Ig for tls@ietf.org; Mon, 26 Jun 2006 12:39:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbd-00049O-N2 for tls@ietf.org; Mon, 26 Jun 2006 12:06:33 -0400 Received: from edelweb.fr ([212.234.46.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutTF-0000Vb-2e for tls@ietf.org; Mon, 26 Jun 2006 11:57:58 -0400 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k5QFvh005334; Mon, 26 Jun 2006 17:57:44 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Mon, 26 Jun 2006 17:57:44 +0200 (MET DST) Message-ID: <44A0038C.80507@edelweb.fr> Date: Mon, 26 Jun 2006 17:55:56 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Updated TLS 1.2 I-D References: In-Reply-To: X-Spam-Score: -2.3 (--) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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="===============0247098128==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0247098128== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030905060905040409010300" This is a cryptographically signed message in MIME format. --------------ms030905060905040409010300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Understood. Thanks. Pasi.Eronen@nokia.com wrote: > ExtensionType value 6 has also been used in draft-ietf-tls-pathsec > (presumably dead, as its from 2001), draft-shacham-tls-fast-track > (also dead, from 2002), and some early versions of draft-ietf-tls-ecc, > making it the most popular TLS extension number ever :-) > > But seriously speaking, the numbers are assigned by IANA *after* the > document has been approved by IESG; draft authors should just use > "TBD-BY-IANA" (and most current drafts, including tls-srp, do this). > > (BTW, draft-ietf-tls-psk has been RFC 4279 for some while; it > did not need an ExtensionType number.) > > Best regards, > Pasi -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms030905060905040409010300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjI2MTU1NTU2WjAjBgkqhkiG9w0B CQQxFgQUzia+BFYKmelpds0YHEY7oHxlmZAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAHiAFbE98YIZTbvmY WjdiMMMEKwWPdvppXwXsEXWbCOYKYtr+jWN4fFtNv2JKQ2aoWJsytrROPaupjwy0XV8wqBdy cFb7eT2I/9ddx87BDui7OS/1SEM+E/pziLAViseUg8hoOP0Geq9IV+53hkf+A0IH79gY9A0z HIt8H15snFEAAAAAAAA= --------------ms030905060905040409010300-- --===============0247098128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0247098128==-- From tls-bounces@lists.ietf.org Mon Jun 26 12:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuLs-0003ma-SX; Mon, 26 Jun 2006 12:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuLq-0003mT-UO for tls@ietf.org; Mon, 26 Jun 2006 12:54:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbd-00049O-DF for tls@ietf.org; Mon, 26 Jun 2006 12:06:33 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutTj-0000WL-Te for tls@ietf.org; Mon, 26 Jun 2006 11:58:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QFwBqg002245; Mon, 26 Jun 2006 18:58:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:58:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:58:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Updated TLS 1.2 I-D Date: Mon, 26 Jun 2006 18:58:04 +0300 Message-ID: In-Reply-To: <20060626153411.GA2821@iota.site> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated TLS 1.2 I-D Thread-Index: AcaZNvBGH8AVxVsoRTqQxaAS3a+HMQAARkMg From: To: X-OriginalArrivalTime: 26 Jun 2006 15:58:10.0868 (UTC) FILETIME=[52D78740:01C69939] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > If you take into account SSL 3.0, then the PRF already *is* a > property of the TLS protocol version, though. And the current TLS > PRF, with its input-splitting dual-hash construction, is somewhat > bizarre, so a reasonable simple new PRF, based on a wider hash, > wouldn't be bad -- providing the advantage that those who want to > avoid the current TLS PRF in their favorite ciphersuites won't have > to define additional ciphersuites just to get another PRF, as long > as they are reasonably happy with the new default if we decide on > one. Hmm... this is true. And we do have a precedent for TLS version dependent properties in ciphersuites: when we added an explicit IV=20 for CBC mode ciphersuites in TLS 1.1, we didn't give new numbers (e.g. "TLS_RSA_WITH_AES_128_CBC_EXPLICITIV_SHA"). So perhaps Eric's proposal (PRF is a property of both the ciphersuite and protocol version, and for version 1.2, it defaults to the new to-be-decided PRF unless a ciphersuite spec explicitly says otherwise) would be simpler after all.. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 26 13:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuueI-0002hn-2F; Mon, 26 Jun 2006 13:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuueG-0002he-FC; Mon, 26 Jun 2006 13:13:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbk-00049O-PY; Mon, 26 Jun 2006 12:06:40 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutML-0000KQ-2x; Mon, 26 Jun 2006 11:50:46 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5QFoiRx018412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 15:50:44 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FutMK-0003Ff-Jw; Mon, 26 Jun 2006 11:50:44 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 26 Jun 2006 11:50:44 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@ietf.org Subject: [TLS] Last Call: 'Using OpenPGP keys for TLS authentication' to Experimental RFC (draft-ietf-tls-openpgp-keys) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'Using OpenPGP keys for TLS authentication ' as an Experimental RFC 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 2006-07-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-10.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 01:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv5fs-0007Qq-S2; Tue, 27 Jun 2006 00:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv5fr-0007Qh-0I for tls@lists.ietf.org; Tue, 27 Jun 2006 00:59:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv5fp-0001gw-LS for tls@lists.ietf.org; Tue, 27 Jun 2006 00:59:42 -0400 Received: by ug-out-1314.google.com with SMTP id m3so1334242uge for ; Mon, 26 Jun 2006 21:59:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=L46Qg5wws1sBuC9vsuch7ab6qak9qQaVDOslQJEmURmULZp/4nRtGhaWLcnAEHutqKaHvVNU0AY6oXcbbFSU4GxkdeUvjKpYF1nKd1btn7nLb4M6pJn8RYgYCnqsuLFTxN4lwYr9w+LkUe1TaTiGVbvRgDq2iPU6lQAHp1/A2bY= Received: by 10.67.24.13 with SMTP id b13mr5673851ugj; Mon, 26 Jun 2006 21:59:40 -0700 (PDT) Received: from ?172.16.1.227? ( [81.175.93.238]) by mx.gmail.com with ESMTP id k2sm5621626ugf.2006.06.26.21.59.40; Mon, 26 Jun 2006 21:59:40 -0700 (PDT) From: Nikos Mavrogiannopoulos To: Stephen Kent Date: Tue, 27 Jun 2006 06:59:35 +0200 User-Agent: KMail/1.9.1 References: <20060626203923.59F81222426@laser.networkresonance.com> In-Reply-To: <20060626203923.59F81222426@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606270659.37003.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@lists.ietf.org Subject: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon 26 Jun 2006 22:31, Eric Rescorla wrote: Hello, Thank you for the comments. They are addressed below. > >Date: Mon, 26 Jun 2006 16:03:48 -0400 > >To: iesg@ietf.org > >From: Stephen Kent > >Cc: Stephen Kent > >Subject: problems with =A0draft-ietf-tls-openpgp-keys-10.txt > > > > > >This I-D contains an error in its characterization of X.509 certs, > >as per RFC 3280, the IETF profile for these certs developed by the > > PKIX WG. > > > >The text in the Introduction says: > > > > =A0 =A0Currently the PKIX > > =A0 =A0protocols are limited to a hierarchical key management and as a > > =A0 =A0result, applications which follow different - non hierarchical - > > =A0 =A0trust models, could not be benefited by TLS." > > > >This is wrong. Neither X.509 nor PKIX restrict PKIs to be > > hierarchic. How would you support this?=20 My understanding from reading the overview rfc3280: "Following is a simplified view of the architectural model assumed by the PKIX specifications. The components in this model are: end entity: user of PKI certificates and/or end user system that is the subject of a certificate; CA: certification authority; ..." and by the fact that only one issuer per certificate is allowed, makes=20 clear to me there is a hierarchy of certification. Is there an example=20 of a non-hierarchic PKIX deployment? > >The Security Considerations section says: > > > > =A0 =A0Security considerations about the use of the web of trust or the > > =A0 =A0verification procedure are outside the scope of this document > > and they are considered an issue to be handled by local policy. > > > >The use of server certs with TLS is specifically designed to allow a > >client (e.g., browser) to verify that the server identity expressed > >in a URL is consistent with the subject identity expressed in the > >cert, as a form of automated authentication. This authentication > >technique is not perfect, but it is reasonably well understood by > >the community. =A0RFC 2818 describes the checking to be performed for > >server (and client) authentication based on X.509 syntax and this > >document should do the same. RFC2818 is a document that proposes a way on how to use HTTP over TLS.=20 This is not the purpose of this document. In more detail, you could see this is as an update of the TLS=20 specification which handles the technical issues of establishing a=20 secure connection. It doesn't mention anything about how to verify=20 certificates, because this is at the application level scope. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 09:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDOE-0006eF-Ey; Tue, 27 Jun 2006 09:14:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDOD-0006e9-1c for tls@ietf.org; Tue, 27 Jun 2006 09:14:01 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDOB-0006XQ-PI for tls@ietf.org; Tue, 27 Jun 2006 09:14:01 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Tue, 27 Jun 2006 09:12:59 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPT17085; Tue, 27 Jun 2006 09:16:38 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k5RDDvDU007536; Tue, 27 Jun 2006 09:13:57 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Tue, 27 Jun 2006 09:13:57 -0400 Message-ID: In-Reply-To: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foA== From: "Linn, John" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= 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: , Errors-To: tls-bounces@lists.ietf.org Pasi, Thanks for the review and comments, which we'll consider as input to a = subsequent draft revision; in particular, we can include more = quantitative discussion on OTP hardening.=20 Rather than defining new ciphersuites that would parallel those defined = in RFC-4279, we'd thought that it was feasible and appropriate to define = how inputs to RFC-4279 could be constructed to support OTP scenarios, = thereby achieving a modular approach that could layer on TLS-PSK rather = than duplicating it. As RFC-4279, Sec. 5, begins, "It is expected that = different types of identities are useful for different applications = running over TLS. This document does not therefore mandate the use of = any particular type of identity...". Against this backdrop, and noting = that RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates use in = conjunction with application profiles, we set out to profile the use of = the identity field so as to represent OTP-related attributes along with = the identity itself. As noted, the draft also proposes error alerts (to = be used only when use of OTP-TLS is indicated) and (optional) use of TLS = extensions, so extends more than just TLS-PSK; this can be clarified. = With regard to the proposed structure for OTP-TLS PSK_Identity, however, = we'd considered this as an example of a TLS-PSK application profile = which RFC-4279 did not appear to preclude. =20 --jl -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Monday, June 26, 2006 11:23 AM To: Linn, John; tls@ietf.org Cc: Nystr=F6m, Magnus Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D = ACTION:draft-linn-otp-tls-00.txt] Since the document quite significantly changes how the PSK ciphersuites work (identity field is re-used to carry a number of other attributes; new alert messages are added; key-exchange related information is carried in new TLS extensions; etc.), I think it would be better to treat OTP as a new TLS key exchange algorithm (and define new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently written, this document certainly is not a "profile" of RFC 4279 in any usual sense of the word... Couple of additional comments: - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents" - Text about "hardening" should give concrete advice on how secure OTP-TLS actuallly is, given some realistic parameter values (just talking about "economically unattractive" is very vague). Best regards, Pasi=20 > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20 > Sent: 14 June, 2006 14:17 > To: tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > This recent I-D constitutes a profile layered on TLS-PSK,=20 > intended to authenticate TLS connections with the general=20 > class of One-Time Password (OTP) methods. We'd like to=20 > invite review and comment in the TLS WG. =20 >=20 > --jl _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 10:21:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvERV-0002JR-NX; Tue, 27 Jun 2006 10:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvERU-0002GI-L0 for tls@ietf.org; Tue, 27 Jun 2006 10:21:28 -0400 Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvERR-0001G0-DF for tls@ietf.org; Tue, 27 Jun 2006 10:21:28 -0400 Received: by nz-out-0102.google.com with SMTP id o1so202687nzf for ; Tue, 27 Jun 2006 07:21:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=olYbmOtj3lhNvvTXtQNXWD2R8ovQangC4L5vPbcYGDKpqpniDObcWJBCCm+npXaWKSF4QINX85F4Rsel05pwgkQRuYalQ4wO2jeP20tEgw+zig6k7au1yLJFJg/WN3nEO4AvJ/HIGV4asMeAte8wJxXeBYt2o/c1rbKnR4BYUOE= Received: by 10.36.12.12 with SMTP id 12mr769401nzl; Tue, 27 Jun 2006 07:21:25 -0700 (PDT) Received: by 10.36.80.13 with HTTP; Tue, 27 Jun 2006 07:21:24 -0700 (PDT) Message-ID: <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com> Date: Tue, 27 Jun 2006 07:21:24 -0700 From: "Anyang Ren" To: tls@ietf.org Subject: Re: [TLS] Updated TLS 1.2 I-D In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060625170241.E4704222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 6/25/06, Eric Rescorla wrote: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt In Section 1.1 Differences from TLS 1.1, you have: - Replacement of MD5/SHA-1 combination in the PRF - Replacement of MD5/SHA-1 combination in the digitally-signed element. Are you going to replace the MD5/SHA-1 combination in the verify_data field of the Finished message? The "Hash" algorithm used in RSA signatures is the same hash algorithm used in the signature of the certificate. Although this is a simple way to choose the "Hash" algorithm, the chosen hash algorithm really reflects the capability of the CA that issued the certificate as opposed to the capability of the certificate's subject (the server or the client). For example, the CA may sign a server certificate that contains an RSA public key using DSA, and "Hash" would be SHA-1 because the signature of the certificate is a DSA signature. The DSS signatures are hardcoded to use SHA-1. Are you planning to support extensions of DSA for the SHA-2 algorithms (as in Draft FIPS 186-3)? Any interest in adding SHA-384 to the enumerated HashType defined in 7.4.1.4.7? The current definition of HashType seems to imply that CAs don't plan to sign certificates with SHA-384 in the signatures. Anyang Ren Open source developer _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 10:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEUe-0005FO-OZ; Tue, 27 Jun 2006 10:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEUb-0005F8-QI for tls@ietf.org; Tue, 27 Jun 2006 10:24:41 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEUZ-0001Xr-EE for tls@ietf.org; Tue, 27 Jun 2006 10:24:41 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4BDA21E8C1F; Tue, 27 Jun 2006 07:24:38 -0700 (PDT) To: "Anyang Ren" Subject: Re: [TLS] Updated TLS 1.2 I-D References: <20060625170241.E4704222425@laser.networkresonance.com> <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com> From: Eric Rescorla Date: Tue, 27 Jun 2006 07:24:38 -0700 In-Reply-To: <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com> (Anyang Ren's message of "Tue, 27 Jun 2006 07:21:24 -0700") Message-ID: <86d5cu7k2h.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: tls-bounces@lists.ietf.org "Anyang Ren" writes: > On 6/25/06, Eric Rescorla wrote: >> I've submitted an update TLS 1.2 I-D an in the meantime >> you can find it at: >> >> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > In Section 1.1 Differences from TLS 1.1, you have: > > - Replacement of MD5/SHA-1 combination in the PRF > > - Replacement of MD5/SHA-1 combination in the digitally-signed > element. > > Are you going to replace the MD5/SHA-1 combination in the > verify_data field of the Finished message? It's already done. The PRF is used to create the verify_data. > The "Hash" algorithm used in RSA signatures is the same hash > algorithm used in the signature of the certificate. Although this > is a simple way to choose the "Hash" algorithm, the chosen hash > algorithm really reflects the capability of the CA that issued the > certificate as opposed to the capability of the certificate's subject > (the server or the client). For example, the CA may sign a server > certificate that contains an RSA public key using DSA, and "Hash" > would be SHA-1 because the signature of the certificate is a DSA > signature. Yes. This is a hueristic, but it's the one we have. Since it seems like a generally safe assumption that you can verify your own cert, I don't think there's a problem here. > The DSS signatures are hardcoded to use SHA-1. Are you planning > to support extensions of DSA for the SHA-2 algorithms (as in Draft > FIPS 186-3)? Yes. > Any interest in adding SHA-384 to the enumerated HashType defined > in 7.4.1.4.7? The current definition of HashType seems to imply that > CAs don't plan to sign certificates with SHA-384 in the signatures. I don't personally hear much interest in that. How do other WG members feel? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 10:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEnM-0000bZ-5i; Tue, 27 Jun 2006 10:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEnL-0000Zf-30 for tls@ietf.org; Tue, 27 Jun 2006 10:44:03 -0400 Received: from nz-out-0102.google.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEnI-0002x0-SC for tls@ietf.org; Tue, 27 Jun 2006 10:44:03 -0400 Received: by nz-out-0102.google.com with SMTP id q3so1754899nzb for ; Tue, 27 Jun 2006 07:44:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eaAexjit5Zo7VS04c/i/g9FC9M1Ek/blHMSgVkMsSbt46vAjNmrkx77sjr0Fm27cbz4Uoa13aLVpnrGfVGplU0Xkm4BmsXeO+bSJUBT4Tkqoz4yUxQlqc0m/GDZCw3i/W9r0B0rtyCAiazQy1iCZlukyhr2yuMS5sdLC2F3sxqw= Received: by 10.36.58.12 with SMTP id g12mr1263618nza; Tue, 27 Jun 2006 07:44:00 -0700 (PDT) Received: by 10.36.80.13 with HTTP; Tue, 27 Jun 2006 07:44:00 -0700 (PDT) Message-ID: <39932b4c0606270744w21527b03ob884212d0e05c8ff@mail.gmail.com> Date: Tue, 27 Jun 2006 07:44:00 -0700 From: "Anyang Ren" To: tls@ietf.org Subject: Re: [TLS] Updated TLS 1.2 I-D In-Reply-To: <86d5cu7k2h.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060625170241.E4704222425@laser.networkresonance.com> <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com> <86d5cu7k2h.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 6/27/06, Eric Rescorla wrote: > "Anyang Ren" writes: > > > Are you going to replace the MD5/SHA-1 combination in the > > verify_data field of the Finished message? > > It's already done. The PRF is used to create the verify_data. I was referring to the definition of verify_data in Section 7.4.10. Finished on page 65: struct { opaque verify_data[12]; } Finished; verify_data PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; The input to the PRF still contains the concatenation of MD5 and SHA-1 hashes. Anyang Ren Open source developer _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 10:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEuY-0004h1-CY; Tue, 27 Jun 2006 10:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEuX-0004gc-LY for tls@ietf.org; Tue, 27 Jun 2006 10:51:29 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEuW-0003Lp-Bu for tls@ietf.org; Tue, 27 Jun 2006 10:51:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C7EE21E8C1F; Tue, 27 Jun 2006 07:51:27 -0700 (PDT) To: "Anyang Ren" Subject: Re: [TLS] Updated TLS 1.2 I-D References: <20060625170241.E4704222425@laser.networkresonance.com> <39932b4c0606270721v19ecbed6j5fe129a42a99f106@mail.gmail.com> <86d5cu7k2h.fsf@raman.networkresonance.com> <39932b4c0606270744w21527b03ob884212d0e05c8ff@mail.gmail.com> From: Eric Rescorla Date: Tue, 27 Jun 2006 07:51:27 -0700 In-Reply-To: <39932b4c0606270744w21527b03ob884212d0e05c8ff@mail.gmail.com> (Anyang Ren's message of "Tue, 27 Jun 2006 07:44:00 -0700") Message-ID: <867j327its.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tls-bounces@lists.ietf.org "Anyang Ren" writes: > On 6/27/06, Eric Rescorla wrote: >> "Anyang Ren" writes: >> >> > Are you going to replace the MD5/SHA-1 combination in the >> > verify_data field of the Finished message? >> >> It's already done. The PRF is used to create the verify_data. > > I was referring to the definition of verify_data in Section 7.4.10. > Finished on page 65: > > struct { > opaque verify_data[12]; > } Finished; > > verify_data > PRF(master_secret, finished_label, MD5(handshake_messages) + > SHA-1(handshake_messages)) [0..11]; > > The input to the PRF still contains the concatenation of MD5 and SHA-1 hashes. No, we're going to feed in the handshake messages directly. I just forgot to change that. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 11:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFxn-00053o-GK; Tue, 27 Jun 2006 11:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFxm-00053g-90 for tls@ietf.org; Tue, 27 Jun 2006 11:58:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEvN-0003PC-Hm for tls@ietf.org; Tue, 27 Jun 2006 10:52:21 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvEif-0007J6-UL for tls@ietf.org; Tue, 27 Jun 2006 10:39:15 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for chiedprmail1.ietf.org [156.154.24.150]) with ESMTP; Tue, 27 Jun 2006 10:38:12 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPT28076; Tue, 27 Jun 2006 10:41:48 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k5REd2DU021180; Tue, 27 Jun 2006 10:39:03 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Tue, 27 Jun 2006 10:39:02 -0400 Message-ID: In-Reply-To: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDwAAEihOA= From: "Linn, John" To: , X-Spam-Score: -2.6 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= 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: , Errors-To: tls-bounces@lists.ietf.org Pasi, Thanks for the background and discussion. Leaving error alerts and = extension usage aside for the moment, there's an interesting distinction = here. Considering the phrase "key exchange" in a crypto-focused sense, = the approach proposed in the draft wasn't intended to modify the = underlying key establishment as defined in RFC-4279. Rather, it = describes a method that starts with OTP data and associated attributes, = using these to construct the inputs to PSK, DHE_PSK, and/or RSA_PSK = ciphersuites. The same messages as in RFC-4279 are applied, with = profiling (part of "key exchange" processing in a broader sense of the = term) that is specific to the method rather than to the consuming layer. = Do you see an appropriate means to reuse an existing ciphersuite in = this sort of layered fashion, rather than introducing a new and parallel = definition that would be based on the same underlying crypto processing? = The basic primitives in RFC-4279 are general and flexible, and it seems = attractive to take advantage of them as a basis for related work. =20 --jl -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Tuesday, June 27, 2006 9:29 AM To: Linn, John; tls@ietf.org Cc: Nystr=F6m, Magnus Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D = ACTION:draft-linn-otp-tls-00.txt] Hi John, The "application profile specifications" mentioned in Sections 5.2=20 and 5.4 were intended to specify how to *use* the RFC4279 ciphersuites=20 to secure some particular application/service/higher-layer-protocol, without modifying anything in TLS. (In other words, something like RFC 2818 or 4261, which are for certificate-based ciphersuites) If you significantly modify how the TLS key exchange works (as is done in this case), the architecturally right way to do so is to=20 define a new "TLS key exchange algorithm". This was discussed way back also during the PSK work (where another proposal was to tweak=20 the session resumption mechanism instead of defining a key exchange algorithm). Best regards, Pasi=20 > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20 > Sent: 27 June, 2006 16:14 > To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > Pasi, >=20 > Thanks for the review and comments, which we'll consider as=20 > input to a subsequent draft revision; in particular, we can=20 > include more quantitative discussion on OTP hardening.=20 >=20 > Rather than defining new ciphersuites that would parallel=20 > those defined in RFC-4279, we'd thought that it was feasible=20 > and appropriate to define how inputs to RFC-4279 could be=20 > constructed to support OTP scenarios, thereby achieving a=20 > modular approach that could layer on TLS-PSK rather than=20 > duplicating it. As RFC-4279, Sec. 5, begins, "It is expected=20 > that different types of identities are useful for different=20 > applications running over TLS. This document does not=20 > therefore mandate the use of any particular type of=20 > identity...". Against this backdrop, and noting that=20 > RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates=20 > use in conjunction with application profiles, we set out to=20 > profile the use of the identity field so as to represent=20 > OTP-related attributes along with the identity itself. As=20 > noted, the draft also proposes error alerts (to be used only=20 > when use of OTP-TLS is indicated) and (optional) use of TLS=20 > extensions, so extends more than just TLS-PSK; this can be=20 > clarified. With regard to the proposed structure for OTP-TLS=20 > PSK_Identity, however, we'd considered this as an example of=20 > a TLS-PSK application profile which RFC-4279 did not appear=20 > to preclude. =20 >=20 > --jl >=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Monday, June 26, 2006 11:23 AM > To: Linn, John; tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > Since the document quite significantly changes how the PSK > ciphersuites work (identity field is re-used to carry a number of > other attributes; new alert messages are added; key-exchange related > information is carried in new TLS extensions; etc.), I think it would > be better to treat OTP as a new TLS key exchange algorithm (and define > new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently > written, this document certainly is not a "profile" of RFC 4279 > in any usual sense of the word... >=20 > Couple of additional comments: >=20 > - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents" >=20 > - Text about "hardening" should give concrete advice on how secure > OTP-TLS actuallly is, given some realistic parameter values (just > talking about "economically unattractive" is very vague). >=20 > Best regards, > Pasi=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 12:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFzw-0006hi-Kd; Tue, 27 Jun 2006 12:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFzv-0006hU-Cd for tls@ietf.org; Tue, 27 Jun 2006 12:01:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE0K-0008PB-Ei for tls@ietf.org; Tue, 27 Jun 2006 09:53:24 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvDdH-00069S-Pi for tls@ietf.org; Tue, 27 Jun 2006 09:29:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RDTWIm006552; Tue, 27 Jun 2006 16:29:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:28:42 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:28:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Tue, 27 Jun 2006 16:28:46 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDw From: To: , X-OriginalArrivalTime: 27 Jun 2006 13:28:41.0773 (UTC) FILETIME=[9B41FDD0:01C699ED] X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mnystrom@rsasecurity.com 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: , Errors-To: tls-bounces@lists.ietf.org Hi John, The "application profile specifications" mentioned in Sections 5.2=20 and 5.4 were intended to specify how to *use* the RFC4279 ciphersuites=20 to secure some particular application/service/higher-layer-protocol, without modifying anything in TLS. (In other words, something like RFC 2818 or 4261, which are for certificate-based ciphersuites) If you significantly modify how the TLS key exchange works (as is done in this case), the architecturally right way to do so is to=20 define a new "TLS key exchange algorithm". This was discussed way back also during the PSK work (where another proposal was to tweak=20 the session resumption mechanism instead of defining a key exchange algorithm). Best regards, Pasi=20 > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20 > Sent: 27 June, 2006 16:14 > To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > Pasi, >=20 > Thanks for the review and comments, which we'll consider as=20 > input to a subsequent draft revision; in particular, we can=20 > include more quantitative discussion on OTP hardening.=20 >=20 > Rather than defining new ciphersuites that would parallel=20 > those defined in RFC-4279, we'd thought that it was feasible=20 > and appropriate to define how inputs to RFC-4279 could be=20 > constructed to support OTP scenarios, thereby achieving a=20 > modular approach that could layer on TLS-PSK rather than=20 > duplicating it. As RFC-4279, Sec. 5, begins, "It is expected=20 > that different types of identities are useful for different=20 > applications running over TLS. This document does not=20 > therefore mandate the use of any particular type of=20 > identity...". Against this backdrop, and noting that=20 > RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates=20 > use in conjunction with application profiles, we set out to=20 > profile the use of the identity field so as to represent=20 > OTP-related attributes along with the identity itself. As=20 > noted, the draft also proposes error alerts (to be used only=20 > when use of OTP-TLS is indicated) and (optional) use of TLS=20 > extensions, so extends more than just TLS-PSK; this can be=20 > clarified. With regard to the proposed structure for OTP-TLS=20 > PSK_Identity, however, we'd considered this as an example of=20 > a TLS-PSK application profile which RFC-4279 did not appear=20 > to preclude. =20 >=20 > --jl >=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Monday, June 26, 2006 11:23 AM > To: Linn, John; tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > Since the document quite significantly changes how the PSK > ciphersuites work (identity field is re-used to carry a number of > other attributes; new alert messages are added; key-exchange related > information is carried in new TLS extensions; etc.), I think it would > be better to treat OTP as a new TLS key exchange algorithm (and define > new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently > written, this document certainly is not a "profile" of RFC 4279 > in any usual sense of the word... >=20 > Couple of additional comments: >=20 > - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents" >=20 > - Text about "hardening" should give concrete advice on how secure > OTP-TLS actuallly is, given some realistic parameter values (just > talking about "economically unattractive" is very vague). >=20 > Best regards, > Pasi=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 27 15:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJaP-0007xJ-42; Tue, 27 Jun 2006 15:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZV-0005xB-RE; Tue, 27 Jun 2006 15:50:05 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0001OE-Ce; Tue, 27 Jun 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo21u030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Iy-Ul; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The TLS Protocol Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc4346-bis-01.txt Pages : 111 Date : 2006-6-27 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4346-bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27143453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27143453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Jun 27 19:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNKz-0005XH-Kq; Tue, 27 Jun 2006 19:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNKp-0005Qp-BO; Tue, 27 Jun 2006 19:51:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMWY-0006PJ-0A; Tue, 27 Jun 2006 18:59:14 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvMNe-0007KT-Hf; Tue, 27 Jun 2006 18:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo1UA006440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNd-0005rn-Mw; Tue, 27 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-12.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: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-12.txt Pages : 27 Date : 2006-6-27 This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-srp-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-srp-12.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: <2006-6-27154446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27154446.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Jun 28 03:45:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUjv-0003wQ-Ki; Wed, 28 Jun 2006 03:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUju-0003qY-Di for tls@ietf.org; Wed, 28 Jun 2006 03:45:34 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUjt-0007HD-Ts for tls@ietf.org; Wed, 28 Jun 2006 03:45:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5S7jQxo019717; Wed, 28 Jun 2006 10:45:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 10:45:28 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 10:45:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Date: Wed, 28 Jun 2006 10:45:27 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt] Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDwAAEihOAAJRAsQA== From: To: , X-OriginalArrivalTime: 28 Jun 2006 07:45:28.0457 (UTC) FILETIME=[D3191790:01C69A86] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mnystrom@rsasecurity.com 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: , Errors-To: tls-bounces@lists.ietf.org John, I used "key exchange algorithm" in the TLS protocol sense: a key exchange algorithm defines what information is sent in the handshake messages, how they're processed, how the pre-master secret is computed, and how exceptional situations are handled. In other words, a TLS key exchange algorithm covers more than just the cryptographic calculations. Profiling RFC4279 (or building a layer on top of RFC4279) is an appropriate thing to do if it's really _above_ the TLS layer, but if there are changes to the handshake processing (e.g. in some situation RFC4279 would send alert X, while OTP-TLS sends alert Y), then IMHO defining a new key exchange algorithm would be a better idea. Of course, the new key exchange algorithm could copy most of the details from RFC4279, so it's not a question of whether RFC4279 should be re-used or not, but rather exactly how the re-use should be done and the additional behavior negotiated in TLS... Best regards, Pasi > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20 > Sent: 27 June, 2006 17:39 > To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 > Pasi, >=20 > Thanks for the background and discussion. Leaving error=20 > alerts and extension usage aside for the moment, there's an=20 > interesting distinction here. Considering the phrase "key=20 > exchange" in a crypto-focused sense, the approach proposed in=20 > the draft wasn't intended to modify the underlying key=20 > establishment as defined in RFC-4279. Rather, it describes a=20 > method that starts with OTP data and associated attributes,=20 > using these to construct the inputs to PSK, DHE_PSK, and/or=20 > RSA_PSK ciphersuites. The same messages as in RFC-4279 are=20 > applied, with profiling (part of "key exchange" processing in=20 > a broader sense of the term) that is specific to the method=20 > rather than to the consuming layer. Do you see an=20 > appropriate means to reuse an existing ciphersuite in this=20 > sort of layered fashion, rather than introducing a new and=20 > parallel definition that would be based on the same=20 > underlying crypto processing? The basic primitives in=20 > RFC-4279 are general and flexible, and it seems attractive to=20 > take advantage of them as a basis for related work. =20 >=20 > --jl >=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Tuesday, June 27, 2006 9:29 AM > To: Linn, John; tls@ietf.org > Cc: Nystr=F6m, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20 > ACTION:draft-linn-otp-tls-00.txt] >=20 >=20 > Hi John, >=20 > The "application profile specifications" mentioned in Sections 5.2=20 > and 5.4 were intended to specify how to *use* the RFC4279=20 > ciphersuites=20 > to secure some particular application/service/higher-layer-protocol, > without modifying anything in TLS. (In other words, something > like RFC 2818 or 4261, which are for certificate-based ciphersuites) >=20 > If you significantly modify how the TLS key exchange works (as > is done in this case), the architecturally right way to do so is to=20 > define a new "TLS key exchange algorithm". This was discussed way > back also during the PSK work (where another proposal was to tweak=20 > the session resumption mechanism instead of defining a key exchange > algorithm). >=20 > Best regards, > Pasi=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 28 11:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbl4-0006cj-RP; Wed, 28 Jun 2006 11:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbl3-0006bO-JW for tls@lists.ietf.org; Wed, 28 Jun 2006 11:15:13 -0400 Received: from nz-out-0102.google.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbl2-00021p-Ct for tls@lists.ietf.org; Wed, 28 Jun 2006 11:15:13 -0400 Received: by nz-out-0102.google.com with SMTP id z31so63488nzd for ; Wed, 28 Jun 2006 08:15:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QIhYmprJQ1FyLmW4nx/VFjIs3GCkudHoCtY7HaeBa87+elVLHb9RPSWWC6fXNjOghJErJjLqWX1VQplGWcqR4mv8jxlY311Fk97HA0o8wXeDs05Ng1lUBginhpzJ9j9YbVrEvpL7M83O1MHrChUSPkZnyc5Jzg9tHLpNUkaugRs= Received: by 10.36.139.12 with SMTP id m12mr1372757nzd; Wed, 28 Jun 2006 08:15:11 -0700 (PDT) Received: by 10.36.80.13 with HTTP; Wed, 28 Jun 2006 08:15:11 -0700 (PDT) Message-ID: <39932b4c0606280815p78adb345u7961a5aefcba4176@mail.gmail.com> Date: Wed, 28 Jun 2006 08:15:11 -0700 From: "Anyang Ren" To: tls@lists.ietf.org Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt In-Reply-To: <200606270659.37003.nmav@gnutls.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060626203923.59F81222426@laser.networkresonance.com> <200606270659.37003.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: tls-bounces@lists.ietf.org On 6/26/06, Nikos Mavrogiannopoulos wrote: > > My understanding from reading the overview rfc3280: > > "Following is a simplified view of the architectural model assumed by > the PKIX specifications. > > The components in this model are: > > end entity: user of PKI certificates and/or end user system that is > the subject of a certificate; > CA: certification authority; > ..." > > and by the fact that only one issuer per certificate is allowed, makes > clear to me there is a hierarchy of certification. Is there an example > of a non-hierarchic PKIX deployment? Although only one issuer per certificate is allowed, an end entity can get multiple certificates from different CAs. CAs can also issue certificates to each other (cross-certification). -- Anyang Ren Open source developer _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 28 18:20:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOS-0001eL-Be; Wed, 28 Jun 2006 18:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOQ-0001eG-DB for tls@lists.ietf.org; Wed, 28 Jun 2006 18:20:18 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviOP-0004FV-2i for tls@lists.ietf.org; Wed, 28 Jun 2006 18:20:18 -0400 Received: by ug-out-1314.google.com with SMTP id m3so18817uge for ; Wed, 28 Jun 2006 15:20:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=tCzeJxb2ovF6PitEjPWWPGnjg8Ty7hrEXbq2D0Stxn0WJKmacCMLmCbdsHjSUhxB9A+nmAsL+mbNXmPiAQO06xaVifDZXEuVItyFWnrotK/MX2PA/L++EL27aPC8sKskFLI0jAyfnW+BjnbQE97ThK0V8/u0tx6NnlmYIdWpwoM= Received: by 10.67.93.6 with SMTP id v6mr1205284ugl; Wed, 28 Jun 2006 15:20:15 -0700 (PDT) Received: from ?172.16.1.227? ( [81.175.93.238]) by mx.gmail.com with ESMTP id m1sm224651ugc.2006.06.28.15.20.14; Wed, 28 Jun 2006 15:20:14 -0700 (PDT) From: Nikos Mavrogiannopoulos To: Stephen Kent Date: Thu, 29 Jun 2006 00:20:09 +0200 User-Agent: KMail/1.9.1 References: <20060626203923.59F81222426@laser.networkresonance.com> <200606270659.37003.nmav@gnutls.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606290020.10111.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@lists.ietf.org Subject: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed 28 Jun 2006 15:48, Stephen Kent wrote: > >How would you support this? > Each relying party is allowed to select the CAs that it views as > trust anchors. As a result, different RPs may have differing views of > the same PKI. Because a CA may have its key cross certified by > multiple other CAs, it is possible to create cert paths that > terminate at different trust anchors, depending on what TAs a given > relying party selects. All of these observations say that X.509 and > PKIX are NOT strictly hierarchic. Ok I see your point. I also noticed that hierarchical is used in several RFCs, to specify a specific form of hierarchy. So since this term is already common for this, would something like the following change address your concerns? At the time of writing, TLS [TLS] uses the PKIX [PKIX] infrastructure, to provide certificate services. Currently the PKIX protocols are limited to a structured certification model where only specific participants, the Certificate Authorities, are allowed to express trust. As a result, applications which follow more complex trust models, such as the web of trust, could not be benefited by TLS. > >RFC2818 is a document that proposes a way on how to use HTTP over > > TLS. This is not the purpose of this document. > TLS is the IETF version of SSL. SSL, like PGP (vs. OPGP) was not > born in a standards environment, but rather existed prior to IETF > involvement. The description of how to use the ID data from an X.509 > cert to provide authentication for a web server is an important part > of the semantics of SSL and TLS. I disagree with that. Why do I have to cope with HTTP? I didn't write this extension to use openpgp keys with web browsers. Sure this could be done, but then the ones that need this functionality should write the rules. I am not interested in that. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 28 18:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvifs-0008Jz-TN; Wed, 28 Jun 2006 18:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvifr-00088A-IJ for tls@lists.ietf.org; Wed, 28 Jun 2006 18:38:19 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvifq-0005eG-7f for tls@lists.ietf.org; Wed, 28 Jun 2006 18:38:19 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 776BE1E8C1F; Wed, 28 Jun 2006 15:38:17 -0700 (PDT) To: Nikos Mavrogiannopoulos Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt References: <20060626203923.59F81222426@laser.networkresonance.com> <200606270659.37003.nmav@gnutls.org> <200606290020.10111.nmav@gnutls.org> From: Eric Rescorla Date: Wed, 28 Jun 2006 15:38:17 -0700 In-Reply-To: <200606290020.10111.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 29 Jun 2006 00:20:09 +0200") Message-ID: <86y7vg52jq.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@lists.ietf.org, Stephen Kent 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: , Errors-To: tls-bounces@lists.ietf.org Nikos Mavrogiannopoulos writes: > On Wed 28 Jun 2006 15:48, Stephen Kent wrote: >> >RFC2818 is a document that proposes a way on how to use HTTP over >> > TLS. This is not the purpose of this document. > >> TLS is the IETF version of SSL. SSL, like PGP (vs. OPGP) was not >> born in a standards environment, but rather existed prior to IETF >> involvement. The description of how to use the ID data from an X.509 >> cert to provide authentication for a web server is an important part >> of the semantics of SSL and TLS. > > I disagree with that. Why do I have to cope with HTTP? I didn't write > this extension to use openpgp keys with web browsers. Sure this could be > done, but then the ones that need this functionality should write the > rules. I am not interested in that. I think I have to agree with Nikos here. TLS (2246 and 4346) are deliberately agnostic about how to determine whether a certificate matches the expected client or server. That is relegated to the upper layer protocol, in the case of HTTP it's described in RFC 2818. So, I don't think that the document in question needs to specify this. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From peach_kuppa_pac_racer@yahoo.co.jp Wed Jun 28 21:55:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvll3-00053h-JL for tls-archive@lists.ietf.org; Wed, 28 Jun 2006 21:55:53 -0400 Received: from [221.9.113.159] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fvll1-0006Dm-Im for tls-archive@lists.ietf.org; Wed, 28 Jun 2006 21:55:53 -0400 To: From: =?iso-2022-jp?B?bmFtaQ==?= Subject: =?iso-2022-jp?B?GyRCRjFBazJxJE4kKkNOJGkkOxsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca $B%9%]%s%5!<(B $BFbDjDLCN!ZFCJLAw?.![(B $BFbDjDLCN(B*$BJV?.4|F|(B07$B7n(B02$BF|Kx!Z(B10$BK|1_3MF@8"Mx(B $B![%"%C%W",(B $B2DG=(B $B!!(B $B5U!!!!!!1g!!!!!!=u!!!!!!Fb!!!!!!Dj!!!!!!DL!!!!!!CN(B $B$"$J$?$K1g=u3[#1#0K|1_0J>e$N5U1g=u$r$7$FD:$1$k=w@-(B($B%9%]%s%5!<(B)$B$N3MF@(B $B8"Mx$,FbDj$$$?$7$^$7$?$3$H$r$4Js9p$7$^$9!#!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!(B 07$B7n(B02$BF|Kx$K2<5-=w@-$KD>@\$4O"MmD:$1$l$P8"Mx3MF@$H$J$j$^$9$N$G(B $B$h$m$7$/$*4j$$$$$?$7$^$9!#!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B $BKt:#2sFbDjDLCN!ZFCJLAw?.![$N0Y2<5-$G$40FFb$N%9%]%s%5!$N=w@-MM$N%"%I!&"M!!(Bhttp://kxfv.com/?mum=0070 + $B%9%]%s%5!<(B $B=w@-(BID 271376 $B!!$*L>A0!!@FF#??5*MM!!(B36$B:P(B $B!ZCm0U![(B $B!&$3$A$i$N%a!<%k$O$"$/$^$G$b5U1g=uFbDj$N9pCN%a!<%k$G$9!#(B $B5U1g=u3NDj$r$*CN$i$;$9$k$b$N$G$O$"$j$^$;$s!#I,$:4|F|$^$G$KD>@\=w@-(B $B$K$4O"Mm$r$$$l$F$/$@$5$$!#(B $B=w@-$H0)$C$?$i$9$0$K:Y$+$$6b3[@_Dj$rFs?M$G$43NG'$7$F2<$5$$!#(B $B$"$J$?$O$*6b$r"M!!(Bhttp://kxfv.com/?mum=0070 $B:#8eG[?.$r5qH]$5$l$kJ}$O(B refuse@renai-h1.com From tls-bounces@lists.ietf.org Thu Jun 29 12:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzB1-0002Om-Qb; Thu, 29 Jun 2006 12:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzB1-0002OC-0c for tls@ietf.org; Thu, 29 Jun 2006 12:15:35 -0400 Received: from web60916.mail.yahoo.com ([209.73.178.244]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvzAv-0004q3-Lr for tls@ietf.org; Thu, 29 Jun 2006 12:15:34 -0400 Received: (qmail 25108 invoked by uid 60001); 29 Jun 2006 16:15:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IMT2aNV/BEwMAp9Z8r8u6kyqfJoQyPeCoH+HYD4auJvwyTIwtGQmXrCbRcNLBCNQMS58eoNP+DWbQpxdEkMgtOwNuBA7npXN//pVEeadGRB7Dufn4m7XjCioruoCGnFgVd7z9o1vTjDKxEnD5ts+IwQAuoQIqeukI/l7qJ0KNpA= ; Message-ID: <20060629161529.25106.qmail@web60916.mail.yahoo.com> Received: from [208.110.21.131] by web60916.mail.yahoo.com via HTTP; Thu, 29 Jun 2006 09:15:29 PDT Date: Thu, 29 Jun 2006 09:15:29 -0700 (PDT) From: Ferianto siregar To: tls@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Subject: [TLS] My TLS Compiling error ...please help me... 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="===============1782024597==" Errors-To: tls-bounces@lists.ietf.org --===============1782024597== Content-Type: multipart/alternative; boundary="0-820230188-1151597729=:23831" Content-Transfer-Encoding: 8bit --0-820230188-1151597729=:23831 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all, I try to compile the TLS Support in my openser. I use Redhat 9 and openser-1.0.1-tls packet I have done some commands like: 1. localhost@openser-1.0.1-tls # export TLS=1 2. Uncomment (enable) TLS =1 in Makefile 3. localhost@openser-1.0.1-tls # TLS=1 make all I do those task based on the tutorial that i have read from www.openser.org/docs/tls.html. But, when i run the make command, TLS=1 make all, there is an error message. The error message is make: *** [main.o] Error 1 Does someone can help me to solve this problem? What should i do ? Please help me.... NB: this is the message that i have got when run the make command >> In file included from /usr/include/openssl/ssl.h:179, >> from tls/tls_init.h:27, >> from main.c:112: >> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory >> In file included from /usr/include/openssl/ssl.h:179, >> from tls/tls_init.h:27, >> from main.c:112: >> /usr/include/openssl/kssl.h:132: parse error before "krb5_enctype" >> /usr/include/openssl/kssl.h:134: parse error before "FAR" >> /usr/include/openssl/kssl.h:135: parse error before '}' token >> /usr/include/openssl/kssl.h:147: parse error before "kssl_ctx_setstring" >> /usr/include/openssl/kssl.h:147: parse error before '*' token >> /usr/include/openssl/kssl.h:148: parse error before '*' token >> /usr/include/openssl/kssl.h:149: parse error before '*' token >> /usr/include/openssl/kssl.h:149: parse error before '*' token >> /usr/include/openssl/kssl.h:150: parse error before '*' token >> /usr/include/openssl/kssl.h:151: parse error before "kssl_ctx_setprinc" >> /usr/include/openssl/kssl.h:151: parse error before '*' token >> /usr/include/openssl/kssl.h:153: parse error before "kssl_cget_tkt" >> /usr/include/openssl/kssl.h:153: parse error before '*' token >> /usr/include/openssl/kssl.h:155: parse error before "kssl_sget_tkt" >> /usr/include/openssl/kssl.h:155: parse error before '*' token >> /usr/include/openssl/kssl.h:157: parse error before "kssl_ctx_setkey" >> /usr/include/openssl/kssl.h:157: parse error before '*' token >> /usr/include/openssl/kssl.h:159: parse error before "context" >> /usr/include/openssl/kssl.h:160: parse error before "kssl_build_principal_2" >> /usr/include/openssl/kssl.h:160: parse error before "context" >> /usr/include/openssl/kssl.h:163: parse error before "kssl_validate_times" >> /usr/include/openssl/kssl.h:163: parse error before "atime" >> /usr/include/openssl/kssl.h:165: parse error before "kssl_check_authent" >> /usr/include/openssl/kssl.h:165: parse error before '*' token >> /usr/include/openssl/kssl.h:167: parse error before "enctype" >> In file included from tls/tls_init.h:27, >> from main.c:112: >> /usr/include/openssl/ssl.h:909: parse error before "KSSL_CTX" >> /usr/include/openssl/ssl.h:931: parse error before '}' token >> make: *** [main.o] Error 1 Thank you. Sincerely yours, Ferianto --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. --0-820230188-1151597729=:23831 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all,

I try to compile the TLS Support in my openser. I use Redhat  9 and  openser-1.0.1-tls packet
I have done some commands like:
1. localhost@openser-1.0.1-tls # export TLS=1
2. Uncomment (enable) TLS =1 in Makefile
3. localhost@openser-1.0.1-tls # TLS=1 make all

I do those task based on the tutorial that i have read from www.openser.org/docs/tls.html.
But, when i run the make command, TLS=1 make all, there is an error message. The error message is

make: *** [main.o] Error 1

Does someone can help me to solve this problem? What should i do ? Please help me....

NB: this is the message that i have got when run the make command

>> In file included from /usr/include/openssl/ssl.h:179,

>>               from tls/tls_init.h:27,

>>                 from main.c:112:

>> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory

>> In file included from /usr/include/openssl/ssl.h:179,

>>                from tls/tls_init.h:27,

>>                from main.c:112:

>> /usr/include/openssl/kssl.h:132: parse error before "krb5_enctype"

>>  /usr/include/openssl/kssl.h:134: parse error before "FAR"

>>  /usr/include/openssl/kssl.h:135: parse error before '}' token

>> /usr/include/openssl/kssl.h:147: parse error before "kssl_ctx_setstring"

>> /usr/include/openssl/kssl.h:147: parse error before '*' token

>> /usr/include/openssl/kssl.h:148: parse error before '*' token

>> /usr/include/openssl/kssl.h:149: parse error before '*' token

>> /usr/include/openssl/kssl.h:149: parse error before '*' token

>> /usr/include/openssl/kssl.h:150: parse error before '*' token

>> /usr/include/openssl/kssl.h:151: parse error before "kssl_ctx_setprinc"

>> /usr/include/openssl/kssl.h:151: parse error before '*' token

>> /usr/include/openssl/kssl.h:153: parse error before "kssl_cget_tkt"

>> /usr/include/openssl/kssl.h:153: parse error before '*' token

>> /usr/include/openssl/kssl.h:155: parse error before "kssl_sget_tkt"

>> /usr/include/openssl/kssl.h:155: parse error before '*' token

>> /usr/include/openssl/kssl.h:157: parse error before "kssl_ctx_setkey"

>> /usr/include/openssl/kssl.h:157: parse error before '*' token

>> /usr/include/openssl/kssl.h:159: parse error before "context"

>> /usr/include/openssl/kssl.h:160: parse error before "kssl_build_principal_2"

>> /usr/include/openssl/kssl.h:160: parse error before "context"

>> /usr/include/openssl/kssl.h:163: parse error before "kssl_validate_times"

>> /usr/include/openssl/kssl.h:163: parse error before "atime"

>> /usr/include/openssl/kssl.h:165: parse error before "kssl_check_authent"

>> /usr/include/openssl/kssl.h:165: parse error before '*' token

>> /usr/include/openssl/kssl.h:167: parse error before "enctype"

>> In file included from tls/tls_init.h:27,

>>               from main.c:112:

>> /usr/include/openssl/ssl.h:909: parse error before "KSSL_CTX"

>> /usr/include/openssl/ssl.h:931: parse error before '}' token

>> make: *** [main.o] Error 1

 
Thank you.
Sincerely yours,

Ferianto

Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta. --0-820230188-1151597729=:23831-- --===============1782024597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1782024597==-- From tls-bounces@lists.ietf.org Fri Jun 30 08:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIGC-0001X9-E5; Fri, 30 Jun 2006 08:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIGA-0001S5-Mi for tls@ietf.org; Fri, 30 Jun 2006 08:38:10 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIG8-0000zO-7q for tls@ietf.org; Fri, 30 Jun 2006 08:38:10 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UCc39f024977; Fri, 30 Jun 2006 15:38:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:38:04 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:38:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Updated TLS 1.2 I-D Date: Fri, 30 Jun 2006 15:38:01 +0300 Message-ID: In-Reply-To: <86d5cu7k2h.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated TLS 1.2 I-D Thread-Index: AcaZ9cActYvbT2tnT3eF2DqCho9d8wCSscDA From: To: , X-OriginalArrivalTime: 30 Jun 2006 12:38:04.0367 (UTC) FILETIME=[080FDDF0:01C69C42] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > The "Hash" algorithm used in RSA signatures is the same hash > > algorithm used in the signature of the certificate. Although this > > is a simple way to choose the "Hash" algorithm, the chosen hash > > algorithm really reflects the capability of the CA that issued the > > certificate as opposed to the capability of the certificate's > > subject (the server or the client). For example, the CA may sign a > > server certificate that contains an RSA public key using DSA, and > > "Hash" would be SHA-1 because the signature of the certificate is > > a DSA signature. >=20 > Yes. This is a hueristic, but it's the one we have. Since it seems > like a generally safe assumption that you can verify your own > cert, I don't think there's a problem here. I agree with Anyang's concerns to some degree; an explicit negotiation would be better than a heuristic. But since the draft already has cert_hash_types extension, couldn't we use it to also specify what algorithms are supported for the "Signature" construct? (BTW, it would be useful if the server could also indicate to the client which hash functions it supports, e.g. for client authentication). > > Any interest in adding SHA-384 to the enumerated HashType defined > > in 7.4.1.4.7? The current definition of HashType seems to imply that > > CAs don't plan to sign certificates with SHA-384 in the signatures. >=20 > I don't personally hear much interest in that. How do other > WG members feel? Including SHA-384 would make the list match PKCS#1 (except for MD2, but I guess that's obsolete)... so maybe it would like nicer? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls