From tls-bounces@lists.ietf.org Thu Nov 01 01:07:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InSE0-0000JM-Ue; Thu, 01 Nov 2007 01:04:12 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InSDy-0000FZ-SN for tls-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 01:04:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InSDy-0007Kw-Hi for tls@ietf.org; Thu, 01 Nov 2007 01:04:10 -0400 Received: from rune.pobox.com ([208.210.124.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InSDA-0007gT-53 for tls@ietf.org; Thu, 01 Nov 2007 01:03:20 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id C2CA4152AA6 for ; Thu, 1 Nov 2007 01:03:34 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 92AE6152A4D for ; Thu, 1 Nov 2007 01:03:34 -0400 (EDT) Message-ID: <47295E32.9020402@pobox.com> Date: Wed, 31 Oct 2007 22:03:46 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> <4728FE08.3020901@pobox.com> <20071101001220.9FD5533C21@delta.rtfm.com> In-Reply-To: <20071101001220.9FD5533C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > To see this, consider a server such as Apache, which operates > multiple independent processes. There are two ways to have an > ephemeral key with a limited lifespan: have it shared across > multiple processes or have one key per process. Obviously > in the second model a key used for 100 transactions will have > a much longer lifespan than the first. Would the use of cached sessions be considered to extend the lifespan of an ephemeral key? Or is it just the sessions where it is used in a full handshake? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 01 03:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InUQV-0004NZ-Qy; Thu, 01 Nov 2007 03:25:15 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InUQU-0004MH-G8 for tls-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 03:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InUQP-0004CS-Fm for tls@ietf.org; Thu, 01 Nov 2007 03:25:09 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InUQM-0001nL-5v for tls@ietf.org; Thu, 01 Nov 2007 03:25:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3579A33C21; Thu, 1 Nov 2007 00:20:17 -0700 (PDT) Date: Thu, 01 Nov 2007 00:20:16 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] DH group validation In-Reply-To: <47295E32.9020402@pobox.com> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> <4728FE08.3020901@pobox.com> <20071101001220.9FD5533C21@delta.rtfm.com> <47295E32.9020402@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071101072017.3579A33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 At Wed, 31 Oct 2007 22:03:46 -0700, Mike wrote: > > > To see this, consider a server such as Apache, which operates > > multiple independent processes. There are two ways to have an > > ephemeral key with a limited lifespan: have it shared across > > multiple processes or have one key per process. Obviously > > in the second model a key used for 100 transactions will have > > a much longer lifespan than the first. > > Would the use of cached sessions be considered to extend the > lifespan of an ephemeral key? Or is it just the sessions > where it is used in a full handshake? I'm not sure what the question is. Clearly if you have access to the session cache you can reconstruct the keying material for any connection using that master secret. If you're interested in PFS, you need to use short session caches. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 01 10:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InagC-0001O8-Pt; Thu, 01 Nov 2007 10:05:52 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Inag9-0001Hy-UA for tls-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 10:05:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inag9-0000EZ-Iu for tls@ietf.org; Thu, 01 Nov 2007 10:05:49 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inaf7-0001lz-5S for tls@ietf.org; Thu, 01 Nov 2007 10:04:45 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id CD1472F0 for ; Thu, 1 Nov 2007 10:04:56 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 9F41F90E02 for ; Thu, 1 Nov 2007 10:04:56 -0400 (EDT) Message-ID: <4729DD0F.30900@pobox.com> Date: Thu, 01 Nov 2007 07:05:03 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> <4728FE08.3020901@pobox.com> <20071101001220.9FD5533C21@delta.rtfm.com> <47295E32.9020402@pobox.com> <20071101072017.3579A33C21@delta.rtfm.com> In-Reply-To: <20071101072017.3579A33C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > If you're > interested in PFS, you need to use short session caches. Is there any guideline on how short "short" should be? Is the recommended upper limit of 24 hours too long? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 01 10:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbNI-0004Sr-JP; Thu, 01 Nov 2007 10:50:24 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InbNH-0004SY-Gx for tls-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 10:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbNH-0004SQ-7I for tls@ietf.org; Thu, 01 Nov 2007 10:50:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbNF-0004Cu-Qk for tls@ietf.org; Thu, 01 Nov 2007 10:50:23 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1EoHrL023082 for ; Thu, 1 Nov 2007 16:50:20 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 16:48:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 16:48:56 +0200 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] DH group validation Date: Thu, 1 Nov 2007 16:49:05 +0200 Message-ID: In-Reply-To: <4728C885.4000108@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DH group validation Thread-Index: Acgb7OcRITwg4FU1TPCLR8BFcluSQgAp8gtg References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid><20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> From: To: X-OriginalArrivalTime: 01 Nov 2007 14:48:56.0576 (UTC) FILETIME=[5457A000:01C81C96] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 mike-list@pobox.com wrote: > Resurrecting the RSA_EXPORT key exchange mechanism and > repackaging it as ephemeral RSA (and removing the key length > restrictions) would solve this problem and there is already > a body of existing code to do it. These constrained clients > could even ditch all their Diffie-Hellman code, saving some > memory. I don't think this is within the scope of the TLS 1.2 document. As a separate draft, maybe (although if the absolute savings we're talking about are in the same ballpark, or less, than typical round-trip times, any "160x speedup" in one part won't have any effect on e.g. user noticeable delay). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 01 18:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inijz-00088z-W1; Thu, 01 Nov 2007 18:42:19 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Inijy-000884-Sb for tls-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 18:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inijy-00084V-J8 for tls@ietf.org; Thu, 01 Nov 2007 18:42:18 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inijh-0005mb-5T for tls@ietf.org; Thu, 01 Nov 2007 18:42:08 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id B30C02F0 for ; Thu, 1 Nov 2007 18:41:55 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 806FA90FBE for ; Thu, 1 Nov 2007 18:41:55 -0400 (EDT) Message-ID: <472A5636.30600@pobox.com> Date: Thu, 01 Nov 2007 15:41:58 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid><20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 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 >> Resurrecting the RSA_EXPORT key exchange mechanism and >> repackaging it as ephemeral RSA (and removing the key length >> restrictions) would solve this problem and there is already >> a body of existing code to do it. These constrained clients >> could even ditch all their Diffie-Hellman code, saving some >> memory. > > I don't think this is within the scope of the TLS 1.2 document. > > As a separate draft, maybe (although if the absolute savings > we're talking about are in the same ballpark, or less, than > typical round-trip times, any "160x speedup" in one part > won't have any effect on e.g. user noticeable delay). My point was that if you're going to consider modifying DHE to increase client performance, you should also consider moving to ephemeral RSA. The code is already there (RSA_EXPORT), and a few people seem interested in it. If you choose not to go with either change, that's fine. As far as a 160x speedup not being compelling enough, I would just say that my 3.2GHz machine might not show any user notice- able performance improvement, but a much slower processor could easily do the RSA encryption while struggling to do the Diffie- Hellman computations. Also being able to support only RSA, and not both RSA and DH saves on space. To be complete, I tested the performance of RSA signature verification to see if that would overwhelm the client. The numbers are: 1024-bit size RSA signature verify RSA encryption Total 1536 0.000438 0.000842 0.001280 2048 0.000438 0.001405 0.001843 For a Diffie-Hellman exchange: size RSA verify DH keygen DH secret Total 1536 0.000438 0.06978 0.06968 0.139898 2048 0.000438 0.15535 0.15286 0.308648 Still a factor of 109 to 167. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 02 18:58:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io5OR-0003SI-Qp; Fri, 02 Nov 2007 18:53:35 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Io5OP-0003Ra-Pj for tls-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 18:53:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io5OP-0003N0-Ey for tls@ietf.org; Fri, 02 Nov 2007 18:53:33 -0400 Received: from csesmtp.ucsd.edu ([132.239.51.63] helo=cse-smtp.ucsd.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io5OK-0005sk-0k for tls@ietf.org; Fri, 02 Nov 2007 18:53:28 -0400 Received: from [128.54.56.36] (0-1d-4f-f6-9f-d8.dynamic.ucsd.edu [128.54.56.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id D9B892C18E for ; Fri, 2 Nov 2007 15:53:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tls@ietf.org From: Hovav Shacham Date: Fri, 2 Nov 2007 15:53:27 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [TLS] removing cipher suites for 1.2 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, all -- I'd like to propose that we remove some cipher suites from TLS 1.2. The goal is to reduce the number of choices to keep people from making the wrong ones, and to reduce the amount of complexity in the main TLS standard overall. My philosophy is that we should think that everything in the main TLS standard is a good idea and worth implementing. In particular, I'd like to discourage the use of single-DES, IDEA, and anything export-strength. This gives the following cipher suites, I believe: CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; I'd suggest that these numbers be marked as reserved to avoid backward-compatibility problems. I'd also suggest removing some of the values from the BulkCipherAlgorithm enum, specifically rc2, des, des40, and idea. Cheers -- Hovav Shacham. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 02 21:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io7qG-00074a-Iw; Fri, 02 Nov 2007 21:30:28 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Io7qD-00071t-6A for tls-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 21:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io7qC-0006yQ-Rp; Fri, 02 Nov 2007 21:30:24 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io7q1-00043t-Ld; Fri, 02 Nov 2007 21:30:19 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 716C0EBAE4; Fri, 2 Nov 2007 18:29:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071103012958.716C0EBAE4@bosco.isi.edu> Date: Fri, 2 Nov 2007 18:29:58 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 5081 on Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 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 A new Request for Comments is now available in online RFC libraries. RFC 5081 Title: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication Author: N. Mavrogiannopoulos Status: Experimental Date: November 2007 Mailbox: nmav@gnutls.org Pages: 8 Characters: 15300 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-openpgp-keys-11.txt URL: http://www.rfc-editor.org/rfc/rfc5081.txt This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Transport Layer Security Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 02 23:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io9dA-00082O-8b; Fri, 02 Nov 2007 23:25:04 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Io9d8-00081n-NV for tls-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 23:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io9d8-00081f-Df for tls@ietf.org; Fri, 02 Nov 2007 23:25:02 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io9d2-0000Ky-3S for tls@ietf.org; Fri, 02 Nov 2007 23:25:02 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9C74C48056B; Sat, 3 Nov 2007 16:24:18 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCPD5x056Ldu; Sat, 3 Nov 2007 16:24:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 604DF480515; Sat, 3 Nov 2007 16:24:17 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6B73DE080B5; Sat, 3 Nov 2007 16:24:17 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Io9cP-0004VZ-6m; Sat, 03 Nov 2007 16:24:17 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hovav@hovav.net, tls@ietf.org Subject: Re: [TLS] removing cipher suites for 1.2 In-Reply-To: Message-Id: Date: Sat, 03 Nov 2007 16:24:17 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Hovav Shacham writes: >In particular, I'd like to discourage the use of single-DES, IDEA, and >anything export-strength. Just as a data point, about:config indicates that these are disabled by default in Firefox so there's pretty good evidence there that there's no problem in removing them. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 03 20:34:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoTQx-0004RM-Sc; Sat, 03 Nov 2007 20:33:47 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IoTQw-0004Qb-HL for tls-confirm+ok@megatron.ietf.org; Sat, 03 Nov 2007 20:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoTQw-0004QD-7k for tls@ietf.org; Sat, 03 Nov 2007 20:33:46 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoTQu-0001b4-VZ for tls@ietf.org; Sat, 03 Nov 2007 20:33:46 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1015113rvb for ; Sat, 03 Nov 2007 17:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VRhSfFW92ims9UcFxpiuhjpT1XXH/4OCuXVxIF4X3XU=; b=GHwuRt/3ImI07iwpUHAF2diuEqAdxItC6Tw2VP8uSEF2q4OEcbmdfMCdAr1qVYgElO4TEolPCeVAf525H33mY6SS+v8TZohRIOvcezGlVgbDkODwY0nsXVLkhiMpAiIYX1CA+U+POZs/G8G3q1aSCorHzpd00iLJyn+0kegCWRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M37Ps2OqJcmHiv9AyJ0KXiU4sqGku305QizuC33RUeZrn10hC3NoLuhbzhEcdBOWElV6nZ5vMcBksfwg1r5Y/v2DirqBnwCbZVvQbrOJB7ubyrUYXKx0tR4YReUQ0jyOdKULkzI5B3lapM0FHRX+Nd6j8pFCDQknoEJ7NC7Czss= Received: by 10.140.148.3 with SMTP id v3mr1646696rvd.1194136422498; Sat, 03 Nov 2007 17:33:42 -0700 (PDT) Received: by 10.140.202.8 with HTTP; Sat, 3 Nov 2007 17:33:42 -0700 (PDT) Message-ID: <8637da890711031733o3fdccfebg24e43790e2bb78d0@mail.gmail.com> Date: Sat, 3 Nov 2007 17:33:42 -0700 From: "Wan-Teh Chang" To: tls@ietf.org Subject: Re: [TLS] removing cipher suites for 1.2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 11/2/07, Peter Gutmann wrote: > Hovav Shacham writes: > > >In particular, I'd like to discourage the use of single-DES, IDEA, and > >anything export-strength. > > Just as a data point, about:config indicates that these are disabled by > default in Firefox so there's pretty good evidence there that there's no > problem in removing them. I believe that these are also disabled in IE7 on Windows Vista. See http://blogs.msdn.com/ie/archive/2006/03/15/552246.aspx Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 05 06:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoztN-00023n-FI; Mon, 05 Nov 2007 06:13:17 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IoztM-00022Z-5U for tls-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 06:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoztL-00022R-SE for tls@ietf.org; Mon, 05 Nov 2007 06:13:15 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoztK-00040k-DV for tls@ietf.org; Mon, 05 Nov 2007 06:13:15 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA5BAHOo012302; Mon, 5 Nov 2007 13:10:59 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:10:31 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:05:51 +0200 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] removing cipher suites for 1.2 Date: Mon, 5 Nov 2007 13:05:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] removing cipher suites for 1.2 Thread-Index: AcgdpWFZ50D8j8DfT8S6YUnbwrVFJAB9XRbQ References: From: To: , X-OriginalArrivalTime: 05 Nov 2007 11:05:51.0999 (UTC) FILETIME=[D42A40F0:01C81F9B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 The "export strength" cipher suites were already removed in TLS 1.1. I guess single-DES is also obsolete, and IDEA isn't very=20 widely used either... Best regards, Pasi > -----Original Message----- > From: ext Hovav Shacham [mailto:hovav@hovav.net]=20 > Sent: 03 November, 2007 00:53 > To: tls@ietf.org > Subject: [TLS] removing cipher suites for 1.2 >=20 > Hi, all -- >=20 >=20 > I'd like to propose that we remove some cipher suites from TLS 1.2. =20 > The goal is to reduce the number of choices to keep people from =20 > making the wrong ones, and to reduce the amount of complexity in the =20 > main TLS standard overall. >=20 > My philosophy is that we should think that everything in the=20 > main TLS =20 > standard is a good idea and worth implementing. >=20 > In particular, I'd like to discourage the use of single-DES, IDEA, =20 > and anything export-strength. >=20 > This gives the following cipher suites, I believe: >=20 > CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA =3D {=20 > 0x00,0x07 }; > CipherSuite TLS_RSA_WITH_DES_CBC_SHA =3D {=20 > 0x00,0x09 }; > CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA =3D {=20 > 0x00,0x0C }; > CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA =3D {=20 > 0x00,0x0F }; > CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA =3D {=20 > 0x00,0x12 }; > CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA =3D {=20 > 0x00,0x15 }; > CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA =3D { 0x00, =20 > 0x1A }; >=20 > CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 =3D {=20 > 0x00,0x03 }; > CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 =3D {=20 > 0x00,0x06 }; > CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x08 }; > CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x0B }; > CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x0E }; > CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x11 }; > CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x14 }; > CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 =3D {=20 > 0x00,0x17 }; > CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA =3D {=20 > 0x00,0x19 }; >=20 > I'd suggest that these numbers be marked as reserved to avoid =20 > backward-compatibility problems. >=20 > I'd also suggest removing some of the values from the =20 > BulkCipherAlgorithm enum, specifically rc2, des, des40, and idea. >=20 >=20 > Cheers -- > Hovav Shacham. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 06 12:16:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpS2I-0000rE-PK; Tue, 06 Nov 2007 12:16:22 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpS2H-0000qo-A8 for tls-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 12:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpS2G-0000ps-W1 for tls@lists.ietf.org; Tue, 06 Nov 2007 12:16:20 -0500 Received: from emerald.yonsei.ac.kr ([165.132.120.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpS2D-0001Vm-CE for tls@lists.ietf.org; Tue, 06 Nov 2007 12:16:20 -0500 Received: from sky (diamond.yonsei.ac.kr [165.132.120.136]) by emerald.yonsei.ac.kr (Postfix) with ESMTP id C6D1A4801CD71 for ; Wed, 7 Nov 2007 02:16:15 +0900 (KST) From: "jjb27" To: Date: Wed, 7 Nov 2007 02:15:13 +0900 Message-ID: <000001c82098$97defbb0$c79cf310$@yonsei.ac.kr> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcggmJbiq0zahqi6QPeD6DIuVWnhng== Content-Language: ko X-Spam-Score: 2.3 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [TLS] Wireless LAN with TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1821772705==" Errors-To: tls-bounces@lists.ietf.org 여러 부분으로 구성된 MIME 형식의 메시지입니다. --===============1821772705== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C820E4.07C6A3B0" Content-Language: ko 여러 부분으로 구성된 MIME 형식의 메시지입니다. ------=_NextPart_000_0001_01C820E4.07C6A3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit These days, I'm interested in the TLS in the wireless LAN infrastructure for the authentication and securing channel. Is it possible? and progressing now? ------=_NextPart_000_0001_01C820E4.07C6A3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These days, I'm interested in the TLS in the wireless LAN infrastructure

 for the authentication and securing = channel.

 

Is it possible? and progressing = now?

 

------=_NextPart_000_0001_01C820E4.07C6A3B0-- --===============1821772705== 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 --===============1821772705==-- From tls-bounces@lists.ietf.org Tue Nov 06 13:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSoA-0001OT-6I; Tue, 06 Nov 2007 13:05:50 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpSo8-0001ON-Iy for tls-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:05:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSo7-0001O9-UC for tls@lists.ietf.org; Tue, 06 Nov 2007 13:05:47 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpSo4-0002tB-Ot for tls@lists.ietf.org; Tue, 06 Nov 2007 13:05:47 -0500 Received: (qmail 14517 invoked by uid 0); 6 Nov 2007 18:05:38 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 6 Nov 2007 18:05:38 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Nov 2007 13:01:55 -0500 To: jjb27@emerald.yonsei.ac.kr From: Russ Housley Subject: Re: [TLS] Wireless LAN with TLS In-Reply-To: <000001c82098$97defbb0$c79cf310$@yonsei.ac.kr> References: <000001c82098$97defbb0$c79cf310$@yonsei.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Message-Id: Cc: tls@lists.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 Are you asking about EAP-TLS for the authentication of the wireless station and the access point or base station? If so, that discussion is happening in the EMU WG. At 12:15 PM 11/6/2007, jjb27 wrote: >These days, I'm interested in the TLS in the wireless LAN infrastructure > for the authentication and securing channel. > >Is it possible? and progressing now? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 10:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpmXj-0005wk-4D; Wed, 07 Nov 2007 10:10:11 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpmXh-0005vd-Ez for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 10:10:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpmXh-0005vE-2z for tls@ietf.org; Wed, 07 Nov 2007 10:10:09 -0500 Received: from wp056.webpack.hosteurope.de ([80.237.132.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpmXe-0004Gu-RT for tls@ietf.org; Wed, 07 Nov 2007 10:10:09 -0500 Received: from dslb-084-056-154-234.pools.arcor-ip.net ([84.56.154.234] helo=[192.168.178.21]); authenticated by wp056.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:RC4-MD5:128) id 1IpmXd-000074-T6; Wed, 07 Nov 2007 16:10:05 +0100 Message-ID: <4731D54C.9080809@oliroll.de> Date: Wed, 07 Nov 2007 16:10:04 +0100 From: Oliver Roll User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;mail@oliroll.de;1194448206;2d3145ac; X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [TLS] DTLS over SCTP - Implementation available? 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, I'm interested in sending (DTLS-) secured data over SCTP (with & without partial reliability extension). I read most of the material google provides on this topic, but I didn't get a clear picture of what actually is possible by now. I read Michael Tuexen's draft on the combination DTLS + SCTP AUTH as actual work in progress. I read about "plain DTLS over SCTP" as the simplest way in the article "Secure End-to-End Transport Over SCTP" by Erwin Rathgeb et. al. As a start for me, is there any implementation (or code snippet) yet which runs "plain DTLS over SCTP"? Thanks & best regards, Oliver _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 14:05:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqD1-0001yc-0p; Wed, 07 Nov 2007 14:05:03 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpqCz-0001tb-8z for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqCy-0001t2-VQ for tls@ietf.org; Wed, 07 Nov 2007 14:05:00 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpqCw-0004xE-G9 for tls@ietf.org; Wed, 07 Nov 2007 14:05:00 -0500 Received: from [192.168.1.198] (p508FBF44.dip.t-dialin.net [80.143.191.68]) by mail-n.franken.de (Postfix) with ESMTP id CD7BE80000BD; Wed, 7 Nov 2007 20:04:56 +0100 (CET) (KNF-authenticated sender: micmac) Message-Id: From: Michael Tuexen To: Oliver Roll In-Reply-To: <4731D54C.9080809@oliroll.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [TLS] DTLS over SCTP - Implementation available? Date: Wed, 7 Nov 2007 20:04:55 +0100 References: <4731D54C.9080809@oliroll.de> X-Mailer: Apple Mail (2.912) X-Spam-Score: 2.2 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Oliver, see my comments in-line. Best regards Michael On Nov 7, 2007, at 4:10 PM, Oliver Roll wrote: > Dear all, > > I'm interested in sending (DTLS-) secured data over SCTP (with & > without > partial reliability extension). > I read most of the material google provides on this topic, but I > didn't > get a clear picture of what actually is possible by now. I read > Michael > Tuexen's draft on the combination DTLS + SCTP AUTH as actual work in > progress. Yes, it will also be updated. > > I read about "plain DTLS over SCTP" as the simplest way in the article > "Secure End-to-End Transport Over SCTP" by Erwin Rathgeb et. al. As a > start for me, is there any implementation (or code snippet) yet which > runs "plain DTLS over SCTP"? Not yet. A student of mine is implementing this by using OpenSSL (which supports DTLS). We will make this code available once it is in a usable state. > > > Thanks & best regards, > > Oliver > > > > _______________________________________________ > 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 Wed Nov 07 14:37:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipqil-0005UW-Cr; Wed, 07 Nov 2007 14:37:51 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ipqik-0005Tt-GF for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipqik-0005Tk-6K for TLS@lists.ietf.org; Wed, 07 Nov 2007 14:37:50 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipqih-0006Vg-G0 for TLS@lists.ietf.org; Wed, 07 Nov 2007 14:37:50 -0500 Received: from sap.corp by smtpde02.sap-ag.de (26) with ESMTP id lA7JbioZ025178 for ; Wed, 7 Nov 2007 20:37:44 +0100 (MET) From: Martin Rex Message-Id: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> To: TLS@lists.ietf.org Date: Wed, 7 Nov 2007 20:36:37 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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 I'm finally back at work and investigating a bug in the SSL client certificate code of our OEM implementation and after reading the current TLS v1.2 document it appears that the spec is still unclear what implementations should do for multi-level CA hierarchies. The description of the "7.4.4. Certificate Request" handshake message explicitly allows a TLS-Server to announce subordinate CAs (which I think is useful), but I'm somewhat confused about what a client is supposed or allowed to send as a certificate_list (not where it starts, but where it ends), and what the server is supposed to allow or allowed to / expected to reject. I would appreciate guidance in the spec here. Scenario: PKI with 3-level CA hierarchy for SSL client authentication: RootCA, SubCA1, SubCA2, EndEntity(User) According to 7.4.4. the SSL server can send/include any one possible subset of (RootCAs,SubCA1,SubCA2) as acceptable certificate_authorities in the CertificateRequest message. Which "matching" certification authority the client implementation depends on the clients search strategy and possibly the order of the certification_authorities in the CertificateRequest message of the server. IMHO, the most sensible approach would be for the server to send Subordinate CAs names before their issuing CA names, but for some SSL/TLS (server side) implementations it might be difficult or impossible to configure a particular ordering, but the client will always receive a particular order, be it a side-effect of the server SSL/TLS implementation or a conscious decision (aka preference list) of the servers admin. I'm not sure what would be the best approach for the client would be to (a) search for the "most desirable" certification authority, and whether it is allowed to send certificates in the certificate_list of the ClientCertificate message beyond the "matching" certification authority, in case that matching certification authority was actually a subordinate CA. Personally, I would consider it a client-side bug if the client would send a CA certificate beyond the matched certification authority from the CertificateRequest, _unless_ the server explicitly announced this higher certification authority also in the certification_authorities list of the CertificateRequest message. Conceivable reasons why a client may not want to (or not be able to) send a full path ending at a self-signed CA certificate (and appreciate the server to announce subordinate CAs) might be - size constraints of a crypto hardware token or device (it may not store chain certs), - bandwith savings for the ClientCertificate handshake message. - reduced work for the server: it does not need to parse and to process (even if processing just means comparing and ignoring) CA certs beyond a trusted subordinate CA >From how I read OpenSSL code (s3_both.c from 0.9.7g) I assume that OpenSSL will unconditionally send all available path certificates up to a self-signed (CA) cert. SSL clients sending unrequested/extra CA certs in the ClientCertificate message will unnecessarily drain resources from the SSL server (and preclude this small optimization from the server admin). Opinions? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 18:42:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpuXE-00009q-E5; Wed, 07 Nov 2007 18:42:12 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpuXD-00009j-8V for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 18:42:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpuXC-00009b-VH for tls@ietf.org; Wed, 07 Nov 2007 18:42:10 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpuX9-0007Q6-1s for tls@ietf.org; Wed, 07 Nov 2007 18:42:10 -0500 Received: from sap.corp by smtpde03.sap-ag.de (26) with ESMTP id lA7Nfx7A023610; Thu, 8 Nov 2007 00:42:00 +0100 (MET) From: Martin Rex Message-Id: <200711072341.lA7Nfx87015549@fs4113.wdf.sap.corp> Subject: Re: [TLS] removing cipher suites for 1.2 To: hovav@hovav.net (Hovav Shacham) Date: Thu, 8 Nov 2007 00:41:59 +0100 (MET) In-Reply-To: from "Hovav Shacham" at Nov 2, 7 03:53:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: -4.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: martin.rex@sap.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 Hovav Shacham wrote: > > Hi, all -- > > > I'd like to propose that we remove some cipher suites from TLS 1.2. > The goal is to reduce the number of choices to keep people from > making the wrong ones, and to reduce the amount of complexity in the > main TLS standard overall. I don't understand you request. They have been removed from TLS 1.2 (from the protocol, not from the specification document, that is). What is _NOT_ clear about the last paragraph(s) of Section A.5 of the current TLS v1.2 draft (draft-ietf-tls-rfc4346-bis-06.txt): When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak and export restrictions have ! since been loosened. TLS 1.2 implementations MUST NOT negotiate these ! cipher suites in TLS 1.2 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS 1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers. CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; My impression is that there is a significant installed base that doesn't have TLS v1.1, so removing them from the specifiction document doesn't seem like a good idea to me. I'm already very uncomfortable with "silent" backwards-incompatible changes in the SSLv3->TLSv1.x protocol revisions that requires implementors to read all documents individually and find out the backward incompatible changes on their own. Regards, -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 18:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipunm-0008SF-A8; Wed, 07 Nov 2007 18:59:18 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ipunk-0008RA-PA for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 18:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipunk-0008R1-FP for tls@ietf.org; Wed, 07 Nov 2007 18:59:16 -0500 Received: from cse-smtp.ucsd.edu ([132.239.51.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipunh-0007wn-23 for tls@ietf.org; Wed, 07 Nov 2007 18:59:16 -0500 Received: from [128.54.58.185] (0-1d-4f-f6-9f-d8.dynamic.ucsd.edu [128.54.58.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id 3BE682C0DE for ; Wed, 7 Nov 2007 15:59:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200711072341.lA7Nfx87015549@fs4113.wdf.sap.corp> References: <200711072341.lA7Nfx87015549@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hovav Shacham Subject: Re: [TLS] removing cipher suites for 1.2 Date: Wed, 7 Nov 2007 15:59:10 -0800 To: tls@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > I don't understand you request. They have been removed from TLS 1.2 > (from the protocol, not from the specification document, that is). First, I am proposing that more cipher suites than just the export cipher suites be removed. Single-DES and IDEA are not export- strength ciphers. > ! since been loosened. TLS 1.2 implementations MUST NOT negotiate > these > ! cipher suites in TLS 1.2 mode. However, for backward compatibility > they may be offered in the ClientHello for use with TLS 1.0 or > SSLv3 > only servers. TLS 1.2 clients MUST check that the server did not > choose one of these cipher suites during the handshake. These > ciphersuites are listed below for informational purposes and to > reserve the numbers. I don't disagree that this is okay, but I would prefer that TLS 1.2 implementations be required never to list export cipher specs in the ClientHello. I do not see the downside to redefining these cipher spec numbers as reserved. However, I would be willing to live with the current export language if we can apply it to single-DES and IDEA as well. Cheers -- Hovav. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 19:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvAD-00012x-W8; Wed, 07 Nov 2007 19:22:29 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpvA9-0000tU-W7 for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 19:22:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvA9-0000tM-Lt for tls@ietf.org; Wed, 07 Nov 2007 19:22:25 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpvA9-0000Kz-5M for tls@ietf.org; Wed, 07 Nov 2007 19:22:25 -0500 Received: from sap.corp by smtpde02.sap-ag.de (26) with ESMTP id lA80MM1h009437; Thu, 8 Nov 2007 01:22:22 +0100 (MET) From: Martin Rex Message-Id: <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> Subject: Re: [TLS] removing cipher suites for 1.2 To: hovav@hovav.net (Hovav Shacham) Date: Thu, 8 Nov 2007 01:22:22 +0100 (MET) In-Reply-To: from "Hovav Shacham" at Nov 7, 7 03:59:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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 Hovav Shacham wrote: > > > I don't understand you request. They have been removed from TLS 1.2 > > (from the protocol, not from the specification document, that is). > > First, I am proposing that more cipher suites than just the export > cipher suites be removed. Single-DES and IDEA are not export- > strength ciphers. For the original SSLv3 (spec dated Nov-1996) the EXPORT grade was 40-bit. IIRC, the single-DES ciphersuites were added to accomodate the raised US crypto-export regulations somewhere around 1999/2000, but the period wasn't long enough and the issue not significant enough to deserve "EXPORT" labelling in any of the documents. I don't recall that IDEA was ever called weak, but it has always been esoteric because it had been patent-encumbered (the patent may have expired by now, but I don't know). > > I don't disagree that this is okay, but I would prefer that TLS 1.2 > implementations be required never to list export cipher specs in the > ClientHello. I do not see the downside to redefining these cipher > spec numbers as reserved. I will strongly object to a requirement that would require TLSv1.2 implementations to significantly impair interoperability with the installed base of TLSv1.0 or SSLv3. A policy option to that effect at the discretion of a consumer of this technology is OK, but not an implementation requirement to impair interoperability. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 07 21:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwnV-0007Sa-K3; Wed, 07 Nov 2007 21:07:09 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IpwnU-0007SQ-G5 for tls-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 21:07:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwnU-0007SI-5w for tls@ietf.org; Wed, 07 Nov 2007 21:07:08 -0500 Received: from csesmtp.ucsd.edu ([132.239.51.63] helo=cse-smtp.ucsd.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpwnT-0003h2-Sd for tls@ietf.org; Wed, 07 Nov 2007 21:07:08 -0500 Received: from [128.54.58.185] (0-1d-4f-f6-9f-d8.dynamic.ucsd.edu [128.54.58.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id 5FBD82C1B8; Wed, 7 Nov 2007 18:07:03 -0800 (PST) In-Reply-To: <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> References: <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73EDB8D9-6345-49F3-96A9-6C34B59793F6@hovav.net> Content-Transfer-Encoding: 7bit From: Hovav Shacham Subject: Re: [TLS] removing cipher suites for 1.2 Date: Wed, 7 Nov 2007 18:07:01 -0800 To: tls@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Martin Rex wrote: > IIRC, the single-DES ciphersuites were added to accomodate > the raised US crypto-export regulations somewhere around 1999/2000, > but the period wasn't long enough and the issue not significant > enough to deserve "EXPORT" labelling in any of the documents. So, single DES is weak -- due to its small keyspace -- and should not be negotiated. > I don't recall that IDEA was ever called weak, but it has always been > esoteric For block ciphers, "esoteric" means "weak." IDEA should not be negotiated. Cheers -- Hovav. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 08 02:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1s0-00035m-V6; Thu, 08 Nov 2007 02:32:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iq1rz-00031v-UC for tls-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 02:32:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1rz-00030K-Hy for tls@ietf.org; Thu, 08 Nov 2007 02:32:07 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq1rv-0003Sh-BT for tls@ietf.org; Thu, 08 Nov 2007 02:32:06 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA87Vfgs002453; Thu, 8 Nov 2007 09:32:00 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 09:31:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 09:31:42 +0200 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] removing cipher suites for 1.2 Date: Thu, 8 Nov 2007 09:31:40 +0200 Message-ID: In-Reply-To: <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] removing cipher suites for 1.2 Thread-Index: AcghnX38O80qPx53Tfi8mgtykOEFLAAOwIlQ References: from "HovavShacham" at Nov 7, 7 03:59:10 pm <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> From: To: , X-OriginalArrivalTime: 08 Nov 2007 07:31:42.0170 (UTC) FILETIME=[684F33A0:01C821D9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Martin Rex wrote: > IIRC, the single-DES ciphersuites were added to accomodate > the raised US crypto-export regulations somewhere around 1999/2000, > but the period wasn't long enough and the issue not significant > enough to deserve "EXPORT" labelling in any of the documents. The single-DES ciphersuites were present already in SSLv2 and SSLv3, around 1994/1995 (and were in all TLS 1.0 drafts, as well). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 08 21:12:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJMI-0008Vb-5Z; Thu, 08 Nov 2007 21:12:34 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IqJMH-0008V6-9c for tls-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 21:12:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJMG-0008Ru-Ue for tls@ietf.org; Thu, 08 Nov 2007 21:12:32 -0500 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqJMA-000816-Lo for tls@ietf.org; Thu, 08 Nov 2007 21:12:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9B1664804F2; Fri, 9 Nov 2007 15:12:18 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I97DzrojbY9E; Fri, 9 Nov 2007 15:12:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6AC294804CE; Fri, 9 Nov 2007 15:12:18 +1300 (NZDT) Received: from wintermute02.cs.auckland.ac.nz (wintermute02.cs.auckland.ac.nz [130.216.207.92]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 15C8219EC0B6; Fri, 9 Nov 2007 15:12:16 +1300 (NZDT) Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1IqJLz-00078d-UV; Fri, 09 Nov 2007 15:12:15 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] removing cipher suites for 1.2 In-Reply-To: <200711080022.lA80MMCQ023492@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 09 Nov 2007 15:12:15 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Martin Rex writes: >I don't recall that IDEA was ever called weak, but it has always been >esoteric because it had been patent-encumbered (the patent may have expired >by now, but I don't know). The first patents were issued in 1991, so it's got a while to go yet. However even if was unencumbered, you've got a cipher designed for circa-1990 processors, full of complex 16-bit operations that are a right pain on RISC 32-bit and 64-bit CPUs. The only reason it's still in there is because PGP 2.x used it. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 09 06:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqS7W-00008F-EN; Fri, 09 Nov 2007 06:33:54 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IqS7U-00006v-Kw for tls-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 06:33:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqS7U-00006n-BJ for TLS@lists.ietf.org; Fri, 09 Nov 2007 06:33:52 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqS7R-0002es-N7 for TLS@lists.ietf.org; Fri, 09 Nov 2007 06:33:52 -0500 Received: from tau.invalid (p508EA515.dip0.t-ipconnect.de [80.142.165.21]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IqS7H0wwi-0001tD; Fri, 09 Nov 2007 12:33:39 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 963CD1BBE7; Fri, 9 Nov 2007 12:33:37 +0100 (CET) Date: Fri, 9 Nov 2007 12:33:37 +0100 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] CAs and certificate chains in the SSL/TLS handshake Message-ID: <20071109113337.GA26370@tau.invalid> References: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX19BfMS6OdUz+jzF0FLzeCX4V/6MxnkzkZF+HJV FTc/JnS3D1YUUVuUL5fCO8glB0rj3mUe5SPvw4cBvHzgRIK3Vn 6hLkUbziE3ZnovYfupLUdfSfa1d4hW9lF78Die27NuHVZCb3yV DNA== X-Spam-Score: -0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: TLS@lists.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 Wed, Nov 07, 2007 at 08:36:37PM +0100, Martin Rex wrote: [...] > Personally, I would consider it a client-side bug if the client > would send a CA certificate beyond the matched certification > authority from the CertificateRequest, _unless_ the server > explicitly announced this higher certification authority also > in the certification_authorities list of the CertificateRequest > message. The preferred client behavior that you describe here certainly makes a lot of sense. However, I wouldn't want to strictly require it. Rather, I think that is a feature that (low-footprint) clients can treat their own certificate chain as a blob and just send the complete chain without having to take into account its structure. (Occasionally there might even be an actual advantage in seeing the complete chain, beyond those CAs found in the certification_authorities list: Remember that the list only provides distinguished names, which need not uniquely denote specific certificates. If the client has a certificate chain containing one of the acceptable distinguished names, the server still might be unable to verify this chain because none of the certificates in it is trusted. In this case, knowing the complete CA chain might turn out to be useful for analysing the whole mess, even if all the TLS implementation can do with this is help dump the CA chain information into a logfile.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 12 12:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcoO-0007Ah-Ht; Mon, 12 Nov 2007 12:11:00 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IrcoN-0007AY-F5 for tls-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 12:10:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcoM-0007A8-C9 for tls@ietf.org; Mon, 12 Nov 2007 12:10:58 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcoL-0000aj-V8 for tls@ietf.org; Mon, 12 Nov 2007 12:10:58 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E6CDA33C2B; Mon, 12 Nov 2007 09:06:07 -0800 (PST) Date: Mon, 12 Nov 2007 09:06:06 -0800 From: Eric Rescorla To: In-Reply-To: References: <20071029214813.CD3DC33C3D@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071112170607.E6CDA33C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org Subject: [TLS] Re: Updated TLS ID (certificate restrictions #57) 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 At Wed, 31 Oct 2007 17:24:59 +0200, wrote: At Wed, 31 Oct 2007 17:24:59 +0200, wrote: > > Eric Rescorla wrote: > > > The changes list is: > > - Redid the hash function advertisements for CertificateRequest > > and the client-side extension. They are now pairs of > > hash/signature and the semantics are clearly defined for > > all uses of signatures (hopefully). [Issue 41] > > > - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57] > > This looks pretty good. In Section 7.4.2, I think there's > still some room for simplification. Currently it says: > > If no "signature_algorithms" extension is present, the end-entity > certificate MUST be signed as follows: > > Key Exchange Alg. Signature Algorithm Used by Issuer > > RSA RSA (RSASSA-PKCS1-v1_5) > DHE_RSA > DH_RSA > RSA_PSK > ECDH_RSA > ECDHE_RSA > > DHE_DSS DSA > DH_DSS > > ECDH_ECDSA ECDSA > ECDHE_ECDSA > > I think it would be simpler to specify the default behavior > in one place, and not to make it ciphersuite-dependent. > E.g. "if the client does not send signature_algorithms, > behave as if rsa+sha1 had been sent". Or we could just require > everyone to send signature_algorithms. So, I see where you're going with this, but I'm concerned about making it (say) RSA-SHA1 because that would potentially make currently compliant configurations noncompliant (e.g., if you had a pure DSA-DH shop). As for requiring signature_algorithms, I'm concerned about requring extensions. I think we're getting close to the point where it's definitely safe, but I'm not sure we're there yet. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 12 14:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iremt-0007dn-Mt; Mon, 12 Nov 2007 14:17:35 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iremr-0007da-Rc for tls-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:17:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iremr-0007dG-HH for tls@ietf.org; Mon, 12 Nov 2007 14:17:33 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iremr-0006JL-5g for tls@ietf.org; Mon, 12 Nov 2007 14:17:33 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1881733C3D; Mon, 12 Nov 2007 11:12:23 -0800 (PST) Date: Mon, 12 Nov 2007 11:12:23 -0800 From: Eric Rescorla To: ietf-pkix@imc.org, tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071112191223.1881733C3D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [TLS] DSA/SHA-1, and OIDs 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 PKIX guys, As you probably know, in some modes of TLS one or the other party signs data. In some cases, this presumably means DSA. This is fine if you can guarantee that you are going to use SHA-1 with DSA, but obviously there's going to be a desire to transition to SHA-256, which raises the issue of digest substitution. My understanding of the current thinking on how to prevent this is to indicate in the certificate which digest algorithm is to be used with the cert. So, the rule we plan to promulgate in TLS is: OID 1 2 840 10040 4 1 MUST only be used with SHA-1. Future revisions of [PKIX] MAY define new object identifiers for DSA with other hash algorithms. I wanted to check that this is compatible with the current PKIX thinking. Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 12 14:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irf3m-0004ON-6N; Mon, 12 Nov 2007 14:35:02 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Irf3l-0004OC-Jx for tls-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 14:35:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irf3l-0004O4-9Y for tls@ietf.org; Mon, 12 Nov 2007 14:35:01 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irf3k-00071H-U0 for tls@ietf.org; Mon, 12 Nov 2007 14:35:01 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 543C833C2B; Mon, 12 Nov 2007 11:11:15 -0800 (PST) Date: Mon, 12 Nov 2007 11:11:14 -0800 From: Eric Rescorla To: ietf-pkix@imc.org, tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071112191115.543C833C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [TLS] DSA/SHA-1, and OIDs 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 PKIX guys, As you probably know, in some modes of TLS one or the other party signs data. In some cases, this presumably means DSA. This is fine if you can guarantee that you are going to use SHA-1 with DSA, but obviously there's going to be a desire to transition to SHA-256, which raises the issue of digest substitution. My understanding of the current thinking on how to prevent this is to indicate in the certificate which digest algorithm is to be used with the cert. So, the rule we plan to promulgate in TLS is: OID 1 2 840 10040 4 1 MUST only be used with SHA-1. Future revisions of [PKIX] MAY define new object identifiers for DSA with other hash algorithms. I wanted to check that this is compatible with the current PKIX thinking. Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 13 01:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IroxE-0007Il-N5; Tue, 13 Nov 2007 01:08:56 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IroxC-0007HJ-Ur for tls-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 01:08:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IroxC-0007Go-4B for tls@ietf.org; Tue, 13 Nov 2007 01:08:54 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IroxB-0004GB-Gh for tls@ietf.org; Tue, 13 Nov 2007 01:08:53 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAD68iUY013508; Tue, 13 Nov 2007 08:08:50 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 08:08:47 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 08:08:47 +0200 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: Tue, 13 Nov 2007 08:08:46 +0200 Message-ID: In-Reply-To: <20071112170607.E6CDA33C2B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated TLS ID (certificate restrictions #57) Thread-Index: AcglTwPAN3Ur5GfeSI6NJS+oFomRcQAa2rRw References: <20071029214813.CD3DC33C3D@delta.rtfm.com> <20071112170607.E6CDA33C2B@delta.rtfm.com> From: To: X-OriginalArrivalTime: 13 Nov 2007 06:08:47.0064 (UTC) FILETIME=[A6FB0580:01C825BB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tls@ietf.org Subject: [TLS] RE: Updated TLS ID (certificate restrictions #57) 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: > > I think it would be simpler to specify the default behavior > > in one place, and not to make it ciphersuite-dependent. > > E.g. "if the client does not send signature_algorithms, > > behave as if rsa+sha1 had been sent". Or we could just require > > everyone to send signature_algorithms. >=20 > So, I see where you're going with this, but I'm concerned about > making it (say) RSA-SHA1 because that would potentially make > currently compliant configurations noncompliant (e.g., if you had=20 > a pure DSA-DH shop). There are currently *no* compliant TLS 1.2 configurations (early implementations of e.g. -04 draft won't be compatible with the next draft version anyway), and we aren't changing the behavior=20 when TLS 1.0/1.1 is negotiated. (And it doesn't have to be RSA-SHA1; but IMHO something along the lines "if the extension was not sent, behave as if XYZ had been sent" would be simpler than the current text.) > As for requiring signature_algorithms, I'm concerned about requring > extensions. I think we're getting close to the point where it's > definitely safe, but I'm not sure we're there yet. I'm not sure if we're at a point where it would be definitely safe to propose TLS 1.2 :-) (without automatic fallback to=20 SSLv3/TLS 1.0 if the negotation fails) But you won't get full signature algorithm agility without extensions anyway -- I just think we probably don't want to have a half-way solution (with extra complexity) for folks who don't want to use extensions. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 13 13:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0Yc-0002Mo-Ap; Tue, 13 Nov 2007 13:32:18 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Is0Ya-0002GT-Jn for tls-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:32:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0YZ-0002D5-Q2 for tls@ietf.org; Tue, 13 Nov 2007 13:32:15 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is0YZ-0001Vg-De for tls@ietf.org; Tue, 13 Nov 2007 13:32:15 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5898233C2B; Tue, 13 Nov 2007 10:27:25 -0800 (PST) Date: Tue, 13 Nov 2007 10:27:24 -0800 From: Eric Rescorla To: In-Reply-To: References: <20071029214813.CD3DC33C3D@delta.rtfm.com> <20071112170607.E6CDA33C2B@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113182725.5898233C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org Subject: [TLS] Re: Updated TLS ID (certificate restrictions #57) 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 At Tue, 13 Nov 2007 08:08:46 +0200, wrote: > > Eric Rescorla wrote: > > > > I think it would be simpler to specify the default behavior > > > in one place, and not to make it ciphersuite-dependent. > > > E.g. "if the client does not send signature_algorithms, > > > behave as if rsa+sha1 had been sent". Or we could just require > > > everyone to send signature_algorithms. > > > > So, I see where you're going with this, but I'm concerned about > > making it (say) RSA-SHA1 because that would potentially make > > currently compliant configurations noncompliant (e.g., if you had > > a pure DSA-DH shop). > > There are currently *no* compliant TLS 1.2 configurations (early > implementations of e.g. -04 draft won't be compatible with the > next draft version anyway), and we aren't changing the behavior > when TLS 1.0/1.1 is negotiated. > > (And it doesn't have to be RSA-SHA1; but IMHO something along > the lines "if the extension was not sent, behave as if XYZ had > been sent" would be simpler than the current text.) Sorry, what I mean is: If you have TLS 1.1 server with a DSS cert, then you can currently run DSS_DHE. It should be the case that if you switch to TLS 1.2, this continues to work, which means that the implied signature_algorithms need to permit DSA/SHA-1 in this case. So, I think the right thing is: assume that SHA-1 is permitted and that you can use whatever signature algorithm is specified in the cipher suite. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 14 03:55:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE1K-0007eW-B8; Wed, 14 Nov 2007 03:54:50 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IsE1J-0007bc-70 for tls-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 03:54:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE1D-0007NV-Mv for tls@ietf.org; Wed, 14 Nov 2007 03:54:43 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsE1D-0000Xl-4v for tls@ietf.org; Wed, 14 Nov 2007 03:54:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAE8seHI013663; Wed, 14 Nov 2007 10:54:40 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:54:30 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:54:29 +0200 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, 14 Nov 2007 10:54:19 +0200 Message-ID: In-Reply-To: <20071113182725.5898233C2B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated TLS ID (certificate restrictions #57) Thread-Index: AcgmI5CKtENjlG+ZT7KwaQdoigQmGgAdvMtw References: <20071029214813.CD3DC33C3D@delta.rtfm.com><20071112170607.E6CDA33C2B@delta.rtfm.com> <20071113182725.5898233C2B@delta.rtfm.com> From: To: X-OriginalArrivalTime: 14 Nov 2007 08:54:29.0984 (UTC) FILETIME=[F7D5F600:01C8269B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org Subject: [TLS] RE: Updated TLS ID (certificate restrictions #57) 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: > Sorry, what I mean is: If you have TLS 1.1 server with a DSS cert, > then you can currently run DSS_DHE. It should be the case that if > you switch to TLS 1.2, this continues to work, which means that the > implied signature_algorithms need to permit DSA/SHA-1 in this case. This means we'd have two different ways to specify supported signature algorithms: the extension and the cipher suite. IMHO this is unnecessarily complicated -- if you switch to TLS 1.2, your new implementation will simply have to support the extension. Otherwise, we have to specify how the two mechanisms interact. > So, I think the right thing is: assume that SHA-1 is permitted > and that you can use whatever signature algorithm is specified > in the cipher suite. Well... even in that case, I'd prefer describing this=20 as a default value for signature_algorithms extension in=20 Section 7.4.1.4.1 (rather than mixing this in with the certificate selection text). E.g. something along these lines: If the client does not send the signature_algorithms=20 extension, the server will assume the following: o If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA),=20 behave as if client had sent the value (sha1,rsa). =20 o If the negotiated key exchange algorithm is one of=20 (DHE_DSS, DH_DSS), behave as if the client had sent the value (sha1,dsa). o If the negotiated key exchnage algorithm is one of=20 (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). (BTW, the SignatureAlgorithm enum is missing "ecdsa"). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 16 10:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It36c-0001el-K3; Fri, 16 Nov 2007 10:27:42 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1It36b-0001dO-DI for tls-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:27:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It36b-0001cs-0y for tls@ietf.org; Fri, 16 Nov 2007 10:27:41 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It36a-00013n-Go for tls@ietf.org; Fri, 16 Nov 2007 10:27:40 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 16 Nov 2007 15:27:39 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 16 Nov 2007 15:27:39 +0000 From: Stefan Santesson To: Eric Rescorla , "ietf-pkix@imc.org" , "tls@ietf.org" Date: Fri, 16 Nov 2007 15:27:20 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcglYyixk89m+4dNQ8SjtdSWyP3DzwDAR28Q Message-ID: <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> In-Reply-To: <20071112191115.543C833C2B@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Not really. The OID 1 2 840 10040 4 1 identifies DSA only and is used in the subject pu= blic key info for declaring the DSA key. In FIPS 186-2 sha-1 was the only h= ash algorithm, but this is expanded in FIPS 186-3 The following OIDs are relevant >From RFC 3279: -- OID for DSA public key id-dsa OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } -- OID for DSA signature generated with SHA-1 hash id-dsa-with-sha1 OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } >From draft-ietf-pkix-sha2-dsa-ecdsa-01.txt id-dsa-with-sha224 OBJECT IDENTIFIER ::=3D { joint-iso- ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1} id-dsa-with-sha256 OBJECT IDENTIFIER ::=3D { joint-iso- ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1} Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 12 november 2007 20:11 > To: ietf-pkix@imc.org; tls@ietf.org > Subject: [TLS] DSA/SHA-1, and OIDs > > Hi PKIX guys, > > As you probably know, in some modes of TLS one or the other party > signs data. In some cases, this presumably means DSA. This is > fine if you can guarantee that you are going to use SHA-1 with > DSA, but obviously there's going to be a desire to transition > to SHA-256, which raises the issue of digest substitution. > > My understanding of the current thinking on how to prevent this > is to indicate in the certificate which digest algorithm is to > be used with the cert. So, the rule we plan to promulgate in TLS > is: > > OID 1 2 840 10040 4 1 MUST only be used with SHA-1. Future > revisions of [PKIX] MAY define new object identifiers for DSA > with other hash algorithms. > > I wanted to check that this is compatible with the current PKIX > thinking. > > Thanks, > -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 Fri Nov 16 11:10:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3ld-0002m1-KD; Fri, 16 Nov 2007 11:10:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1It3lc-0002k4-G1 for tls-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:10:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3lc-0002j2-18 for tls@ietf.org; Fri, 16 Nov 2007 11:10:04 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3lb-0005wu-3h for tls@ietf.org; Fri, 16 Nov 2007 11:10:03 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lAGG9hPM014303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Nov 2007 17:09:45 +0100 X-Hashcash: 1:22:071116:tls@ietf.org::n+uGInAftLv92MNf:9FJ3 From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Fri, 16 Nov 2007 17:09:42 +0100 Message-ID: <87r6iqgojd.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [TLS] Interoperability failure caused by CBC block cipher padding 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 Section 6.2.3.2 of RFC 4364 says: block-ciphered struct { opaque IV[CipherSpec.block_length]; opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; ... padding Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. The padding MAY be any length up to 255 bytes, as long as it results in the TLSCiphertext.length being an integral multiple of the block length. Lengths longer than necessary might be desirable to frustrate attacks on a protocol that are based on analysis of the lengths of exchanged messages. GnuTLS takes advantage of the wording, and uses longer padding than necessary. The pad length is determined randomly. The reason is to avoid statistical length-based analysis of short packets. Other common implementations (including OpenSSL) doesn't seem to implement similar precautions. GnuTLS' behavior appear to generate interop failures with some TLS client libraries, notably those in Nokia/Ericsson phones. For reference, see bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390712 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438137 I believe this part of the specification has changed since the SSL days, which did not permit unnecessarily long pads. Still, it seems clear that this is a problem in those TLS libraries rather than in GnuTLS. I also believe the feature is important. Have others run into this problem? Is there anything the specification can say to make implementers more aware of this problem? Would this be relevant for draft-ietf-tls-interoperability? (Btw, what's up with that document? It has expired.) If someone responsible for these implementation happens to read this, also consider fixing the bug. ;) /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 16 11:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It44z-0005hH-LX; Fri, 16 Nov 2007 11:30:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1It44y-0005fB-8S for tls-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:30:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It44x-0005ef-TV for tls@ietf.org; Fri, 16 Nov 2007 11:30:03 -0500 Received: from mail.gi-de.com ([193.108.184.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It44x-00084Y-DT for tls@ietf.org; Fri, 16 Nov 2007 11:30:03 -0500 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id D120HBHL outgoing id D120HBHL; 16 Nov 2007 17:30:01 +0100 In-Reply-To: <87r6iqgojd.fsf@mocca.josefsson.org> To: tls@ietf.org Subject: Antwort: [TLS] Interoperability failure caused by CBC block cipher padding MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Fri, 16 Nov 2007 17:32:39 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 16.11.2007 17:30:00, Serialize complete at 16.11.2007 17:30:00 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Simon Josefsson 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 Simon, > Have others run into this problem? I had similar toughts about this issue. My conclusion was that its best to accept any valid padding but never use to for sending data - except if the peer uses it first, becaue then we can assume peer supports this. Maybe adding a phrase like "implementations MUST support this" will calify one for all, that this is really mandatory for implementations when reading data. Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 16 12:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4aX-0000E9-0u; Fri, 16 Nov 2007 12:02:41 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1It4aW-0000Da-5L for tls-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 12:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4aV-0000Ca-RI for TLS@lists.ietf.org; Fri, 16 Nov 2007 12:02:39 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4aS-0004sl-00 for TLS@lists.ietf.org; Fri, 16 Nov 2007 12:02:39 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 16 Nov 2007 17:02:34 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 16 Nov 2007 17:02:34 +0000 From: Stefan Santesson To: "martin.rex@sap.com" , "TLS@lists.ietf.org" Date: Fri, 16 Nov 2007 17:02:15 +0000 Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Topic: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Index: AcghdcIhhnEsx7zhQ2KtzoYysg3F4QG+tX8Q Message-ID: <9F11911AED01D24BAA1C2355723C3D3223A32878@EA-EXMSG-C332.europe.corp.microsoft.com> References: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> In-Reply-To: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 As I disagree with the major part of this post, I had to go back to the spe= c to re-read what it actually states. There is nothing in the current text that says anything about how long chai= n the client should return. In fact the text is clearly written as if only = one certificate is sent. The terminology in 7.4.6 talks about "certificate"= and "the certificate" rather than certificates and certificate chains. 7.4.6 does not even make any reference to what structure that is used, even= if you can determine from other parts of the document that the structure i= s "Certificate" which allows a chain of certificates. What I find strange is the following text in 7.4.6 - If the certificate_authorities list in the certificate request message was non-empty, the certificate SHOULD be issued by one of the listed CAs. This makes no sense to me at all. If the list of CA DNs in certificate_auth= orities included a list of root CA names, why "SHOULD" the client certifica= te be issued directly by one of these roots? The functionality, as I see it implemented in practice, is simply that the = server provides a list of CA names. The client picks a certificate where th= at CA name is present anywhere in the selected client certificate chain. Th= e client then sends either just the client certificate or the whole chain (= with or without the root) to the server according to local policy. I also found another small nit in 7.4.4 In the following text: For example, if the server sends dss_fixed_dh certificate type and {dss_sha1, rsa_sha1} signature types, the client MAY _to_ reply with a certificate containing a static DH key, signed with RSA- SHA1. Remove "to" after MAY Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:Martin.Rex@sap.com] > Sent: den 7 november 2007 20:37 > To: TLS@lists.ietf.org > Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake > > I'm finally back at work and investigating a bug in the SSL client > certificate code of our OEM implementation and after reading > the current TLS v1.2 document it appears that the spec is still > unclear what implementations should do for multi-level CA hierarchies. > > The description of the "7.4.4. Certificate Request" handshake message > explicitly allows a TLS-Server to announce subordinate CAs > (which I think is useful), but I'm somewhat confused about what > a client is supposed or allowed to send as a certificate_list > (not where it starts, but where it ends), and what the server > is supposed to allow or allowed to / expected to reject. > I would appreciate guidance in the spec here. > > Scenario: > PKI with 3-level CA hierarchy for SSL client authentication: > RootCA, SubCA1, SubCA2, EndEntity(User) > > According to 7.4.4. the SSL server can send/include > any one possible subset of (RootCAs,SubCA1,SubCA2) as acceptable > certificate_authorities in the CertificateRequest message. > > Which "matching" certification authority the client implementation > depends on the clients search strategy and possibly the order of > the certification_authorities in the CertificateRequest message > of the server. > > IMHO, the most sensible approach would be for the server to > send Subordinate CAs names before their issuing CA names, > but for some SSL/TLS (server side) implementations it might > be difficult or impossible to configure a particular ordering, > but the client will always receive a particular order, be > it a side-effect of the server SSL/TLS implementation or > a conscious decision (aka preference list) of the servers admin. > > I'm not sure what would be the best approach for the client would > be to (a) search for the "most desirable" certification > authority, and whether it is allowed to send certificates > in the certificate_list of the ClientCertificate message > beyond the "matching" certification authority, in case > that matching certification authority was actually a > subordinate CA. > > Personally, I would consider it a client-side bug if the client > would send a CA certificate beyond the matched certification > authority from the CertificateRequest, _unless_ the server > explicitly announced this higher certification authority also > in the certification_authorities list of the CertificateRequest > message. > > Conceivable reasons why a client may not want to (or not be able to) > send a full path ending at a self-signed CA certificate > (and appreciate the server to announce subordinate CAs) might be > - size constraints of a crypto hardware token or device > (it may not store chain certs), > - bandwith savings for the ClientCertificate handshake message. > - reduced work for the server: it does not need to parse > and to process (even if processing just means comparing and > ignoring) > CA certs beyond a trusted subordinate CA > > >From how I read OpenSSL code (s3_both.c from 0.9.7g) I assume that > OpenSSL will unconditionally send all available path certificates > up to a self-signed (CA) cert. > > SSL clients sending unrequested/extra CA certs in the ClientCertificate > message will unnecessarily drain resources from the SSL server > (and preclude this small optimization from the server admin). > > > Opinions? > > -Martin > > > > _______________________________________________ > 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 Nov 17 04:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItJu6-00082Z-6h; Sat, 17 Nov 2007 04:23:54 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ItJu4-00080M-Um for tls-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 04:23:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItJu4-00080E-KP for tls@ietf.org; Sat, 17 Nov 2007 04:23:52 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItJu3-0007mb-Vp for tls@ietf.org; Sat, 17 Nov 2007 04:23:52 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lAH9NYQL013690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2007 10:23:35 +0100 From: Simon Josefsson To: Axel.Heider@gi-de.com References: <87r6iqgojd.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071117:tls@ietf.org::4Bg7bUEeKxCQhdUp:05iI X-Hashcash: 1:22:071117:axel.heider@gi-de.com::87aY0GIwiQs+1XMS:O2lY Date: Sat, 17 Nov 2007 10:23:34 +0100 In-Reply-To: (Axel Heider's message of "Fri, 16 Nov 2007 17:32:39 +0100") Message-ID: <877ikhgr8p.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org Subject: [TLS] Re: Antwort: Interoperability failure caused by CBC block cipher padding 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 Axel.Heider@gi-de.com writes: > Simon, >> Have others run into this problem? > > I had similar toughts about this issue. My conclusion > was that its best to accept any valid padding but never > use to for sending data - except if the peer uses it > first, becaue then we can assume peer supports this. If all implementations make that decision, the feature would never be used in practice. That leads to a normally unused code-path, which is often a poor idea security-wise. I do sympathize with your desire to maximize interoperability though. > Maybe adding a phrase like "implementations MUST support > this" will calify one for all, that this is really > mandatory for implementations when reading data. I would support that. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 17 09:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItOZD-0002KQ-5m; Sat, 17 Nov 2007 09:22:39 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ItOZC-0002Jh-9b for tls-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 09:22:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItOZB-0002Ib-Sv for tls@ietf.org; Sat, 17 Nov 2007 09:22:37 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItOZ8-0007RI-Fp for tls@ietf.org; Sat, 17 Nov 2007 09:22:37 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B445033C21; Sat, 17 Nov 2007 06:17:38 -0800 (PST) Date: Sat, 17 Nov 2007 06:17:38 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071117141738.B445033C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "ietf-pkix@imc.org" , "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 At Fri, 16 Nov 2007 15:27:20 +0000, Stefan Santesson wrote: > > The OID 1 2 840 10040 4 1 identifies DSA only and is used in the subject public key info for declaring the DSA key. In FIPS 186-2 sha-1 was the only hash algorithm, but this is expanded in FIPS 186-3 > > The following OIDs are relevant > > >From RFC 3279: > > -- OID for DSA public key > id-dsa OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } > > -- OID for DSA signature generated with SHA-1 hash > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 } > > > >From draft-ietf-pkix-sha2-dsa-ecdsa-01.txt > > id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso- > ccitt(2) country(16) us(840) organization(1) gov(101) > csor(3) algorithms(4) id-dsa-with-sha2(3) 1} > > id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso- > ccitt(2) country(16) us(840) organization(1) gov(101) > csor(3) algorithms(4) id-dsa-with-sha2(3) 1} Stefan, Maybe it's worth upleveling a bit. My claim is that for security reasons it's necessary for DSA certs to indicate the hash algorithm(s) that may be used with the cert. This prevents hash algorithm substitution in the signature. Do you agree with this? If so, then it becomes a question of encoding this information in the cert. I'm not a PKIX expert and don't have an opinion about how it should be encoded except that: 1. Current certificates must obviously be usable with at least SHA-1. 2. There must be a way for future certificates to rule out SHA-1. How does PKIX propose to solve this? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 18 14:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itpeg-00007l-Vh; Sun, 18 Nov 2007 14:18:06 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Itpeg-00006m-4M for tls-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 14:18:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itpef-00006d-QN for tls@ietf.org; Sun, 18 Nov 2007 14:18:05 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itpef-0000mN-Gx for tls@ietf.org; Sun, 18 Nov 2007 14:18:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C94FA33C2B for ; Sun, 18 Nov 2007 11:13:06 -0800 (PST) Date: Sun, 18 Nov 2007 11:13:06 -0800 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071118191306.C94FA33C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [TLS] New TLS version 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 A new version of TLS 1.2 can be found at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt Here is the (modest) change list: - SSLv2 backward compatibility downgraded to MAY - Altered DSA hash rules to more closely match FIPS186-3 and PKIX, plus remove OID restriction. - verify_length no longer in SecurityParameters - Moved/cleaned up cert selection text for server cert when signature_algorithms is not specified. - Other editorial changes. All open issues I know of are now closed. I believe that this document is ready for WGLC. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 03:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu254-0003Ua-0k; Mon, 19 Nov 2007 03:34:10 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iu252-0003UP-QA for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 03:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu24x-0003Tc-4u for tls@ietf.org; Mon, 19 Nov 2007 03:34:03 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu24u-0007hu-GR for tls@ietf.org; Mon, 19 Nov 2007 03:34:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAJ8Xktq003398; Mon, 19 Nov 2007 10:33:58 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:33:57 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:33:56 +0200 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] Interoperability failure caused by CBC block cipher padding Date: Mon, 19 Nov 2007 10:33:56 +0200 Message-ID: In-Reply-To: <87r6iqgojd.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Interoperability failure caused by CBC block cipher padding Thread-Index: AcgoazhO31Fg1AQBRX+9tFeLEIYJ8wCGhxsg References: <87r6iqgojd.fsf@mocca.josefsson.org> From: To: , X-OriginalArrivalTime: 19 Nov 2007 08:33:56.0800 (UTC) FILETIME=[ECDDC400:01C82A86] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 A while ago, I did some testing on how implementations handled this, and presented the results in IETF67. See: http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld8.htm=20 http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld9.htm Basically, most implementations seemed to handle this OK. Perhaps we could add this to the "implementation pitfalls" section, though. (I will also try to report this bug to the people responsible for fixing this.) Best regards, Pasi > -----Original Message----- > From: ext Simon Josefsson [mailto:simon@josefsson.org]=20 > Sent: 16 November, 2007 18:10 > To: tls@ietf.org > Subject: [TLS] Interoperability failure caused by CBC block=20 > cipher padding >=20 > Section 6.2.3.2 of RFC 4364 says: >=20 > block-ciphered struct { > opaque IV[CipherSpec.block_length]; > opaque content[TLSCompressed.length]; > opaque MAC[CipherSpec.hash_size]; > uint8 padding[GenericBlockCipher.padding_length]; > uint8 padding_length; > } GenericBlockCipher; > ... > padding > Padding that is added to force the length of the plaintext to be > an integral multiple of the block cipher's block length. The > padding MAY be any length up to 255 bytes, as long as it results > in the TLSCiphertext.length being an integral multiple of the > block length. Lengths longer than necessary might be=20 > desirable to > frustrate attacks on a protocol that are based on=20 > analysis of the > lengths of exchanged messages. >=20 > GnuTLS takes advantage of the wording, and uses longer padding than > necessary. The pad length is determined randomly. The reason is to > avoid statistical length-based analysis of short packets. =20 > Other common > implementations (including OpenSSL) doesn't seem to implement similar > precautions. >=20 > GnuTLS' behavior appear to generate interop failures with some TLS > client libraries, notably those in Nokia/Ericsson phones. For > reference, see bug reports: >=20 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D390712 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D402861 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D438137 >=20 > I believe this part of the specification has changed since=20 > the SSL days, > which did not permit unnecessarily long pads. Still, it seems clear > that this is a problem in those TLS libraries rather than in=20 > GnuTLS. I > also believe the feature is important. >=20 > Have others run into this problem? >=20 > Is there anything the specification can say to make implementers more > aware of this problem? >=20 > Would this be relevant for draft-ietf-tls-interoperability? > (Btw, what's up with that document? It has expired.) >=20 > If someone responsible for these implementation happens to read this, > also consider fixing the bug. ;) >=20 > /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 03:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Tp-0003P2-4e; Mon, 19 Nov 2007 03:59:45 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iu2Tn-0003O2-PL for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 03:59:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Tn-0003Ne-F4 for TLS@lists.ietf.org; Mon, 19 Nov 2007 03:59:43 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu2Tk-0001l9-8Z for TLS@lists.ietf.org; Mon, 19 Nov 2007 03:59:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAJ8xPbg020617; Mon, 19 Nov 2007 10:59:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:59:37 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 10:59:37 +0200 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] CAs and certificate chains in the SSL/TLS handshake Date: Mon, 19 Nov 2007 10:59:36 +0200 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223A32878@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Index: AcghdcIhhnEsx7zhQ2KtzoYysg3F4QG+tX8QAIZGtxA= References: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D3223A32878@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 19 Nov 2007 08:59:37.0089 (UTC) FILETIME=[82F33710:01C82A8A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 7.4.6 does not describe the structure, because the structure has been already described, and it's not repeated there. The description is pretty clear that a chain be sent: certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. But there is indeed some text in e.g. 7.4.6 that incorrectly talks about just "the certificate", when it means "the certificate plus possibly intermediate parts of the chain". I'll see that these get fixed during WGLC... Best regards, Pasi > -----Original Message----- > From: ext Stefan Santesson [mailto:stefans@microsoft.com]=20 > Sent: 16 November, 2007 19:02 > To: martin.rex@sap.com; TLS@lists.ietf.org > Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS handshake >=20 > As I disagree with the major part of this post, I had to go=20 > back to the spec to re-read what it actually states. >=20 > There is nothing in the current text that says anything about=20 > how long chain the client should return. In fact the text is=20 > clearly written as if only one certificate is sent. The=20 > terminology in 7.4.6 talks about "certificate" and "the=20 > certificate" rather than certificates and certificate chains. >=20 > 7.4.6 does not even make any reference to what structure that=20 > is used, even if you can determine from other parts of the=20 > document that the structure is "Certificate" which allows a=20 > chain of certificates. >=20 > What I find strange is the following text in 7.4.6 >=20 > - If the certificate_authorities list in the certificate > request message was non-empty, the certificate SHOULD be > issued by one of the listed CAs. >=20 > This makes no sense to me at all. If the list of CA DNs in=20 > certificate_authorities included a list of root CA names, why=20 > "SHOULD" the client certificate be issued directly by one of=20 > these roots? >=20 > The functionality, as I see it implemented in practice, is=20 > simply that the server provides a list of CA names. The=20 > client picks a certificate where that CA name is present=20 > anywhere in the selected client certificate chain. The client=20 > then sends either just the client certificate or the whole=20 > chain (with or without the root) to the server according to=20 > local policy. >=20 >=20 > I also found another small nit in 7.4.4 >=20 > In the following text: >=20 > For > example, if the server sends dss_fixed_dh certificate type and > {dss_sha1, rsa_sha1} signature types, the client MAY _to_ reply > with a certificate containing a static DH key, signed with RSA- > SHA1. >=20 > Remove "to" after MAY >=20 >=20 > Stefan Santesson > Senior Program Manager > Windows Security, Standards >=20 >=20 > > -----Original Message----- > > From: Martin Rex [mailto:Martin.Rex@sap.com] > > Sent: den 7 november 2007 20:37 > > To: TLS@lists.ietf.org > > Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake > > > > I'm finally back at work and investigating a bug in the SSL client > > certificate code of our OEM implementation and after reading > > the current TLS v1.2 document it appears that the spec is still > > unclear what implementations should do for multi-level CA=20 > hierarchies. > > > > The description of the "7.4.4. Certificate Request"=20 > handshake message > > explicitly allows a TLS-Server to announce subordinate CAs > > (which I think is useful), but I'm somewhat confused about what > > a client is supposed or allowed to send as a certificate_list > > (not where it starts, but where it ends), and what the server > > is supposed to allow or allowed to / expected to reject. > > I would appreciate guidance in the spec here. > > > > Scenario: > > PKI with 3-level CA hierarchy for SSL client authentication: > > RootCA, SubCA1, SubCA2, EndEntity(User) > > > > According to 7.4.4. the SSL server can send/include > > any one possible subset of (RootCAs,SubCA1,SubCA2) as acceptable > > certificate_authorities in the CertificateRequest message. > > > > Which "matching" certification authority the client implementation > > depends on the clients search strategy and possibly the order of > > the certification_authorities in the CertificateRequest message > > of the server. > > > > IMHO, the most sensible approach would be for the server to > > send Subordinate CAs names before their issuing CA names, > > but for some SSL/TLS (server side) implementations it might > > be difficult or impossible to configure a particular ordering, > > but the client will always receive a particular order, be > > it a side-effect of the server SSL/TLS implementation or > > a conscious decision (aka preference list) of the servers admin. > > > > I'm not sure what would be the best approach for the client would > > be to (a) search for the "most desirable" certification > > authority, and whether it is allowed to send certificates > > in the certificate_list of the ClientCertificate message > > beyond the "matching" certification authority, in case > > that matching certification authority was actually a > > subordinate CA. > > > > Personally, I would consider it a client-side bug if the client > > would send a CA certificate beyond the matched certification > > authority from the CertificateRequest, _unless_ the server > > explicitly announced this higher certification authority also > > in the certification_authorities list of the CertificateRequest > > message. > > > > Conceivable reasons why a client may not want to (or not be able to) > > send a full path ending at a self-signed CA certificate > > (and appreciate the server to announce subordinate CAs) might be > > - size constraints of a crypto hardware token or device > > (it may not store chain certs), > > - bandwith savings for the ClientCertificate handshake message. > > - reduced work for the server: it does not need to parse > > and to process (even if processing just means comparing and > > ignoring) > > CA certs beyond a trusted subordinate CA > > > > >From how I read OpenSSL code (s3_both.c from 0.9.7g) I assume that > > OpenSSL will unconditionally send all available path certificates > > up to a self-signed (CA) cert. > > > > SSL clients sending unrequested/extra CA certs in the=20 > ClientCertificate > > message will unnecessarily drain resources from the SSL server > > (and preclude this small optimization from the server admin). > > > > > > Opinions? > > > > -Martin > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 04:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2ZT-0005iv-Cv; Mon, 19 Nov 2007 04:05:35 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iu2ZR-0005ij-L6 for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 04:05:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2ZR-0005ib-BV for tls@ietf.org; Mon, 19 Nov 2007 04:05:33 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu2ZN-0002Lt-SG for tls@ietf.org; Mon, 19 Nov 2007 04:05:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAJ94c2Z029105 for ; Mon, 19 Nov 2007 11:05:27 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:03:59 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:03:57 +0200 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: Mon, 19 Nov 2007 11:03:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for agenda items Thread-Index: Acgqix3SisJcDvu7TlClF5uLom97Lg== From: To: X-OriginalArrivalTime: 19 Nov 2007 09:03:57.0223 (UTC) FILETIME=[1E008370:01C82A8B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Call for agenda items 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 TLS WG is scheduled to meet on Monday 0900-1130 (subject to change,=20 as usual). This is a call for agenda items. Please send them to me=20 and Eric as soon as possible (preliminary agendas are due this Wednesday). Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 11:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9rh-0000sc-Pt; Mon, 19 Nov 2007 11:52:53 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iu9rg-0000k6-HL for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:52:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9rg-0000d8-07 for tls@ietf.org; Mon, 19 Nov 2007 11:52:52 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu9rf-0007Wy-Jo for tls@ietf.org; Mon, 19 Nov 2007 11:52:51 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8147233C2B; Mon, 19 Nov 2007 08:47:54 -0800 (PST) Date: Mon, 19 Nov 2007 08:47:53 -0800 From: Eric Rescorla To: Stephen Kent Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: References: <20071112191115.543C833C2B@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071119164754.8147233C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "ietf-pkix@imc.org" , "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 At Mon, 19 Nov 2007 11:35:47 -0500, Stephen Kent wrote: > > Eric, > > Your question was: > My claim is that for security reasons it's necessary for DSA certs > to indicate the hash algorithm(s) that may be used with the cert. > This prevents hash algorithm substitution in the signature. > Do you agree with this? > > The wording here strikes me as a bit odd. The hash algorithm used to > verify a cert IS specified in the cert, in the SignatureAlgorithm > field. > > The hash algorithm(s) that may be used with the public KEY in the > cert are not specified, in general, as the key may be used to verify > signatures for certs or for other signed objects (in the case of EE > certs). I agree my wording was imprecise. Let me rephrase: My claim is that for security reasons it's necessary for DSA certs to indicate the hash algorithm(s) that may be used with the public key contained in the cert. This prevents hash algorithm substitution in signatures formed with that key (or rather the private key that corresponds to that key). Do you agree with this? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 13:39:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBX9-0006cC-D8; Mon, 19 Nov 2007 13:39:47 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuBX7-0006by-UI for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:39:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBX7-0006bU-K8 for tls@ietf.org; Mon, 19 Nov 2007 13:39:45 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBX4-0002iI-0z for tls@ietf.org; Mon, 19 Nov 2007 13:39:45 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 19 Nov 2007 18:39:41 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Mon, 19 Nov 2007 18:39:41 +0000 From: Stefan Santesson To: Eric Rescorla , Stephen Kent Date: Mon, 19 Nov 2007 18:39:00 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgqzKXJLLPnSoYjSlyrf9YbiBN5gAADC46A Message-ID: <9F11911AED01D24BAA1C2355723C3D3223A32C93@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> In-Reply-To: <20071119164754.8147233C2B@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "ietf-pkix@imc.org" , "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 First a small technicality. I copied the OID from the ASN'1 section of the draft. Someone pointed out to me that the two OIDs were identical. So here are the= correct OIDs -- -- DSA with SHA-224 and SHA-256 signature algorithms -- dsa-with-sha224 OBJECT IDENTIFIER ::=3D { joint-iso- ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1} dsa-with-sha256 OBJECT IDENTIFIER ::=3D { joint-iso- ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 2} On the subject I have a clear opinion and that is an absolute no to do this= through subject public key info. The subject public key info is a core field of a certificate and it has a d= efined meaning to provide the key and its parameters. In addition to this t= he field also supplies an identifier of the key which identifies the key an= d parameter structure and syntax so it can be parsed. All X.509 software an= d systems using X.509 built to this date that I know of is designed to use = the field exclusively in this manner. In general, it is the responsibility of the protocol to limit the algorithm= s used, not the public key certificate. When limitations are specified in t= he certificate this is guidance for the applications using it. Except for a= few core restrictions defined in path validation, it is nothing that will = be enforced on the crypto API level. ANSI has made attempts to defined expa= nded restrictions in the subject public key field for ECC algorithm modes a= nd this is exactly the type of complexity and change in field usage we don'= t need in X.509. Especially since nobody has defined where in the system ar= chitecture these restrictions should be enforced (protocol level, applicati= on level or crypto library level where keys are stored and used). Conclusion is. Any new types of usage restrictions must be provided in a ne= w field. i.e. in a certificate extension and it must be understood that thi= s serves as information to the relying party on when it is appropriate to u= se this certificate. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 19 november 2007 17:48 > To: Stephen Kent > Cc: Eric Rescorla; Stefan Santesson; ietf-pkix@imc.org; tls@ietf.org > Subject: Re: [TLS] DSA/SHA-1, and OIDs > > At Mon, 19 Nov 2007 11:35:47 -0500, > Stephen Kent wrote: > > > > Eric, > > > > Your question was: > > My claim is that for security reasons it's necessary for DSA > certs > > to indicate the hash algorithm(s) that may be used with the > cert. > > This prevents hash algorithm substitution in the signature. > > Do you agree with this? > > > > The wording here strikes me as a bit odd. The hash algorithm used to > > verify a cert IS specified in the cert, in the SignatureAlgorithm > > field. > > > > The hash algorithm(s) that may be used with the public KEY in the > > cert are not specified, in general, as the key may be used to verify > > signatures for certs or for other signed objects (in the case of EE > > certs). > > I agree my wording was imprecise. Let me rephrase: > > My claim is that for security reasons it's necessary for DSA > certs to indicate the hash algorithm(s) that may be used with > the public key contained in the cert. This prevents hash > algorithm substitution in signatures formed with that key > (or rather the private key that corresponds to that key). Do > you agree with this? > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 13:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBb1-00042C-O8; Mon, 19 Nov 2007 13:43:47 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuBaz-00041z-Ph for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBaz-00041q-G3 for TLS@lists.ietf.org; Mon, 19 Nov 2007 13:43:45 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBav-0003CS-GA for TLS@lists.ietf.org; Mon, 19 Nov 2007 13:43:45 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 19 Nov 2007 18:43:40 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Mon, 19 Nov 2007 18:43:40 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "TLS@lists.ietf.org" Date: Mon, 19 Nov 2007 18:42:24 +0000 Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Topic: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Index: AcghdcIhhnEsx7zhQ2KtzoYysg3F4QG+tX8QAIZGtxAAFHvhQA== Message-ID: <9F11911AED01D24BAA1C2355723C3D3223A32C96@EA-EXMSG-C332.europe.corp.microsoft.com> References: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D3223A32878@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 Pasi, I know that the structure for certificates is defined. I was just surprised= that this section didn't even mention it. I know that many use standards a= s dictionaries rather than novels (they don't read them from page 1 to the = end). So some kind of hint where the structure is defined would not hurt. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 19 november 2007 10:00 > To: Stefan Santesson; TLS@lists.ietf.org > Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS handshake > > > 7.4.6 does not describe the structure, because the structure > has been already described, and it's not repeated there. > The description is pretty clear that a chain be sent: > > certificate_list > > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding > it. Because certificate validation requires that root keys > be distributed independently, the self-signed certificate > that specifies the root certificate authority MAY optionally > be omitted from the chain, under the assumption that the > remote end must already possess it in order to validate it > in any case. > > But there is indeed some text in e.g. 7.4.6 that incorrectly > talks about just "the certificate", when it means "the certificate > plus possibly intermediate parts of the chain". I'll see > that these get fixed during WGLC... > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Stefan Santesson [mailto:stefans@microsoft.com] > > Sent: 16 November, 2007 19:02 > > To: martin.rex@sap.com; TLS@lists.ietf.org > > Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS > handshake > > > > As I disagree with the major part of this post, I had to go > > back to the spec to re-read what it actually states. > > > > There is nothing in the current text that says anything about > > how long chain the client should return. In fact the text is > > clearly written as if only one certificate is sent. The > > terminology in 7.4.6 talks about "certificate" and "the > > certificate" rather than certificates and certificate chains. > > > > 7.4.6 does not even make any reference to what structure that > > is used, even if you can determine from other parts of the > > document that the structure is "Certificate" which allows a > > chain of certificates. > > > > What I find strange is the following text in 7.4.6 > > > > - If the certificate_authorities list in the certificate > > request message was non-empty, the certificate SHOULD be > > issued by one of the listed CAs. > > > > This makes no sense to me at all. If the list of CA DNs in > > certificate_authorities included a list of root CA names, why > > "SHOULD" the client certificate be issued directly by one of > > these roots? > > > > The functionality, as I see it implemented in practice, is > > simply that the server provides a list of CA names. The > > client picks a certificate where that CA name is present > > anywhere in the selected client certificate chain. The client > > then sends either just the client certificate or the whole > > chain (with or without the root) to the server according to > > local policy. > > > > > > I also found another small nit in 7.4.4 > > > > In the following text: > > > > For > > example, if the server sends dss_fixed_dh certificate type and > > {dss_sha1, rsa_sha1} signature types, the client MAY _to_ > reply > > with a certificate containing a static DH key, signed with > RSA- > > SHA1. > > > > Remove "to" after MAY > > > > > > Stefan Santesson > > Senior Program Manager > > Windows Security, Standards > > > > > > > -----Original Message----- > > > From: Martin Rex [mailto:Martin.Rex@sap.com] > > > Sent: den 7 november 2007 20:37 > > > To: TLS@lists.ietf.org > > > Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake > > > > > > I'm finally back at work and investigating a bug in the SSL client > > > certificate code of our OEM implementation and after reading > > > the current TLS v1.2 document it appears that the spec is still > > > unclear what implementations should do for multi-level CA > > hierarchies. > > > > > > The description of the "7.4.4. Certificate Request" > > handshake message > > > explicitly allows a TLS-Server to announce subordinate CAs > > > (which I think is useful), but I'm somewhat confused about what > > > a client is supposed or allowed to send as a certificate_list > > > (not where it starts, but where it ends), and what the server > > > is supposed to allow or allowed to / expected to reject. > > > I would appreciate guidance in the spec here. > > > > > > Scenario: > > > PKI with 3-level CA hierarchy for SSL client authentication: > > > RootCA, SubCA1, SubCA2, EndEntity(User) > > > > > > According to 7.4.4. the SSL server can send/include > > > any one possible subset of (RootCAs,SubCA1,SubCA2) as acceptable > > > certificate_authorities in the CertificateRequest message. > > > > > > Which "matching" certification authority the client implementation > > > depends on the clients search strategy and possibly the order of > > > the certification_authorities in the CertificateRequest message > > > of the server. > > > > > > IMHO, the most sensible approach would be for the server to > > > send Subordinate CAs names before their issuing CA names, > > > but for some SSL/TLS (server side) implementations it might > > > be difficult or impossible to configure a particular ordering, > > > but the client will always receive a particular order, be > > > it a side-effect of the server SSL/TLS implementation or > > > a conscious decision (aka preference list) of the servers admin. > > > > > > I'm not sure what would be the best approach for the client would > > > be to (a) search for the "most desirable" certification > > > authority, and whether it is allowed to send certificates > > > in the certificate_list of the ClientCertificate message > > > beyond the "matching" certification authority, in case > > > that matching certification authority was actually a > > > subordinate CA. > > > > > > Personally, I would consider it a client-side bug if the client > > > would send a CA certificate beyond the matched certification > > > authority from the CertificateRequest, _unless_ the server > > > explicitly announced this higher certification authority also > > > in the certification_authorities list of the CertificateRequest > > > message. > > > > > > Conceivable reasons why a client may not want to (or not be able > to) > > > send a full path ending at a self-signed CA certificate > > > (and appreciate the server to announce subordinate CAs) might be > > > - size constraints of a crypto hardware token or device > > > (it may not store chain certs), > > > - bandwith savings for the ClientCertificate handshake message. > > > - reduced work for the server: it does not need to parse > > > and to process (even if processing just means comparing and > > > ignoring) > > > CA certs beyond a trusted subordinate CA > > > > > > >From how I read OpenSSL code (s3_both.c from 0.9.7g) I assume that > > > OpenSSL will unconditionally send all available path certificates > > > up to a self-signed (CA) cert. > > > > > > SSL clients sending unrequested/extra CA certs in the > > ClientCertificate > > > message will unnecessarily drain resources from the SSL server > > > (and preclude this small optimization from the server admin). > > > > > > > > > Opinions? > > > > > > -Martin > > > > > > > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 14:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC2P-0003ge-B6; Mon, 19 Nov 2007 14:12:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuC2O-0003Ui-8n for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC2N-0003P4-Gq for tls@ietf.org; Mon, 19 Nov 2007 14:12:03 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuC2K-0005r1-3r for tls@ietf.org; Mon, 19 Nov 2007 14:12:03 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 800F233C2B; Mon, 19 Nov 2007 11:07:03 -0800 (PST) Date: Mon, 19 Nov 2007 11:07:03 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223A32C93@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223A32C93@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071119190703.800F233C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "ietf-pkix@imc.org" , "tls@ietf.org" , Stephen Kent 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 At Mon, 19 Nov 2007 18:39:00 +0000, Stefan Santesson wrote: > On the subject I have a clear opinion and that is an absolute no to > do this through subject public key info. > > The subject public key info is a core field of a certificate and it > has a defined meaning to provide the key and its parameters. In > addition to this the field also supplies an identifier of the key > which identifies the key and parameter structure and syntax so it > can be parsed. All X.509 software and systems using X.509 built to > this date that I know of is designed to use the field exclusively in > this manner. OK. > In general, it is the responsibility of the protocol to limit the > algorithms used, not the public key certificate. This seems problematic: the issue here is downgrade attack. The relying party has support for a variety of digest algorithms and if there's no indication in the certificate of which digests will be used, then essentially an attacker can attack the weakest one. > When limitations > are specified in the certificate this is guidance for the > applications using it. Except for a few core restrictions defined in > path validation, it is nothing that will be enforced on the crypto > API level. ANSI has made attempts to defined expanded restrictions > in the subject public key field for ECC algorithm modes and this is > exactly the type of complexity and change in field usage we don't > need in X.509. Especially since nobody has defined where in the > system architecture these restrictions should be enforced (protocol > level, application level or crypto library level where keys are > stored and used). > > Conclusion is. Any new types of usage restrictions must be provided > in a new field. i.e. in a certificate extension and it must be > understood that this serves as information to the relying party on > when it is appropriate to use this certificate. OK well, I don't have a problem with it being in a new field, or that it's for the information of the relying party, but for the reasons I argue above, I think it needs to be uniform for all protocols and needs to be in the cert. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 19 18:24:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFyF-0002Q3-0P; Mon, 19 Nov 2007 18:24:03 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuFyD-0002M9-B2 for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 18:24:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFyC-0002L3-25; Mon, 19 Nov 2007 18:24:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuFyB-00071Z-Iy; Mon, 19 Nov 2007 18:23:59 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJNNvKc033798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 16:23:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 19 Nov 2007 15:23:13 -0800 To: ipsec@ietf.org, ietf-smime@imc.org, tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [TLS] Fwd: Document Action: 'Additional Diffie-Hellman Groups for use with IETF Standards' to Informational RFC 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 IESG has approved the following document: > >- 'Additional Diffie-Hellman Groups for use with IETF Standards ' > as an Informational RFC > >This document has been reviewed in the IETF but is not the product of an >IETF Working Group. > >The IESG contact person is Tim Polk. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-03.txt > >Technical Summary > >This document specifies (eight) Diffie-Hellman groups for use with >security protocols developed by five different IETF WGs (IPsec, PKIX, >S/MIME, SSH, SSL, and TLS). The specified groups include three >modular exponentiation groups and five elliptic curve groups. Several >of the Diffie-Hellman groups specified in this draft are already >defined in WG-specific RFCs (e.g., RFC 3526 and RFC 4753) and I-Ds, >but without the test data provided here. The group definitions and >test data are derived from a NIST document that is available only >on the NIST web site as a PDF. This draft translates the parameter >terminology from the with NIST document into a form consistent with >RFCs that define Diffie-Hellman groups (in protocol-specific contexts), >and removes extraneous test data that would not be relevant to IETF >protocols. > >Working Group Summary > >This document was not the product of any working group, but has been >reviewed by experts from several relevant wgs. Specifically, this >document >incorporates comments from: Tero Kivinen, the designated >approver of additional Diffie-Hellman groups for IKE; Sean >Turner S/MIME WG co-chair; and Pasi Eronen (TLS WG co-chair). Steve >Kent (PKIX co-chair) is a co-author of this document and he ensured >that PKIX concerns were addressed. No input was solicited form the >SSH WG co-chairs, as that protocol provides a trivial means of >accommodating additional (mod p) Diffie-Hellman groups. SSH provides >no means of accommodating Elliptic Curve Diffie-Hellman groups, and >as a result, the document is silent on use of Elliptic Curve >Diffie-Hellman groups with SSH. (There is an expired I-D that >describes how to use Elliptic Curve Diffie-Hellman with SSH. If it >is re-submitted and adopted by the SSH WG, it would be appropriate >to amend this draft to include it as well.) > >Protocol Quality > >Tim Polk reviewed this specification for the IESG. Larry Bassham, who >drafted the base NIST document, has also reviewed the specification. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR2v-0006fj-BL; Tue, 20 Nov 2007 06:13:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuCny-0004Jq-8b for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:01:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCnx-0004Je-UJ for tls@ietf.org; Mon, 19 Nov 2007 15:01:13 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCns-0000gA-Nm for tls@ietf.org; Mon, 19 Nov 2007 15:01:13 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IuCnq-0007Rr-3z; Mon, 19 Nov 2007 15:01:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20071119164754.8147233C2B@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> Date: Mon, 19 Nov 2007 15:01:07 -0500 To: Eric Rescorla From: Stephen Kent Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Tue, 20 Nov 2007 06:13:35 -0500 Cc: "ietf-pkix@imc.org" , "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 At 8:47 AM -0800 11/19/07, Eric Rescorla wrote: >At Mon, 19 Nov 2007 11:35:47 -0500, >Stephen Kent wrote: >> >> Eric, >> >> Your question was: >> My claim is that for security reasons it's necessary for DSA certs >> to indicate the hash algorithm(s) that may be used with the cert. >> This prevents hash algorithm substitution in the signature. >> Do you agree with this? >> >> The wording here strikes me as a bit odd. The hash algorithm used to >> verify a cert IS specified in the cert, in the SignatureAlgorithm >> field. >> >> The hash algorithm(s) that may be used with the public KEY in the >> cert are not specified, in general, as the key may be used to verify >> signatures for certs or for other signed objects (in the case of EE >> certs). > >I agree my wording was imprecise. Let me rephrase: > > My claim is that for security reasons it's necessary for DSA > certs to indicate the hash algorithm(s) that may be used with > the public key contained in the cert. This prevents hash > algorithm substitution in signatures formed with that key > (or rather the private key that corresponds to that key). Do > you agree with this? > >-Ekr OK, that is clearer. While I do see some benefits to being able to specify a has algorithm to use with a public key and algorithm specified in a cert, I agree with Stefan that the SubjectPublicKeyInfo field is NOT the place to do this, given the history of how this field is used and the peripheral nature of the info you want to specify. I think it would be best to create a new extension that one could use for this purpose, like the extension created for S/MIME to express the symmetric algorithm(s) supported by a recipient of encrypted messages. Steve _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov From tls-bounces@lists.ietf.org Tue Nov 20 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR2v-0006fj-BL; Tue, 20 Nov 2007 06:13:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuCny-0004Jq-8b for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:01:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCnx-0004Je-UJ for tls@ietf.org; Mon, 19 Nov 2007 15:01:13 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCns-0000gA-Nm for tls@ietf.org; Mon, 19 Nov 2007 15:01:13 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IuCnq-0007Rr-3z; Mon, 19 Nov 2007 15:01:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20071119164754.8147233C2B@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> Date: Mon, 19 Nov 2007 15:01:07 -0500 To: Eric Rescorla From: Stephen Kent Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Tue, 20 Nov 2007 06:13:35 -0500 Cc: "ietf-pkix@imc.org" , "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 At 8:47 AM -0800 11/19/07, Eric Rescorla wrote: >At Mon, 19 Nov 2007 11:35:47 -0500, >Stephen Kent wrote: >> >> Eric, >> >> Your question was: >> My claim is that for security reasons it's necessary for DSA certs >> to indicate the hash algorithm(s) that may be used with the cert. >> This prevents hash algorithm substitution in the signature. >> Do you agree with this? >> >> The wording here strikes me as a bit odd. The hash algorithm used to >> verify a cert IS specified in the cert, in the SignatureAlgorithm >> field. >> >> The hash algorithm(s) that may be used with the public KEY in the >> cert are not specified, in general, as the key may be used to verify >> signatures for certs or for other signed objects (in the case of EE >> certs). > >I agree my wording was imprecise. Let me rephrase: > > My claim is that for security reasons it's necessary for DSA > certs to indicate the hash algorithm(s) that may be used with > the public key contained in the cert. This prevents hash > algorithm substitution in signatures formed with that key > (or rather the private key that corresponds to that key). Do > you agree with this? > >-Ekr OK, that is clearer. While I do see some benefits to being able to specify a has algorithm to use with a public key and algorithm specified in a cert, I agree with Stefan that the SubjectPublicKeyInfo field is NOT the place to do this, given the history of how this field is used and the peripheral nature of the info you want to specify. I think it would be best to create a new extension that one could use for this purpose, like the extension created for S/MIME to express the symmetric algorithm(s) supported by a recipient of encrypted messages. Steve _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR2v-0006fo-I0; Tue, 20 Nov 2007 06:13:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuIgY-0004Lz-3Q for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:17:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIgX-0004Lq-Ob for tls@ietf.org; Mon, 19 Nov 2007 21:17:57 -0500 Received: from mailipbo.ntcif.telstra.com.au ([202.12.233.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuIgX-0002vP-3P for tls@ietf.org; Mon, 19 Nov 2007 21:17:57 -0500 Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 20 Nov 2007 13:17:54 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 525CAFF85; Tue, 20 Nov 2007 13:17:54 +1100 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA20036; Tue, 20 Nov 2007 13:17:53 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:17:53 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] DSA/SHA-1, and OIDs Date: Tue, 20 Nov 2007 13:17:50 +1100 Message-ID: <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <20071119164754.8147233C2B@delta.rtfm.com> Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBA References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> From: "Manger, James H" To: , X-OriginalArrivalTime: 20 Nov 2007 02:17:53.0002 (UTC) FILETIME=[8E352CA0:01C82B1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 20 Nov 2007 06:13:35 -0500 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: , Content-Type: multipart/mixed; boundary="===============1998109409==" Errors-To: tls-bounces@lists.ietf.org --===============1998109409== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KUEtJWCBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiBkZXB0aCBhIHllYXIgYWdvLg0K RGlmZmVyZW50IGFwcHJvYWNoZXMgaGFkIGJlIHNwZWNpZmllZCBmb3IgRUNDIGFuZCBSU0ENCltk cmFmdC1pZXRmLXBraXgtZWNjLXBrYWxncy0wMy50eHRdW1JGQyA0MDU1XS4NCkEgRGVzaWduIFRl YW0gd2FzIGZvcm1lZCB0byBwcm9wb3NlIGEgc29sdXRpb24uDQpBcHBhcmVudGx5IHRoZXkgc3Vn Z2VzdGVkIGEgM3JkIGFsdGVybmF0aXZlIC0tDQpkZWZpbmluZyBhIG5ldyBjZXJ0aWZpY2F0ZSBl eHRlbnNpb24uDQpJIGNhbm5vdCByZW1lbWJlciBzZWVpbmcgYW55IGZ1cnRoZXIgcHJvZ3Jlc3Mg b24gdGhhdCB3b3JrLg0KSSBhbSBzdXJlIG5vIHN1Y2ggZXh0ZW5zaW9uIHdhcyBhY3R1YWxseSBz dGFuZGFyZGl6ZWQuDQoNCkEgZ29vZCBwbGFjZSB0byBzdGFydCBpbiB0aGUgZW1haWwgYXJjaGl2 ZSB3b3VsZCBiZQ0KIlN0cmF3IHBvbGwgZm9yIEFsZ29yaXRobSBJZGVudGlmaWVycyBpbiBTdWJq ZWN0IFB1YmxpYyBLZXkgSW5mbyIsDQpieSBTdGVmYW4gU2FudGVzc29uLg0KaHR0cDovL3d3dy5p bWMub3JnL2lldGYtcGtpeC9tYWlsLWFyY2hpdmUvbXNnMDIzMDUuaHRtbA0KDQoNCi0tLS0tIC0t LS0tDQpGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIFttYWlsdG86b3duZXItaWV0 Zi1wa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENCg0KIAlNeSBj bGFp20 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR2v-0006fo-I0; Tue, 20 Nov 2007 06:13:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuIgY-0004Lz-3Q for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:17:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIgX-0004Lq-Ob for tls@ietf.org; Mon, 19 Nov 2007 21:17:57 -0500 Received: from mailipbo.ntcif.telstra.com.au ([202.12.233.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuIgX-0002vP-3P for tls@ietf.org; Mon, 19 Nov 2007 21:17:57 -0500 Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 20 Nov 2007 13:17:54 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 525CAFF85; Tue, 20 Nov 2007 13:17:54 +1100 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA20036; Tue, 20 Nov 2007 13:17:53 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:17:53 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] DSA/SHA-1, and OIDs Date: Tue, 20 Nov 2007 13:17:50 +1100 Message-ID: <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <20071119164754.8147233C2B@delta.rtfm.com> Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBA References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> From: "Manger, James H" To: , X-OriginalArrivalTime: 20 Nov 2007 02:17:53.0002 (UTC) FILETIME=[8E352CA0:01C82B1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 20 Nov 2007 06:13:35 -0500 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: , Content-Type: multipart/mixed; boundary="===============1998109409==" Errors-To: tls-bounces@lists.ietf.org --===============1998109409== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KUEtJWCBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiBkZXB0aCBhIHllYXIgYWdvLg0K RGlmZmVyZW50IGFwcHJvYWNoZXMgaGFkIGJlIHNwZWNpZmllZCBmb3IgRUNDIGFuZCBSU0ENCltk cmFmdC1pZXRmLXBraXgtZWNjLXBrYWxncy0wMy50eHRdW1JGQyA0MDU1XS4NCkEgRGVzaWduIFRl YW0gd2FzIGZvcm1lZCB0byBwcm9wb3NlIGEgc29sdXRpb24uDQpBcHBhcmVudGx5IHRoZXkgc3Vn Z2VzdGVkIGEgM3JkIGFsdGVybmF0aXZlIC0tDQpkZWZpbmluZyBhIG5ldyBjZXJ0aWZpY2F0ZSBl eHRlbnNpb24uDQpJIGNhbm5vdCByZW1lbWJlciBzZWVpbmcgYW55IGZ1cnRoZXIgcHJvZ3Jlc3Mg b24gdGhhdCB3b3JrLg0KSSBhbSBzdXJlIG5vIHN1Y2ggZXh0ZW5zaW9uIHdhcyBhY3R1YWxseSBz dGFuZGFyZGl6ZWQuDQoNCkEgZ29vZCBwbGFjZSB0byBzdGFydCBpbiB0aGUgZW1haWwgYXJjaGl2 ZSB3b3VsZCBiZQ0KIlN0cmF3IHBvbGwgZm9yIEFsZ29yaXRobSBJZGVudGlmaWVycyBpbiBTdWJq ZWN0IFB1YmxpYyBLZXkgSW5mbyIsDQpieSBTdGVmYW4gU2FudGVzc29uLg0KaHR0cDovL3d3dy5p bWMub3JnL2lldGYtcGtpeC9tYWlsLWFyY2hpdmUvbXNnMDIzMDUuaHRtbA0KDQoNCi0tLS0tIC0t LS0tDQpGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIFttYWlsdG86b3duZXItaWV0 Zi1wa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENCg0KIAlNeSBj bGFpbSBpcyB0aGF0IGZvciBzZWN1cml0eSByZWFzb25zIGl0J3MgbmVjZXNzYXJ5IGZvciBEU0EN CiAJY2VydHMgdG8gaW5kaWNhdGUgdGhlIGhhc2ggYWxnb3JpdGhtKHMpIHRoYXQgbWF5IGJlIHVz ZWQgd2l0aA0KIAl0aGUgcHVibGljIGtleSBjb250YWluZWQgaW4gdGhlIGNlcnQuIFRoaXMgcHJl dmVudHMgaGFzaA0KIAlhbGdvcml0aG0gc3Vic3RpdHV0aW9uIGluIHNpZ25hdHVyZXMgZm9ybWVk IHdpdGggdGhhdCBrZXkNCgkob3IgcmF0aGVyIHRoZSBwcml2YXRlIGtleSB0aGF0IGNvcnJlc3Bv bmRzIHRvIHRoYXQga2V5KS4gRG8NCiAJeW91IGFncmVlIHdpdGggdGhpcz8NCg0KLUVrcg0K --===============1998109409== 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 --===============1998109409==-- bSBpcyB0aGF0IGZvciBzZWN1cml0eSByZWFzb25zIGl0J3MgbmVjZXNzYXJ5IGZvciBEU0EN CiAJY2VydHMgdG8gaW5kaWNhdGUgdGhlIGhhc2ggYWxnb3JpdGhtKHMpIHRoYXQgbWF5IGJlIHVz ZWQgd2l0aA0KIAl0aGUgcHVibGljIGtleSBjb250YWluZWQgaW4gdGhlIGNlcnQuIFRoaXMgcHJl dmVudHMgaGFzaA0KIAlhbGdvcml0aG0gc3Vic3RpdHV0aW9uIGluIHNpZ25hdHVyZXMgZm9ybWVk IHdpdGggdGhhdCBrZXkNCgkob3IgcmF0aGVyIHRoZSBwcml2YXRlIGtleSB0aGF0IGNvcnJlc3Bv bmRzIHRvIHRoYXQga2V5KS4gRG8NCiAJeW91IGFncmVlIHdpdGggdGhpcz8NCg0KLUVrcg0K --===============1998109409== 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 --===============1998109409==-- From tls-bounces@lists.ietf.org Tue Nov 20 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuR2v-0006fK-5F; Tue, 20 Nov 2007 06:13:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iu9bA-0008TZ-An for tls-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 11:35:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9b9-0008Sb-Vq for tls@ietf.org; Mon, 19 Nov 2007 11:35:48 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu9b9-0005pu-N7 for tls@ietf.org; Mon, 19 Nov 2007 11:35:47 -0500 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Iu9b8-0003zT-6O; Mon, 19 Nov 2007 11:35:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20071117141738.B445033C21@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.micros oft.com> <20071117141738.B445033C21@delta.rtfm.com> Date: Mon, 19 Nov 2007 11:35:47 -0500 To: Eric Rescorla From: Stephen Kent Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Tue, 20 Nov 2007 06:13:35 -0500 Cc: "ietf-pkix@imc.org" , "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, Your question was: My claim is that for security reasons it's necessary for DSA certs to indicate the hash algorithm(s) that may be used with the cert. This prevents hash algorithm substitution in the signature. Do you agree with this? The wording here strikes me as a bit odd. The hash algorithm used to verify a cert IS specified in the cert, in the SignatureAlgorithm field. The hash algorithm(s) that may be used with the public KEY in the cert are not specified, in general, as the key may be used to verify signatures for certs or for other signed objects (in the case of EE certs). Steve _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 06:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRCo-0000Tg-1z; Tue, 20 Nov 2007 06:23:50 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuRCn-0000Tb-7K for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:23:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRCm-0000TC-TA for TLS@lists.ietf.org; Tue, 20 Nov 2007 06:23:48 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRCj-00071g-Bk for TLS@lists.ietf.org; Tue, 20 Nov 2007 06:23:48 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAKBNgmG009517; Tue, 20 Nov 2007 13:23:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:23:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:23:34 +0200 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] CAs and certificate chains in the SSL/TLS handshake Date: Tue, 20 Nov 2007 13:23:34 +0200 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223A32C96@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] CAs and certificate chains in the SSL/TLS handshake Thread-Index: AcghdcIhhnEsx7zhQ2KtzoYysg3F4QG+tX8QAIZGtxAAFHvhQAAi/Wew References: <200711071936.lA7Jabql023856@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D3223A32878@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D3223A32C96@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 20 Nov 2007 11:23:34.0919 (UTC) FILETIME=[C9E93970:01C82B67] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Stefan Santesson wrote: > Pasi, >=20 > I know that the structure for certificates is defined. I was=20 > just surprised that this section didn't even mention it. I=20 > know that many use standards as dictionaries rather than=20 > novels (they don't read them from page 1 to the end). So some=20 > kind of hint where the structure is defined would not hurt. A very reasonable suggestion; I'll propose text to be added=20 here during WGLC. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 11:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVpw-0005D6-Gi; Tue, 20 Nov 2007 11:20:32 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuVpv-0005Br-0O for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:20:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVpu-0005Bj-LA for tls@ietf.org; Tue, 20 Nov 2007 11:20:30 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuVpu-0007wE-7M for tls@ietf.org; Tue, 20 Nov 2007 11:20:30 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 20 Nov 2007 16:20:29 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 20 Nov 2007 16:20:29 +0000 From: Stefan Santesson To: "Manger, James H" , "ietf-pkix@imc.org" , "tls@ietf.org" Date: Tue, 20 Nov 2007 16:19:40 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAB21BnA= Message-ID: <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Content-Type: multipart/mixed; boundary="===============1237066491==" Errors-To: tls-bounces@lists.ietf.org --===============1237066491== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtZXMsDQoNClRoZSBkZXNpZ24gdGVhbSBoYXMgbWV0IGFnYWluIGFuZCB3aWxsIHRhbGsgYWJv dXQgaXQgYXQgdGhlIFBLSVggbWVldGluZy4NCkhvd2V2ZXIsIHRoaXMgaGFzIG5ldmVyIGV4dGVu ZGVkIGJleW9uZCB0aGUgcHVibGljIGtleSBhbGdvcml0aG0gaXRzZWxmLg0KTm8gb25lIGhhcyBz ZXJpb3VzbHkgcmVxdWVzdGVkIGEgZnVsbCBzaWduYXR1cmUgYWxnb3JpdGhtIHdpdGggaGFzaCBh bGdvcml0aG0gdG8gYmUgc3BlY2lmaWVkIGluIHRoaXMgZmllbGQuDQoNClN0ZWZhbiBTYW50ZXNz b24NClNlbmlvciBQcm9ncmFtIE1hbmFnZXINCldpbmRvd3MgU2VjdXJpdHksIFN0YW5kYXJkcw0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItaWV0Zi1wa2l4 QG1haWwuaW1jLm9yZyBbbWFpbHRvOm93bmVyLWlldGYtDQo+IHBraXhAbWFpbC5pbWMub3JnXSBP biBCZWhhbGYgT2YgTWFuZ2VyLCBKYW1lcyBIDQo+IFNlbnQ6IGRlbiAyMCBub3ZlbWJlciAyMDA3 IDAzOjE4DQo+IFRvOiBpZXRmLXBraXhAaW1jLm9yZzsgdGxzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiBbVExTXSBEU0EvU0hBLTEsIGFuZCBPSURzDQo+DQo+DQo+IEVyaWMsDQo+DQo+IFBLSVgg ZGlzY3Vzc2VkIHRoaXMgaXNzdWUgaW4gZGVwdGggYSB5ZWFyIGFnby4NCj4gRGlmZmVyZW50IGFw cHJvYWNoZXMgaGFkIGJlIHNwZWNpZmllZCBmb3IgRUNDIGFuZCBSU0ENCj4gW2RyYWZ0LWlldGYt cGtpeC1lY2MtcGthbGdzLTAzLnR4dF1bUkZDIDQwNTVdLg0KPiBBIERlc2lnbiBUZWFtIHdhcyBm b3JtZWQgdG8gcHJvcG9zZSBhIHNvbHV0aW9uLg0KPiBBcHBhcmVudGx5IHRoZXkgc3VnZ2VzdGVk IGEgM3JkIGFsdGVybmF0aXZlIC0tDQo+IGRlZmluaW5nIGEgbmV3IGNlcnRpZmljYXRlIGV4dGVu c2lvbi4NCj4gSSBjYW5ub3QgcmVtZW1iZXIgc2VlaW5nIGFueSBmdXJ0aGVyIHByb2dyZXNzIG9u IHRoYXQgd29yay4NCj4gSSBhbSBzdXJlIG5vIHN1Y2ggZXh0ZW5zaW9uIHdhcyBhY3R1YWxseSBz dGFuZGFyZGl6ZWQuDQo+DQo+IEEgZ29vZCBwbGFjZSB0byBzdGFydCBpbiB0aGUgZW1haWwgYXJj aGl2ZSB3b3VsZCBiZQ0KPiAiU3RyYXcgcG9sbCBmb3IgQWxnb3JpdGhtIElkZW50aWZpZXJzIGlu IFN1YmplY3QgUHVibGljIEtleSBJbmZvIiwNCj4gYnkgU3RlZmFuIFNhbnRlc3Nvbi4NCj4gaHR0 cDovL3d3dy5pbWMub3JnL2lldGYtcGtpeC9tYWlsLWFyY2hpdmUvbXNnMDIzMDUuaHRtbA0KPg0K Pg0KPiAtLS0tLSAtLS0tLQ0KPiBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIFtt YWlsdG86b3duZXItaWV0Zi0NCj4gcGtpeEBtYWlsLmltYy5vcmddIE9uIEJlaGFsZiBPZiBFcmlj IFJlc2NvcmxhDQo+DQo+ICAgICAgICAgTXkgY2xhaW0gaXMgdGhhdCBmb3Igc2VjdXJpdHkgcmVh c29ucyBpdCdzIG5lY2Vzc2FyeSBmb3IgRFNBDQo+ICAgICAgICAgY2VydHMgdG8gaW5kaWNhdGUg dGhlIGhhc2ggYWxnb3JpdGhtKHMpIHRoYXQgbWF5IGJlIHVzZWQgd2l0aA0KPiAgICAgICAgIHRo ZSBwdWJsaWMga2V5IGNvbnRhaW5lZCBpbiB0aGUgY2VydC4gVGhpcyBwcmV2ZW50cyBoYXNoDQo+ ICAgICAgICAgYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBpbiBzaWduYXR1cmVzIGZvcm1lZCB3aXRo IHRoYXQga2V5DQo+ICAgICAgICAgKG9yIHJhdGhlciB0aGUgcHJpdmF0ZSBrZXkgdGhhdCBjb3Jy ZXNwb25kcyB0byB0aGF0IGtleSkuIERvDQo+ICAgICAgICAgeW91IGFncmVlIHdpdGggdGhpcz8N Cj4NCj4gLUVrcg0KDQo= --===============1237066491== 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 --===============1237066491==-- From tls-bounces@lists.ietf.org Tue Nov 20 12:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX3a-0007NK-GZ; Tue, 20 Nov 2007 12:38:42 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IuX3Y-0007N7-LR for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX3Y-0007Mz-BV for tls@ietf.org; Tue, 20 Nov 2007 12:38:40 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuX3V-0001II-3j for tls@ietf.org; Tue, 20 Nov 2007 12:38:40 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B3C8133C21; Tue, 20 Nov 2007 09:33:36 -0800 (PST) Date: Tue, 20 Nov 2007 09:33:36 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071120173336.B3C8133C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "ietf-pkix@imc.org" , "Manger, James H" , "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 At Tue, 20 Nov 2007 16:19:40 +0000, Stefan Santesson wrote: > > [1 ] > James, > > The design team has met again and will talk about it at the PKIX meeting. > However, this has never extended beyond the public key algorithm itself. > No one has seriously requested a full signature algorithm with hash algorithm to be specified in this field. Please take this message as a request from me that it be so, at least for DSA/ECSDA. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 16:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub2w-0006oE-BY; Tue, 20 Nov 2007 16:54:18 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iub2v-0006nV-G0 for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 16:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub2v-0006mG-5y for tls@ietf.org; Tue, 20 Nov 2007 16:54:17 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iub2r-0004DB-6y for tls@ietf.org; Tue, 20 Nov 2007 16:54:17 -0500 Received: (qmail 11643 invoked by uid 0); 20 Nov 2007 21:54:04 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 20 Nov 2007 21:54:04 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 10:42:09 -0500 To: Eric Rescorla From: Russ Housley Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <20071117141738.B445033C21@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.microsoft.com> <20071117141738.B445033C21@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.9 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Message-Id: Cc: ietf-pkix@imc.org, 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: I disagree. When an actual signature is generated, then signer must indicate which hash was used to generate the signature. Only the holder of the private key can generate the signature, so the holder of the private key is totally in control of which hash function they choose to use. X.509 and CMS include the algorithm identifier of the signature algorithm (which implicitly identifies the hash function) in two places. One is outside the signature to aid in signature validation. The second one is covered by the signature, and it must match the one on the outside. Putting a list of hash functions in the certificate would be protected by the hash function that the CA employed in signing the certificate, which might be a better studied structure, but it just move the concern that you seem to be raising to the certificate instead of the signed data. Russ At 09:17 AM 11/17/2007, Eric Rescorla wrote: >My claim is that for security reasons it's necessary for DSA certs >to indicate the hash algorithm(s) that may be used with the cert. >This prevents hash algorithm substitution in the signature. >Do you agree with this? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 20 17:26:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubXi-0001A0-Tv; Tue, 20 Nov 2007 17:26:06 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IubXi-00015T-5g for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:26:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubXh-00015L-Qw for tls@ietf.org; Tue, 20 Nov 2007 17:26:05 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IubXh-0007cf-Dd for tls@ietf.org; Tue, 20 Nov 2007 17:26:05 -0500 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAKMQ3Fg027202 for ; Tue, 20 Nov 2007 17:26:03 -0500 (EST) X-AuditID: 90333308-00000f1c000007e0-2b-47435efa5b5c Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:26:02 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 17:26:02 -0500 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] DSA/SHA-1, and OIDs Date: Tue, 20 Nov 2007 17:26:02 -0500 Message-ID: In-Reply-To: <20071120173336.B3C8133C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgrnD7GaEgncnFERZiJtjiaoFoeRwAILEpA References: <20071112191115.543C833C2B@delta.rtfm.com><20071119164754.8147233C2B@delta.rtfm.com><6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com><9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> From: "Kemp, David P." To: , X-OriginalArrivalTime: 20 Nov 2007 22:26:02.0697 (UTC) FILETIME=[556ED390:01C82BC4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Is there any reason to believe that DSA or ECDSA signatures are more susceptible to hash downgrade attacks than RSA-with-digest signatures? And is there a reason such attacks are important? It would seem that a relying party should not accept algorithms that it is not willing to accept. I.e., if the RP would accept a DSA-with-SHA1 signature on message X, then why should the RP not accept DSA-with-SHA1 signature on message Y? (Assume X was signed with SHA1 and Y was signed with SHA2 but was attacked). Putting restrictions on the cert used to sign Y will have no effect on other messages. In the logical end, if an RP is willing to accept signed and unsigned messages, there is no way to prevent a "downgrade" attack of stripping the signature entirely. I don't see the value of using certificate contents to=20 constrain and signal hash algorithms as opposed to the established practice of using protocol and configuration mechanisms. The benefit of the latter is that algorithms can be *upgraded* without reissuing the cert, i.e. users who have been signing using SHA1 can also use SHA2. -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, November 20, 2007 12:34 PM To: Stefan Santesson Cc: ietf-pkix@imc.org; Manger,James H; tls@ietf.org Subject: Re: [TLS] DSA/SHA-1, and OIDs At Tue, 20 Nov 2007 16:19:40 +0000, Stefan Santesson wrote: >=20 > [1 ] > James, >=20 > The design team has met again and will talk about it at the PKIX meeting. > However, this has never extended beyond the public key algorithm itself. > No one has seriously requested a full signature algorithm with hash algorithm to be specified in this field. Please take this message as a request from me that it be so, at least for DSA/ECSDA. -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 Tue Nov 20 19:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iudgd-0008H2-PM; Tue, 20 Nov 2007 19:43:27 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iudgc-0008Gp-AN for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:43:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iudgb-0008Gh-ON; Tue, 20 Nov 2007 19:43:25 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iudgb-00045L-8P; Tue, 20 Nov 2007 19:43:25 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 4DF82F5EB0; Tue, 20 Nov 2007 16:43:24 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071121004324.4DF82F5EB0@bosco.isi.edu> Date: Tue, 20 Nov 2007 16:43:24 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 5054 on Using the Secure Remote Password (SRP) Protocol for TLS Authentication 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 A new Request for Comments is now available in online RFC libraries. RFC 5054 Title: Using the Secure Remote Password (SRP) Protocol for TLS Authentication Author: D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Status: Informational Date: November 2007 Mailbox: dtaylor@gnutls.org, thomwu@cisco.com, nmav@gnutls.org, trevp@trevp.net Pages: 24 Characters: 44445 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-srp-14.txt URL: http://www.rfc-editor.org/rfc/rfc5054.txt This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 02:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iujjc-0007AS-Ow; Wed, 21 Nov 2007 02:10:56 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IubzP-0001nD-Fc for tls-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubzP-0001lb-05 for tls@ietf.org; Tue, 20 Nov 2007 17:54:43 -0500 Received: from exvs01.ex.dslextreme.net ([66.51.199.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IubzL-0006Sz-I9 for tls@ietf.org; Tue, 20 Nov 2007 17:54:42 -0500 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] DSA/SHA-1, and OIDs Date: Tue, 20 Nov 2007 14:55:02 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87909D5A908@EXVS01.ex.dslextreme.net> In-Reply-To: <200711202154.lAKLsBFR034985@balder-227.proper.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgrx2NtlIqwAwRzR5q3reb/tLBRZgAANGEg References: <20071112191115.543C833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223A32833@EA-EXMSG-C332.europe.corp.microsoft.com> <20071117141738.B445033C21@delta.rtfm.com> <200711202154.lAKLsBFR034985@balder-227.proper.com> From: "Santosh Chokhani" To: "Russ Housley" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 21 Nov 2007 02:10:56 -0500 Cc: ietf-pkix@imc.org, 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, But, assuming the trust anchor (self-signed certificate) contains the hashing algorithm you trust (just like the public key) and the certificates in the path have the hash extension, certification path does provide that transitive trust. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Tuesday, November 20, 2007 10:42 AM To: Eric Rescorla Cc: ietf-pkix@imc.org; tls@ietf.org Subject: Re: [TLS] DSA/SHA-1, and OIDs Eric: I disagree. When an actual signature is generated, then signer must=20 indicate which hash was used to generate the signature. Only the=20 holder of the private key can generate the signature, so the holder=20 of the private key is totally in control of which hash function they=20 choose to use. X.509 and CMS include the algorithm identifier of the signature=20 algorithm (which implicitly identifies the hash function) in two=20 places. One is outside the signature to aid in signature=20 validation. The second one is covered by the signature, and it must=20 match the one on the outside. Putting a list of hash functions in the certificate would be=20 protected by the hash function that the CA employed in signing the=20 certificate, which might be a better studied structure, but it just=20 move the concern that you seem to be raising to the certificate=20 instead of the signed data. Russ At 09:17 AM 11/17/2007, Eric Rescorla wrote: >My claim is that for security reasons it's necessary for DSA certs >to indicate the hash algorithm(s) that may be used with the cert. >This prevents hash algorithm substitution in the signature. >Do you agree with this? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 07:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iup0l-0002ty-Fb; Wed, 21 Nov 2007 07:48:59 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iup0j-0002td-J8 for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 07:48:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iup0j-0002tS-2f for tls@ietf.org; Wed, 21 Nov 2007 07:48:57 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iup0i-0007bG-Da for tls@ietf.org; Wed, 21 Nov 2007 07:48:56 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 21 Nov 2007 12:48:55 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Wed, 21 Nov 2007 12:48:55 +0000 From: Stefan Santesson To: Eric Rescorla Date: Wed, 21 Nov 2007 12:47:58 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgrnDhnKbG8Kks0RPCy0emscOerSwAnq6EQ Message-ID: <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> In-Reply-To: <20071120173336.B3C8133C21@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "ietf-pkix@imc.org" , "Manger, James H" , "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 This is not the place to request it, but I really think we should bring thi= s up in a common meeting like the saag, because it is a general problem tha= t is relevant cross protocols. Trying to solve downgrade problems by stuffing hash limitations in the cer= tificate worries me, feels like the easy way out for the protocol designers= and principally wrong. As pointed out, it makes management of hash selection a lot harder and a sl= ow moving target as it requires certificate issuance to match the hash poli= cy. As a basic principle I think the major effort to transition to better hashe= s is to upgrade the capability of communicating hosts before the lowest gra= de of hash used becomes a realistic security issue. As a secondary solution= protocols could be amended to protect against downgrading, as with S/MIME = and as a last resort enhance the certificates. Is there any studies out there showing that this is a real security issue (= has any realistic chance of being exploited) or are we simply chasing a gho= st far away from the scene of real internet crime? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 20 november 2007 18:34 > To: Stefan Santesson > Cc: Manger, James H; ietf-pkix@imc.org; tls@ietf.org > Subject: Re: [TLS] DSA/SHA-1, and OIDs > > At Tue, 20 Nov 2007 16:19:40 +0000, > Stefan Santesson wrote: > > > > [1 ] > > James, > > > > The design team has met again and will talk about it at the PKIX > meeting. > > However, this has never extended beyond the public key algorithm > itself. > > No one has seriously requested a full signature algorithm with hash > algorithm to be specified in this field. > > Please take this message as a request from me that it be so, at > least for DSA/ECSDA. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 09:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur2p-0005HT-7N; Wed, 21 Nov 2007 09:59:15 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iuqvx-0000kG-CL for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:52:09 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iuqvx-0000k3-2q for tls@ietf.org; Wed, 21 Nov 2007 09:52:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuqfj-000433-TN for tls@ietf.org; Wed, 21 Nov 2007 09:35:24 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuqfg-0006r4-FP for tls@ietf.org; Wed, 21 Nov 2007 09:35:23 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Nov 2007 06:35:21 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lALEZJZf008011; Wed, 21 Nov 2007 06:35:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALEZJb6020145; Wed, 21 Nov 2007 14:35:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 06:34:47 -0800 Received: from [10.32.244.67] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 06:34:46 -0800 In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: max pritikin Subject: Re: [TLS] DSA/SHA-1, and OIDs Date: Wed, 21 Nov 2007 08:34:19 -0600 To: Stefan Santesson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Nov 2007 14:34:46.0804 (UTC) FILETIME=[AA19B540:01C82C4B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2170; t=1195655719; x=1196519719; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20[TLS]=20DSA/SHA-1,=20and=20OIDs |Sender:=20; bh=fFdcki2T7xPGV8OtL5T7kjE6IOFwknUTxgBxK/0Qs8g=; b=IyOsvZ8CodCxQabjnpw0PBBUgkTcO99hew2DvpXJaCZ1GJeWaH4v5QJQttWHmQ+DZYaipu++ cWyxgeQ0ankOK235mmjybmUGnrHAYnEvRErKNG76YBOa/RGKeTt4nNcB; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-TMDA-Confirmed: Wed, 21 Nov 2007 09:52:09 -0500 X-Mailman-Approved-At: Wed, 21 Nov 2007 09:59:14 -0500 Cc: "ietf-pkix@imc.org" , "Manger, James H" , "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 too feel that placing protocol hints in the certificate is a bad way to go. - max On Nov 21, 2007, at 6:47 AM, Stefan Santesson wrote: > > This is not the place to request it, but I really think we should > bring this up in a common meeting like the saag, because it is a > general problem that is relevant cross protocols. > > Trying to solve downgrade problems by stuffing hash limitations in > the certificate worries me, feels like the easy way out for the > protocol designers and principally wrong. > As pointed out, it makes management of hash selection a lot harder > and a slow moving target as it requires certificate issuance to > match the hash policy. > > As a basic principle I think the major effort to transition to > better hashes is to upgrade the capability of communicating hosts > before the lowest grade of hash used becomes a realistic security > issue. As a secondary solution protocols could be amended to > protect against downgrading, as with S/MIME and as a last resort > enhance the certificates. > > Is there any studies out there showing that this is a real security > issue (has any realistic chance of being exploited) or are we > simply chasing a ghost far away from the scene of real internet crime? > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: den 20 november 2007 18:34 >> To: Stefan Santesson >> Cc: Manger, James H; ietf-pkix@imc.org; tls@ietf.org >> Subject: Re: [TLS] DSA/SHA-1, and OIDs >> >> At Tue, 20 Nov 2007 16:19:40 +0000, >> Stefan Santesson wrote: >>> >>> [1 ] >>> James, >>> >>> The design team has met again and will talk about it at the PKIX >> meeting. >>> However, this has never extended beyond the public key algorithm >> itself. >>> No one has seriously requested a full signature algorithm with hash >> algorithm to be specified in this field. >> >> Please take this message as a request from me that it be so, at >> least for DSA/ECSDA. >> >> -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 10:03:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur6P-0001Io-HF; Wed, 21 Nov 2007 10:02:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iur6L-0001CI-2o for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:02:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur6K-0001AM-Mv for tls@ietf.org; Wed, 21 Nov 2007 10:02:52 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iur6K-0003sJ-6d for tls@ietf.org; Wed, 21 Nov 2007 10:02:52 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3114833C2B; Wed, 21 Nov 2007 06:57:50 -0800 (PST) Date: Wed, 21 Nov 2007 06:57:49 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071121145750.3114833C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "ietf-pkix@imc.org" , "Manger, James H" , "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 At Wed, 21 Nov 2007 12:47:58 +0000, Stefan Santesson wrote: > > This is not the place to request it, but I really think we should > bring this up in a common meeting like the saag, because it is a > general problem that is relevant cross protocols. > > Trying to solve downgrade problems by stuffing hash limitations in > the certificate worries me, feels like the easy way out for the > protocol designers and principally wrong. I don't know what you mean by "the easy way out". TLS, for instance, has extensive anti-downgrade provisions. But this particular one cannot go in the protocol, because it's fundamentally tied to the signing key. [The exception here is to make an explicit tie to key length, i.e., keys of length X need SHA-1. I'll note that this is what FIPS 186-3 already does but it's notmandatory.] > As pointed out, it makes management of hash selection a lot harder > and a slow moving target as it requires certificate issuance to > match the hash policy. I don't see this. What I would expect would simply be that certificates would be issued with digest algorithms that match the FIPS 186-3 recommendations. > As a basic principle I think the major effort to transition to > better hashes is to upgrade the capability of communicating hosts > before the lowest grade of hash used becomes a realistic security > issue. This isn't about turning on new hashes, it's about allowing old ones to be used once the new ones are turned on during the transition period. > As a secondary solution protocols could be amended to protect > against downgrading, as with S/MIME and as a last resort enhance the > certificates. We're talking about two different kinds of downgrade here. The S/MIME anti-downgrade issue is about signature stripping when multiple signatures are applied. The downgrade issue I'm concerned about is straight-line forgery: Alice always signs with digest algorithm H1: she then generates a signature over some message M where H1(M) = X. The attacker compromises H2 and forms M' st. H2(M2) = X. He can then craft a new message apparently signed by Alice. There's no act that Alice can take involving H1 and her signature algorithm that can prevent this: it has to be in information available to a verifier who has only the cert and a candidate signature. > Is there any studies out there showing that this is a real security > issue (has any realistic chance of being exploited) or are we simply > chasing a ghost far away from the scene of real internet crime? Is this the current PKIX standard for work items? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 11:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ius5k-0000HF-2G; Wed, 21 Nov 2007 11:06:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ius5i-0000H5-B7 for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:06:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ius5i-0000Gw-1H for TLS@lists.ietf.org; Wed, 21 Nov 2007 11:06:18 -0500 Received: from mailrelay.tu-graz.ac.at ([129.27.2.202] helo=mailrelay.tugraz.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ius5d-0001me-1V for TLS@lists.ietf.org; Wed, 21 Nov 2007 11:06:17 -0500 Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.14.2/8.14.2) with ESMTP id lALG66A7004099; Wed, 21 Nov 2007 17:06:06 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.3.2 mailrelay1.tugraz.at lALG66A7004099 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tugraz.at; s=mailrelay; t=1195661169; bh=J3dJYIdodOXiLPqbKCeo6so7MFIzmqjYXEnCO JCMc5Y=; h=X-Virus-Scanned:Message-ID:From:To:Cc:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority: X-MSMail-Priority:X-Mailer:X-MimeOLE:X-Spam-Scanner: X-Spam-Score-relay:X-Scanned-By; b=iMYynAgC9QPUXkqOq5OUXRgL+DvJk/Y LZhO5iazeRvZF3PbNRBz67Jv0DtgzJKmDld16/EzvvCGwfELji7KiC1758GN8W34qyB OBj/Ni4eKQwT4waCBlDzopjX5Sm1Jz2C7Z/rQ+BtsIOusmeJvxkSh5xbHnKWCsofaar n9SZgE= Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 3F45819C004; Wed, 21 Nov 2007 17:06:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at iaik.tugraz.at Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor.iaik.tugraz.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syprT2kfpsza; Wed, 21 Nov 2007 17:06:07 +0100 (CET) Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP; Wed, 21 Nov 2007 17:06:07 +0100 (CET) Received: from localhost [127.0.0.1] by vesta (IAIK S/MIME Mapper 2.02 12 June 2002); Mi, 21 Nov 2007 17:06:07 +0100 Message-ID: <043801c82c58$6ca27730$6d981b81@iaik.tugraz.at> From: "Dieter Bratko" To: Date: Wed, 21 Nov 2007 17:06:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Scanner: SpamAssassin 3.002003 X-Spam-Score-relay: -2.6 X-Scanned-By: MIMEDefang 2.63 on 129.27.10.18 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Pat Sharkey Subject: [TLS] CertificateRequest 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 all, recently we have observed problems with SSL/TLS servers that send large numbers of certificate authorities wihtin their CertificateRequest message. For instance, one server sent 152 CA names (21613 bytes), another sent 164 (29293 bytes) within one record without fragmentation... The client may have to check if any of its keys is appropriate for any of these 164 CAs received from the server. There is no way for the client to tell the server to do not send or limit the number of certificate authorities in the CertificateRequest message. Have there ever been thoughts about, or would this group support a proposal for an extension allowing the client to first announce the DNs of the CAs for which it is able to fulfill a CertificateRequest? Usually a client only has a few number of keys (for instance 1 or 2) to may be used for client authentication. The client could use an extension to send the DNs of these few CAs to the server who then -- if it is configured to request client authentication -- may include only one (or some) of these few CA names in its CertificateRequest message (instead of sending all its trusted CAs). Regards, Dieter --------- Dieter Bratko, SIC/IAIK - Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 11:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusnJ-0008CZ-L6; Wed, 21 Nov 2007 11:51:21 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IusnI-00087A-Kq for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:51:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusnI-00084S-7q for tls@ietf.org; Wed, 21 Nov 2007 11:51:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusnH-0007nc-QL for tls@ietf.org; Wed, 21 Nov 2007 11:51:20 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALGpF4g025608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 09:51:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071121145750.3114833C2B@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.micros oft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.micros oft.com> <20071121145750.3114833C2B@delta.rtfm.com> Date: Wed, 21 Nov 2007 08:50:33 -0800 To: Eric Rescorla , Stefan Santesson From: Paul Hoffman Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "ietf-pkix@imc.org" , "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 At 6:57 AM -0800 11/21/07, Eric Rescorla wrote: >We're talking about two different kinds of downgrade here. >The S/MIME anti-downgrade issue is about signature stripping >when multiple signatures are applied. The downgrade issue >I'm concerned about is straight-line forgery: Alice always >signs with digest algorithm H1: she then generates a signature >over some message M where H1(M) = X. The attacker compromises H2 >and forms M' st. H2(M2) = X. He can then craft a new message >apparently signed by Alice. There's no act that Alice can take >involving H1 and her signature algorithm that can prevent this: >it has to be in information available to a verifier who has only >the cert and a candidate signature. The proposed solution of an extension that says which hash functions can be used with the public key in a cert has a few flaws. First, it means that all CAs must understand the safety of all the hash algorithms out there to know to not list H2. In some sense, they must all predict the future as well, because they might list H2 today and then next year find out that some set of Mallorys have compromised it. Further, this puts CAs into the position of saying what can and cannot be done with a public key; "key usage" has proven this to be a disaster. Instead, we have to assume that all relying parties need to know which of the hash algorithms that they know how to use are trustworthy, and which aren't. Hopefully, for any that are not, the relying party simply forgets how to use it, or marks it as poisoned. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 11:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iustl-00008m-Uh; Wed, 21 Nov 2007 11:58:01 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iustk-00008g-Vn for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:58:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iustk-00008Y-LA for tls@ietf.org; Wed, 21 Nov 2007 11:58:00 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iustk-0007zK-6y for tls@ietf.org; Wed, 21 Nov 2007 11:58:00 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6F56533C2B; Wed, 21 Nov 2007 08:52:58 -0800 (PST) Date: Wed, 21 Nov 2007 08:52:57 -0800 From: Eric Rescorla To: Paul Hoffman Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071121165258.6F56533C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "ietf-pkix@imc.org" , "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 At Wed, 21 Nov 2007 08:50:33 -0800, Paul Hoffman wrote: > > At 6:57 AM -0800 11/21/07, Eric Rescorla wrote: > >We're talking about two different kinds of downgrade here. > >The S/MIME anti-downgrade issue is about signature stripping > >when multiple signatures are applied. The downgrade issue > >I'm concerned about is straight-line forgery: Alice always > >signs with digest algorithm H1: she then generates a signature > >over some message M where H1(M) = X. The attacker compromises H2 > >and forms M' st. H2(M2) = X. He can then craft a new message > >apparently signed by Alice. There's no act that Alice can take > >involving H1 and her signature algorithm that can prevent this: > >it has to be in information available to a verifier who has only > >the cert and a candidate signature. > > The proposed solution of an extension that says which hash functions > can be used with the public key in a cert has a few flaws. First, it > means that all CAs must understand the safety of all the hash > algorithms out there to know to not list H2. Not really, no. As I said, I think this is pretty much an issue of matching SHA variant to DSA key size. I agree that this is imperfect, but the situation is imperfect. > In some sense, they must > all predict the future as well, because they might list H2 today and > then next year find out that some set of Mallorys have compromised > it. Further, this puts CAs into the position of saying what can and > cannot be done with a public key; "key usage" has proven this to be a > disaster. This strikes me as a pretty different case. > Instead, we have to assume that all relying parties need to know > which of the hash algorithms that they know how to use are > trustworthy, and which aren't. Hopefully, for any that are not, the > relying party simply forgets how to use it, or marks it as poisoned. This seems highly undesirable from the perspective of the verifying party, who has opinions about what digests he will use, but who needs the relying party to enforce it. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 13:09:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuu0a-0008Pu-19; Wed, 21 Nov 2007 13:09:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iuu0X-0008Lh-U2 for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuu0X-0008Jd-Jd for tls@ietf.org; Wed, 21 Nov 2007 13:09:05 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuu0U-00068S-7w for tls@ietf.org; Wed, 21 Nov 2007 13:09:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7EF6733C2B; Wed, 21 Nov 2007 10:04:00 -0800 (PST) Date: Wed, 21 Nov 2007 10:03:59 -0800 From: Eric Rescorla To: max pritikin Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071121180400.7EF6733C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "ietf-pkix@imc.org" , "tls@ietf.org" , Paul Hoffman 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 At Wed, 21 Nov 2007 11:26:53 -0600, max pritikin wrote: > Placing usage instructions in the certificate does not enforce the > verifying parties behavior any more than protocol handshakes would. It's not a matter of enforcement than information. Again, there's no way to do this in the protocol handshake because it needs to be authenticated by a separate mechanism. > Paul's > example of key usage seems to be very topical. > > Long lived device certificates would suffer from this approach. The > certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc > etc etc) are profiled and baked well in advance. Attempting to expand > those profiles to limit the use of the credentials to particular hash > algorithms would be problematic. No more than limiting them to particular signature algorithms, which is baked into the certificate right now. In fact, I'd observe that current DSA certificates are effectively restricted to SHA-1 right now in that there is no DSS for DSA with other digests. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 21 14:55:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvf5-0005M1-OF; Wed, 21 Nov 2007 14:55:03 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iuvf3-0005JZ-VG for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvf3-0005JP-LF for tls@ietf.org; Wed, 21 Nov 2007 14:55:01 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuvez-0001Ji-Ks for tls@ietf.org; Wed, 21 Nov 2007 14:55:01 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.102]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Iuvew-0001wr-3n; Wed, 21 Nov 2007 14:54:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20071121145750.3114833C2B@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.micros oft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.micros oft.com> <20071121145750.3114833C2B@delta.rtfm.com> Date: Wed, 21 Nov 2007 14:53:49 -0500 To: Eric Rescorla From: Stephen Kent Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Manger, James H" , "tls@ietf.org" , "ietf-pkix@imc.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 At 6:57 AM -0800 11/21/07, Eric Rescorla wrote: >... > > Is there any studies out there showing that this is a real security >> issue (has any realistic chance of being exploited) or are we simply >> chasing a ghost far away from the scene of real internet crime? > >Is this the current PKIX standard for work items? > >-Ekr Two observations: PKIX does take into account the viability of attacks when deciding how to address newly discovered vulnerabilities. So, for example, we noted that a CA could assign non-predictable cert serial numbers as a countermeasure to the first published hash attacks, which rely on the attacker being able to know/control the prefix of a signed object such as a cert submitted in a cert request. Several of the recent messages refer to problem of using the right hash algorithm with a given signature algorithm and key size. PKIX will certainly address this problem in the context of our data objects, e.g., certs. It is less clear whether PKIX should advocate carriage of additional data in certs to assist other protocols in this area. One could define suitable conventions for hash alg and signature alg/key size in the context of each protocol, for example. That doesn't mean we ought not consider an extension for carrying this info, but as several there folks have pointed out, this approach has problems too: - a CA may not want to assume liability for putting this info into a cert - a cert lifetime many not match the time frame for expressing new algorithm pairing info - an application/protocol or a CAPI may not have ready access to a private extension used to convey this info We have to proceed cautiously here. I am not (yet) ruling out an extension to carry such info, if these issue can be addressed. Steve _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 22 04:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv83Q-00043l-IU; Thu, 22 Nov 2007 04:09:00 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iv83O-00043R-TQ for tls-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 04:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv83I-000425-I9 for TLS@lists.ietf.org; Thu, 22 Nov 2007 04:08:52 -0500 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv83D-0008OX-L7 for TLS@lists.ietf.org; Thu, 22 Nov 2007 04:08:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A20E61852E; Thu, 22 Nov 2007 22:08:43 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51Rqg6bIEWmF; Thu, 22 Nov 2007 22:08:43 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 144221852D; Thu, 22 Nov 2007 22:08:41 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4246319EC0B6; Thu, 22 Nov 2007 22:08:38 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Iv834-0003eK-52; Thu, 22 Nov 2007 22:08:38 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Dieter.Bratko@iaik.tugraz.at, TLS@lists.ietf.org Subject: Re: [TLS] CertificateRequest In-Reply-To: <043801c82c58$6ca27730$6d981b81@iaik.tugraz.at> Message-Id: Date: Thu, 22 Nov 2007 22:08:38 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: PSharkey@cleo.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 "Dieter Bratko" writes: >recently we have observed problems with SSL/TLS servers that send large >numbers of certificate authorities wihtin their CertificateRequest message. >For instance, one server sent 152 CA names (21613 bytes), another sent 164 >(29293 bytes) within one record without fragmentation... The client may have >to check if any of its keys is appropriate for any of these 164 CAs received >from the server. My suspicion is that this is just a pathological implementation that's iterating through all the CAs it knows of (the count seems to be in the ballpark of the set of automatically trusted CAs for Windows, depending on which root cert updates have been applied). I can't imagine that any server would really trust 160 different CAs to authorise access. To support this, I've seen servers that send out cert requests without the admins even knowing that they're doing it, and the servers certainly don't want or even know what to do with a client cert when they send the request. >Have there ever been thoughts about, or would this group support a proposal >for an extension allowing the client to first announce the DNs of the CAs for >which it is able to fulfill a CertificateRequest? Usually a client only has a >few number of keys (for instance 1 or 2) to may be used for client >authentication. I've found that simply ignoring the contents of the cert request seems to work pretty well. Since there are servers sending out nonsensical requests, the safest thing to do is just record that a request for a cert exists. If you have a cert, send it and let the server sort it out. If you don't, send a no- cert response, which deals nicely with servers that send out bogus requests. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 22 04:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8lt-0002Dj-H8; Thu, 22 Nov 2007 04:54:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IutMm-00055C-Uy for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutMm-00054J-KG for tls@ietf.org; Wed, 21 Nov 2007 12:28:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IutMj-0004WU-26 for tls@ietf.org; Wed, 21 Nov 2007 12:28:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,447,1188770400"; d="scan'208";a="158442114" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 18:27:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALHRfBe013610; Wed, 21 Nov 2007 18:27:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALHROZZ000834; Wed, 21 Nov 2007 17:27:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:27:23 +0100 Received: from [10.32.244.68] ([10.32.244.68]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:27:23 +0100 In-Reply-To: <20071121165258.6F56533C2B@delta.rtfm.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: max pritikin Subject: Re: [TLS] DSA/SHA-1, and OIDs Date: Wed, 21 Nov 2007 11:26:53 -0600 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Nov 2007 17:27:23.0592 (UTC) FILETIME=[C73A2480:01C82C63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2863; t=1195666061; x=1196530061; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20[TLS]=20DSA/SHA-1,=20and=20OIDs |Sender:=20; bh=3e8YIUVBxBvBewuJQ5w8eqApu9UR0DtUzm2J6aHeGtg=; b=K6yXAEuRBNkpFD0EMZCFkkz2UZR5hA7RWL+bA+hLnOMQ9Cd/2sxtMniIyRxoF1E+WsrT9Pup 66eHD7zHSlEs0HwG697Vmft2DXX9kNZFKWrseAOAShfSyhd0Z47FhNci; Authentication-Results: ams-dkim-2; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Thu, 22 Nov 2007 04:54:55 -0500 Cc: "ietf-pkix@imc.org" , Paul Hoffman , "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 Placing usage instructions in the certificate does not enforce the verifying parties behavior any more than protocol handshakes would. Also it maybe more difficult if the certificate verification operations are distinct from the protocol hashing operations. Paul's example of key usage seems to be very topical. Long lived device certificates would suffer from this approach. The certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc etc etc) are profiled and baked well in advance. Attempting to expand those profiles to limit the use of the credentials to particular hash algorithms would be problematic. - max On Nov 21, 2007, at 10:52 AM, Eric Rescorla wrote: > > At Wed, 21 Nov 2007 08:50:33 -0800, > Paul Hoffman wrote: >> >> At 6:57 AM -0800 11/21/07, Eric Rescorla wrote: >>> We're talking about two different kinds of downgrade here. >>> The S/MIME anti-downgrade issue is about signature stripping >>> when multiple signatures are applied. The downgrade issue >>> I'm concerned about is straight-line forgery: Alice always >>> signs with digest algorithm H1: she then generates a signature >>> over some message M where H1(M) = X. The attacker compromises H2 >>> and forms M' st. H2(M2) = X. He can then craft a new message >>> apparently signed by Alice. There's no act that Alice can take >>> involving H1 and her signature algorithm that can prevent this: >>> it has to be in information available to a verifier who has only >>> the cert and a candidate signature. >> >> The proposed solution of an extension that says which hash functions >> can be used with the public key in a cert has a few flaws. First, it >> means that all CAs must understand the safety of all the hash >> algorithms out there to know to not list H2. > > Not really, no. As I said, I think this is pretty much an issue > of matching SHA variant to DSA key size. I agree that this is > imperfect, but the situation is imperfect. > > >> In some sense, they must >> all predict the future as well, because they might list H2 today and >> then next year find out that some set of Mallorys have compromised >> it. Further, this puts CAs into the position of saying what can and >> cannot be done with a public key; "key usage" has proven this to be a >> disaster. > > This strikes me as a pretty different case. > > >> Instead, we have to assume that all relying parties need to know >> which of the hash algorithms that they know how to use are >> trustworthy, and which aren't. Hopefully, for any that are not, the >> relying party simply forgets how to use it, or marks it as poisoned. > > This seems highly undesirable from the perspective of the > verifying party, who has opinions about what digests he > will use, but who needs the relying party to enforce it. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 22 04:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8lu-0002Dt-GQ; Thu, 22 Nov 2007 04:54:58 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iv0le-0000vh-0L for tls-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 20:22:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0lb-0000t8-Sl for tls@ietf.org; Wed, 21 Nov 2007 20:22:09 -0500 Received: from mailipbo.ntcif.telstra.com.au ([202.12.233.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv0la-0004jr-F5 for tls@ietf.org; Wed, 21 Nov 2007 20:22:07 -0500 Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 22 Nov 2007 12:21:56 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 04E83FFA1; Thu, 22 Nov 2007 12:21:55 +1100 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA08619; Thu, 22 Nov 2007 12:21:55 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 12:21:54 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] DSA/SHA-1, and OIDs Date: Thu, 22 Nov 2007 12:21:53 +1100 Message-ID: <6215401E01247448A306C54F499111F20383906A@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <6215401E01247448A306C54F499111F202C39470@WSMSG2103V.srv.dir.telstra.com> Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAF1tZzA= References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F202C39470@WSMSG2103V.srv.dir.telstra.com> From: "Manger, James H" To: , X-OriginalArrivalTime: 22 Nov 2007 01:21:54.0880 (UTC) FILETIME=[116FEC00:01C82CA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Thu, 22 Nov 2007 04:54:55 -0500 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: , Content-Type: multipart/mixed; boundary="===============0560406675==" Errors-To: tls-bounces@lists.ietf.org --===============0560406675== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEVrci4NClJGQyA0MDU1IOKAnEFkZGl0aW9uYWwgUlNBIEFsZ29yaXRobXMg YW5kIElkZW50aWZpZXJz4oCdDQrCpzgg4oCcU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ0gZGVz Y3JpYmVzIHRoZSByZWFzb25zIGZvciBiaW5kaW5nDQphIHB1YmxpYyBrZXkgdG8gYSBzaWduYXR1 cmUgYWxnb3JpdGhtLiBJdCB0YWxrcyBhYm91dCBSU0Ega2V5cywNCmJ1dCB0aGUgbG9naWMgYWxz byBhcHBsaWVzIHRvIERTQSBrZXlzIC0tIGluIGZhY3QgdG8gYW55IGNyeXB0byBrZXkuDQoNCuKA nEdlbmVyYWxseSwgZ29vZCBjcnlwdG9ncmFwaGljIHByYWN0aWNlIGVtcGxveXMgYSBnaXZlbiBS U0Ega2V5IHBhaXINCmluIG9ubHkgb25lIHNjaGVtZS4gIFRoaXMgcHJhY3RpY2UgYXZvaWRzIHRo ZSByaXNrIHRoYXQgdnVsbmVyYWJpbGl0eQ0KaW4gb25lIHNjaGVtZSBtYXkgY29tcHJvbWlzZSB0 aGUgc2VjdXJpdHkgb2YgdGhlIG90aGVyLCBhbmQgbWF5IGJlDQplc3NlbnRpYWwgdG8gbWFpbnRh aW4gcHJvdmFibGUgc2VjdXJpdHkuICBXaGlsZSBQS0NTICMxIFZlcnNpb24gMS41DQpbUDF2MS41 XSBoYXMgYmVlbiBlbXBsb3llZCBmb3IgYm90aCBrZXkgdHJhbnNwb3J0IGFuZCBkaWdpdGFsDQpz aWduYXR1cmUgd2l0aG91dCBhbnkga25vd24gYmFkIGludGVyYWN0aW9ucywgc3VjaCBhIGNvbWJp bmVkIHVzZSBvZg0KYW4gUlNBIGtleSBwYWlyIGlzIG5vdCByZWNvbW1lbmRlZCBpbiB0aGUgZnV0 dXJlLiAgVGhlcmVmb3JlLCBhbiBSU0ENCmtleSBwYWlyIHVzZWQgZm9yIFJTQVNTQS1QU1Mgc2ln bmF0dXJlIGdlbmVyYXRpb24gc2hvdWxkIG5vdCBiZSB1c2VkDQpmb3Igb3RoZXIgcHVycG9zZXMu ICBGb3Igc2ltaWxhciByZWFzb25zLCBvbmUgUlNBIGtleSBwYWlyIHNob3VsZA0KYWx3YXlzIGJl IHVzZWQgd2l0aCB0aGUgc2FtZSBSU0FTU0EtUFNTIHBhcmFtZXRlcnMgKGV4Y2VwdCBwb3NzaWJs eQ0KZm9yIHRoZSBzYWx0IGxlbmd0aCkuICBMaWtld2lzZSwgYW4gUlNBIGtleSBwYWlyIHVzZWQg Zm9yIFJTQUVTLU9BRVANCmtleSB0cmFuc3BvcnQgc2hvdWxkIG5vdCBiZSB1c2VkIGZvciBvdGhl ciBwdXJwb3Nlcy4gIEZvciBzaW1pbGFyDQpyZWFzb25zLCBvbmUgUlNBIGtleSBwYWlyIHNob3Vs ZCBhbHdheXMgYmUgdXNlZCB3aXRoIHRoZSBzYW1lIFJTQUVTLQ0KT0FFUCBwYXJhbWV0ZXJzLuKA nQ0KDQpUaGVyZSBhY3R1YWxseSBoYXZlIGJlZW4g4oCca25vd24gYmFkIGludGVyYWN0aW9uc+KA nSB3aXRoIFBLQ1MgIzEgdjEuNS4NClRoZSDigJxtaWxsaW9uLW1lc3NhZ2UgYXR0YWNr4oCdIGFn YWluc3QgUEtDUyAjMSB2MS41IGJsb2NrLXR5cGUgMiBlbmNyeXB0aW9uDQppbiBTU0wgY2FuIGJl IHVzZWQgdG8gY3JlYXRlIGEgUEtDUyAjMSB2MS41IGJsb2NrLXR5cGUgMSBzaWduYXR1cmUuDQpB IGNlcnRpZmljYXRlIGJpbmRpbmcgdGhlIFNTTCBzZXJ2ZXLigJlzIHB1YmxpYyBlbmNyeXB0aW9u IGtleSB0byBhDQpzcGVjaWZpYyBlbmNyeXB0aW9uIGFsZ29yaXRobSB3b3VsZCBwcmV2ZW50IHRo ZSBmb3JnZWQgc2lnbmF0dXJlIGZyb20NCmJlaW5nIGFjY2VwdGVkLg0KSW4gdGhpcyBjYXNlLCBh IChjcml0aWNhbCkga2V5IHVzYWdlIGV4dGVuc2lvbiB3b3VsZCBhbHNvIHN1ZmZpY2UuDQoNCklu IHByYWN0aXNlLCB0aGUgYmVuZWZpdHMgb2YgYmVpbmcgYWJsZSB0byB1c2UgYSBzaW5nbGUga2V5 IChmb3INCnNpZ25pbmcgYW5kIGRlY3J5cHRpbmcgZW1haWwsIGZvciBhY3RpbmcgYXMgYSBUTFMg c2VydmVyIGFuZCBjbGllbnQsDQpmb3Igc2lnbmluZyBYTUwgYW5kIGF1dGhlbnRpY2F0aW5nIGlu IFRMUykgb2Z0ZW4gZmFyIG91dHdlaWdoIHRoZQ0KcmlzayBvZiBiYWQgaW50ZXJhY3Rpb25zLiBU aGF0IGlzLCB0aGUgcmlzayB0aGF0IGFuIG9wZXJhdGlvbiBpbiBvbmUNCmNvbnRleHQgYmVpbmcg bWlzaW50ZXJwcmV0ZWQgYXMgYW4gb3BlcmF0aW9uIGluIGEgZGlmZmVyZW50IGNvbnRleHQuDQri gJxPZnRlbuKAnSDigJxpbiBwcmFjdGlzZeKAnSBpcyBub3Qg4oCcYWx3YXlz4oCdIOKAnGZvciBh bGwgdXNlcnPigJ0g4oCcaW4gYWxsIGNpcmN1bXN0YW5jZXPigJ0uDQoNCktleSB1c2FnZSAoMSks IGtleSBwdXJwb3NlICgyKSBhbmQgc2lnbmF0dXJlL2VuY3J5cHRpb24vdHJhbnNwb3J0DQphbGdv cml0aG0gKDMpIGFyZSByZWFsbHkgdGhyZWUgcG9pbnRzIG9uIGEgY29udGludXVtDQpmb3IgZ2l2 aW5nIHRoZSBjZXJ0aWZpY2F0ZSBob2xkZXIgY29udHJvbCBvdmVyIHdoZXJlIHRoZQ0Ka2V5LT5u YW1lIGJpbmRpbmcgKHdoaWNoIGlzIHRoZSBjb3JlIG9mIHRoZWlyIGNlcnRpZmljYXRlKSB3aWxs IGJlIHVzZWQuDQpUaGVyZSBpcyBubyB0aGVvcmV0aWNhbCByZWFzb24gdG8gc3VwcG9ydCBjb250 cm9scyAxICYgMiwgYnV0IG5vdCAzLg0KDQpTbyB3ZSBjb21lIGRvd24gdG8gcHJhY3RpY2FsIG9i amVjdGlvbnM6DQoqIGNvbnRyb2wgMyAoZWcgb3ZlciBzaWduYXR1cmUgaGFzaCkgd2lsbCBiZSB1 c2VkIGxlc3MgdGhhbg0KICBjb250cm9scyAxICYgMiAoa2V5IHVzYWdlICYgcHVycG9zZSkgLS0g cGVyaGFwcyBpbmZyZXF1ZW50bHkNCiAgZW5vdWdoIHRoYXQgaXQgZG9lc27igJl0IHdhcnJhbnQg aW5jbHVzaW9uIGluIGEgc3RhbmRhcmQNCiAgZm9yIEludGVybmV0IHVzZTsNCioga2V5IHVzYWdl IGhhcyBiZWVuIGEgZGlzYXN0ZXIgKGFjY29yZGluZyB0byBQYXVsIEhvZmZtYW4pLA0KICBpbXBs eWluZyB0aGF0IGRlcHJlY2F0aW5nIHRoZSBleGlzdGluZyBjb250cm9scyB3b3VsZCBiZQ0KICBi ZXR0ZXIgdGhhbiBhZGRpbmcgYW5vdGhlciAodGhvdWdoIHN1Y2ggZGVwcmVjYXRpb24gd291bGQN CiAgY2F1c2UgdG9vIGJpZyBhIHN0b3JtIHRvIGNvbnRlbXBsYXRlKTsNCiogbWVzc3kvcGFpbmZ1 bC9hd2t3YXJkIHRvIGltcGxlbWVudCBnaXZlbiB0aGUgY29tbW9uIGRpdmlkZQ0KICBiZXR3ZWVu IGNyeXB0byBsaWJyYXJpZXMsIGNlcnQgcHJvY2Vzc2luZyBsaWJyYXJpZXMgYW5kDQogIGFwcGxp Y2F0aW9uIGxvZ2ljICh0aGlzIGFyZWEgaXMgbm90IG15IGZvcnRlLCBidXQgdGhhdCBpcw0KICB0 aGUgaW1wcmVzc2lvbiBJIHJlbWVtYmVyIGZyb20gU3RlZmFuIFNhbnRlc3NvbiAtLQ0KICB0aG91 Z2ggaXQgbWF5IG9ubHkgY29uY2VybiB0aGUgcGxhY2VtZW50IG9mIHRoZSBjb250cm9sDQogIGlu IHN1YmplY3RQdWJsaWNLZXlJbmZvIHZzIGluIGFuIGV4dGVuc2lvbik7DQoqIGV4aXN0aW5nIHB1 YmxpYyBDQXMgZG9u4oCZdCAodGhhdCBJIGhhdmUgc2VlbikgYWxsb3cgY2VydGlmaWNhdGUNCiAg aG9sZGVycyB0byBhcmJpdHJhcmlseSBzcGVjaWZ5IHRoZSBrZXkgdXNhZ2Ugb3IgcHVycG9zZXMg dGhleSB3YW50DQogIChvdGhlciB0aGFuIGNob29zaW5nIGEgc2VydmVyIG9yIGNvZGUgc2lnbmlu ZyBjZXJ0KSBzbw0KICB0aGV5IGFyZSB1bmxpa2VseSB0byBhbGxvdyBhbGdvcml0aG1zIHRvIGJl IHNwZWNpZmllZCwNCiAgd2hpY2ggbWVhbnMgYW55IGV4dGVuc2lvbiBoYXMgbGl0dGxlIGhvcGUg b2Ygd2lkZXNwcmVhZCBkZXBsb3ltZW50Ow0KKiBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB3aGVy ZSBhIGNlcnRpZmljYXRlIGhvbGRlciB3YW50cw0KICBvbmUgYWxnb3JpdGhtLCBidXQgYSByZWx5 aW5nIHBhcnR5IHdhbnRzIGFub3RoZXINCiAgKHRoaXMgaXMgYSBjbGFzaCBvZiBkZWxpYmVyYXRl IGNyeXB0byBjaG9pY2VzIChwb2xpY3kpLA0KICBub3Qgc3ludGF4IGRldGFpbHMgLS0gYnV0IHRo ZSByZXN1bHRpbmcgZnJ1c3RyYXRpb24gaXMgc2ltaWxhcikuDQoNCk15IGd1dCBmZWVsIGlzIHRo YXQgYSBuZXcgZXh0ZW5zaW9uIGhvbGRpbmcg4oCcYWxnb3JpdGhtIGlkZW50aWZpZXINCm1hdGNo aW5nIHJ1bGVz4oCdIHNob3VsZCBiZSBkZWZpbmVkLg0KTGlzdCBoYXNoOlNIQS0xIGluIHRoZSBl eHRlbnNpb24sIG1hcmsgaXQgY3JpdGljYWwsDQphbmQgcHJheSB0aGF0IHRoZSBvdGhlciBlbmQg dW5kZXJzdGFuZHMuDQoNCi0tLS0tLS0tLS0NCkZyb206IG93bmVyLWlldGYtcGtpeEBtYWlsLmlt Yy5vcmcgW21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXSBPbiBCZWhhbGYgT2Yg RXJpYyBSZXNjb3JsYQ0KDQogCU15IGNsYWltIGlzIHRoYXQgZm9yIHNlY3VyaXR5IHJlYXNvbnMg aXQncyBuZWNlc3NhcnkgZm9yIERTQQ0KIAljZXJ0cyB0byBpbmRpY2F0ZSB0aGUgaGFzaCBhbGdv cml0aG0ocykgdGhhdCBtYXkgYmUgdXNlZCB3aXRoDQogCXRoZSBwdWJsaWMga2V5IGNvbnRhaW5l ZCBpbiB0aGUgY2VydC4gVGhpcyBwcmV2ZW50cyBoYXNoDQogCWFsZ29yaXRobSBzdWJzdGl0dXRp b24gaW4gc2lnbmF0dXJlcyBmb3JtZWQgd2l0aCB0aGF0IGtleQ0KCShvciByYXRoZXIgdGhlIHBy aXZhdGUga2V5IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhhdCBrZXkpLiBEbw0KIAl5b3UgYWdyZWUg d2l0aCB0aGlzPw0KDQotRWtyDQo= --===============0560406675== 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 --===============0560406675==-- From tls-bounces@lists.ietf.org Thu Nov 22 06:54:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAd1-0006Sr-2b; Thu, 22 Nov 2007 06:53:55 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IvAcz-0006Sh-Bh for tls-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 06:53:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvAcy-0006SZ-9N for tls@ietf.org; Thu, 22 Nov 2007 06:53:52 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvAcu-00060N-AE for tls@ietf.org; Thu, 22 Nov 2007 06:53:52 -0500 Received: from tau.invalid ([134.147.40.222]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IvAch13a0-0004GS; Thu, 22 Nov 2007 12:53:38 +0100 Received: by tau.invalid (Postfix, from userid 1000) id ABEF71EBFB; Thu, 22 Nov 2007 12:53:33 +0100 (CET) Date: Thu, 22 Nov 2007 12:53:33 +0100 From: Bodo Moeller To: max pritikin Subject: Re: [TLS] DSA/SHA-1, and OIDs Message-ID: <20071122115333.GA12388@tau.invalid> Mail-Followup-To: Bodo Moeller , max pritikin , Eric Rescorla , "ietf-pkix@imc.org" , Paul Hoffman , "tls@ietf.org" References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.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: V01U2FsdGVkX18zKt0lxjyIewvrhwWW2emut9PolZM+9B+wnLy Iw6H1zyIh4UUNj/QXHqZlqnysoNPCzeYwBH03+p0b1relKtP7I 71YtPx8ePA6hBJoOIULhSach/Ff0OGb1Rb1GnGDT3Onda8oGNt 8Kw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "ietf-pkix@imc.org" , "tls@ietf.org" , Paul Hoffman 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, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote: > Placing usage instructions in the certificate does not enforce the > verifying parties behavior any more than protocol handshakes would. It does provide authenticated usage information to the verifying parties, though. Without such information, verifying parties cannot tell if the observed usage in any given handshake should be considered suspicious (and thus rejected) or is benign. > Also it maybe more difficult if the certificate verification > operations are distinct from the protocol hashing operations. Paul's > example of key usage seems to be very topical. > > Long lived device certificates would suffer from this approach. The > certificates on these devices (cable modems, wimax, IEEE 802.1AR, etc > etc etc) are profiled and baked well in advance. Attempting to expand > those profiles to limit the use of the credentials to particular hash > algorithms would be problematic. One the one hand, you wouldn't *have* to use such hash algorithm constraints in long-lived certificates for which you consider it problematic. On the other hand, this is where it is particularly important to specify such constraints. (You don't really need hash constraints to prevent SHA-1 use of your (EC)DSA key that is only meant to be used with SHA-256: Except with tiny probability, none of the signatures that you ever generate using SHA-256 could be interpreted as a SHA-1-based signature, unless the (EC)DSA subgroup you are using is too small.) Consider the following scenario. The SHA-3 competition is now open. So one interesting business idea is to take the signature from any certificate signed by some high-profile ECDSA or DSA root certificate that is far away from expiring, and then to engineer a new hash algorithm that appears sound and secure, except that it happens to have a particularly interesting pre-image for the hash value from said non-root certificate's signature: namely, a preimage that would provide you with a certificate of your own with generous basicConstraints, simply by reusing the previous signature coming from the CA. So you submit this hash function to the SHA-3 competition, provide a reference implementation and hope that it ends up in relying parties' software. If this plan works out, suddenly you have become a high-profile CA yourself -- even though in this particular example none of the cryptographic algorithms involved would have to be insecure in itself. If your are ambitious about security, then to avoid hash algorithm substitution attacks of any kind, generally you'd want to limit the use of any given key beforehand if at all possible. I don't agree that long-lived certificates are a severe obstacle to this. If you want algorithm flexibility for everyday use, then you can introduce an intermediate CA whose certificate is updated sufficiently often, always specifying the appropriate algorithm to use, while the root CA would continue to use the initially chosen hash algorithms for the few certificates that it signs. If there is ever a time where you want to completely exchange the set of allowed algorithms, why not take the extra step and exchange the long-lived certificate as well? Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 22 11:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvEuX-0004eA-Cj; Thu, 22 Nov 2007 11:28:17 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IvEuW-0004b7-6g for tls-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvEuV-0004aA-Oq for TLS@lists.ietf.org; Thu, 22 Nov 2007 11:28:15 -0500 Received: from mailrelay.tu-graz.ac.at ([129.27.2.202] helo=mailrelay.tugraz.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvEuQ-00064m-Kq for TLS@lists.ietf.org; Thu, 22 Nov 2007 11:28:15 -0500 Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.2/8.14.2) with ESMTP id lAMGRgjW009938; Thu, 22 Nov 2007 17:27:42 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.3.2 mailrelay2.tugraz.at lAMGRgjW009938 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tugraz.at; s=mailrelay; t=1195748864; bh=+BHu/zksOvynETwX0vVfzn+Ea2726fh6jx59g lnY2sI=; h=X-Virus-Scanned:Message-ID:From:To:Cc:References:Subject: Date:MIME-Version:Content-Type:Content-Transfer-Encoding: X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-Spam-Scanner: X-Spam-Score-relay:X-Scanned-By; b=UvWoa7GWB8tNSBCB54m8s9dSGSGfnXh XhRsulCeawFFk/mOAQSZ/z2+Q4oV2tAmwQ91PexYtcLfYUJWPEf1lSi6vk8peOGEMD4 QO547rWJ4omiK6dZql/7iO/GOBHTJtAFRLa9sO1JcI6z2AgPtDQxNGdQN9RcpoYrNrq HLQJKs= Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 2E6DF19C001; Thu, 22 Nov 2007 17:27:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at iaik.tugraz.at Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor.iaik.tugraz.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXTtAOOInssx; Thu, 22 Nov 2007 17:27:42 +0100 (CET) Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP; Thu, 22 Nov 2007 17:27:42 +0100 (CET) Received: from localhost [127.0.0.1] by vesta (IAIK S/MIME Mapper 2.02 12 June 2002); Do, 22 Nov 2007 17:27:42 +0100 Message-ID: <027d01c82d24$9b1ada40$6d981b81@iaik.tugraz.at> From: "Dieter Bratko" To: "Peter Gutmann" , References: Subject: Re: [TLS] CertificateRequest Date: Thu, 22 Nov 2007 17:27:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Scanner: SpamAssassin 3.002003 X-Spam-Score-relay: 1.4 X-Scanned-By: MIMEDefang 2.63 on 129.27.10.19 X-Spam-Score: 2.7 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: PSharkey@cleo.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 > is just a pathological implementation that's Unfortunetely not in these cases. > ballpark of the set of automatically trusted CAs for Windows, > depending on which root cert updates have been applied). That's what I have done to simulate the behaviour (since the servers have not been publicly accessible): I installed IIS on my machine, requested client authentication with default trust settings and IIS sent all the certificates in one large record. > I can't imagine that any server would really trust 160 different CAs > to authorise access. Yes, but as you say below it also may occur unintentionally. For the client -- at the time when receiving a large list -- it makes no difference if the server has sent it because of misconfiguration or because he actually trusts 160 or more CAs :-) > I've seen servers that send out cert requests without the > admins even knowing that they're doing it You are right. And also the trust pool -- and with it the list sent within the CertificateRequest message -- may grow automatically without interaction and knowing of the admins. In one of the cases (where already over 200 certificates have been sent) it helped to contact the admin and ask him to remove certificates from the list. However, you won't do this anytime you find large list of CAs. We were asked if there is a way for the client to tell the server to not send all its CAs, but this is not possible. > I've found that simply ignoring the contents of the cert request > seems to work pretty well. Since there are servers sending out > nonsensical requests, the safest thing to do is just record that a > request for a cert exists. If you have a cert, send it and let the > server sort it out. If you don't, send a no-cert response, which > deals nicely with servers that send out bogus requests. It might require additional configuration options on the client side, but you are right again. However, just when doing so a (large) CA list sent by the server is not required at all and only waste of bandwith, which especially may be of concern in constrained environments. Regards, Dieter ----- Original Message ----- From: Peter Gutmann To: Dieter.Bratko@iaik.tugraz.at ; TLS@lists.ietf.org Cc: PSharkey@cleo.com Sent: Thursday, November 22, 2007 10:08 AM Subject: Re: [TLS] CertificateRequest "Dieter Bratko" writes: >recently we have observed problems with SSL/TLS servers that send large >numbers of certificate authorities wihtin their CertificateRequest message. >For instance, one server sent 152 CA names (21613 bytes), another sent 164 >(29293 bytes) within one record without fragmentation... The client may >have >to check if any of its keys is appropriate for any of these 164 CAs >received >from the server. My suspicion is that this is just a pathological implementation that's iterating through all the CAs it knows of (the count seems to be in the ballpark of the set of automatically trusted CAs for Windows, depending on which root cert updates have been applied). I can't imagine that any server would really trust 160 different CAs to authorise access. To support this, I've seen servers that send out cert requests without the admins even knowing that they're doing it, and the servers certainly don't want or even know what to do with a client cert when they send the request. >Have there ever been thoughts about, or would this group support a proposal >for an extension allowing the client to first announce the DNs of the CAs >for >which it is able to fulfill a CertificateRequest? Usually a client only has >a >few number of keys (for instance 1 or 2) to may be used for client >authentication. I've found that simply ignoring the contents of the cert request seems to work pretty well. Since there are servers sending out nonsensical requests, the safest thing to do is just record that a request for a cert exists. If you have a cert, send it and let the server sort it out. If you don't, send a no- cert response, which deals nicely with servers that send out bogus requests. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 22 11:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFLU-0003aZ-57; Thu, 22 Nov 2007 11:56:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IvFLT-0003WB-9t for tls-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:56:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFLT-0003Vj-08 for TLS@lists.ietf.org; Thu, 22 Nov 2007 11:56:07 -0500 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvFLP-0006wi-Ce for TLS@lists.ietf.org; Thu, 22 Nov 2007 11:56:06 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 745FE10027FE5; Thu, 22 Nov 2007 11:55:38 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFqDnd1RdvkJ; Thu, 22 Nov 2007 11:55:34 -0500 (EST) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Thu, 22 Nov 2007 11:55:34 -0500 (EST) To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Dana Zhao Date: Thu, 22 Nov 2007 11:55:38 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 11/22/2007 11:55:29 AM, Serialize complete at 11/22/2007 11:55:29 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Michael Mezheritsky , Rob Dugal , Rob Williams , Elliott Mazzuca Subject: [TLS] Numbers for GCM ciphersuites? 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="===============1250675165==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1250675165== Content-Type: multipart/alternative; boundary="=_alternative 005D060F8525739B_=" This is a multipart message in MIME format. --=_alternative 005D060F8525739B_= Content-Type: text/plain; charset="US-ASCII" Hi all, Did anyone implement the GCM ciphersuites for TLS1.2? For example, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 What number do you use for them? I want to do interoperating test on them. Thanks. Regards, ----------------------------------------------- Dana Zhao Software Developer Certicom Corp. EMAIL: dzhao@certicom.com PHONE: (905) 501-3822 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 005D060F8525739B_= Content-Type: text/html; charset="US-ASCII"
Hi all,

Did anyone implement the GCM ciphersuites for TLS1.2?

For example,

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
       
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384


What number do you use for them? I want to do interoperating test on them.

Thanks.

Regards,
-----------------------------------------------
Dana Zhao
Software Developer
Certicom Corp.
EMAIL: dzhao@certicom.com
PHONE: (905) 501-3822
FAX  : (905) 507-4230
WEBSITE: www.certicom.com --=_alternative 005D060F8525739B_=-- --===============1250675165== 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 --===============1250675165==-- From tls-bounces@lists.ietf.org Fri Nov 23 03:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvULR-00075o-V1; Fri, 23 Nov 2007 03:57:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IvULP-00075U-AG for tls-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 03:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvULO-00075M-Vg for TLS@lists.ietf.org; Fri, 23 Nov 2007 03:57:02 -0500 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvULJ-00006x-5Q for TLS@lists.ietf.org; Fri, 23 Nov 2007 03:57:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 53BD81840A; Fri, 23 Nov 2007 21:56:53 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gq4WCfSmwF3; Fri, 23 Nov 2007 21:56:53 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0557F1840B; Fri, 23 Nov 2007 21:56:52 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id F2A61E080B5; Fri, 23 Nov 2007 21:56:39 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1IvUL1-0004WK-SC; Fri, 23 Nov 2007 21:56:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Dieter.Bratko@iaik.tugraz.at, pgut001@cs.auckland.ac.nz, TLS@lists.ietf.org Subject: Re: [TLS] CertificateRequest In-Reply-To: <027d01c82d24$9b1ada40$6d981b81@iaik.tugraz.at> Message-Id: Date: Fri, 23 Nov 2007 21:56:39 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: PSharkey@cleo.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 "Dieter Bratko" writes: >However, just when doing so a (large) CA list sent by the server is not >required at all and only waste of bandwith, which especially may be of >concern in constrained environments. Hmm, I see the potential for a nasty catch-22 here: Any server that's stupid enough to send a list of 150-200 CAs in its request probably isn't going to know about, or honour, the "Don't send me a huge long list of junk" extension from the client :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 23 10:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvaL6-0006jd-Cz; Fri, 23 Nov 2007 10:21:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IvaL4-0006jK-R1 for tls-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 10:21:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvaL4-0006iL-An for tls@ietf.org; Fri, 23 Nov 2007 10:21:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvaL3-0004IC-PL for tls@ietf.org; Fri, 23 Nov 2007 10:21:06 -0500 Received: from [10.20.30.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANFL3pI025848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 08:21:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071122115333.GA12388@tau.invalid> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.com> <20071122115333.GA12388@tau.invalid> Date: Fri, 23 Nov 2007 07:20:46 -0800 To: "ietf-pkix@imc.org" , "tls@ietf.org" From: Paul Hoffman Subject: Re: [TLS] DSA/SHA-1, and OIDs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 At 12:53 PM +0100 11/22/07, Bodo Moeller wrote: >On Wed, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote: > >> Placing usage instructions in the certificate does not enforce the >> verifying parties behavior any more than protocol handshakes would. > >It does provide authenticated usage information to the verifying >parties, though. Um, so? It is "authenticated" to be from a party that is not the signer. In most situations, my CA doesn't have the slightest idea what I am doing, or want to be doing, with my public key. >Without such information, verifying parties cannot >tell if the observed usage in any given handshake should be considered >suspicious (and thus rejected) or is benign. And with such information from my CA, they still have no idea. >Consider the following scenario. The SHA-3 competition is now open. >So one interesting business idea is to take the signature from any >certificate signed by some high-profile ECDSA or DSA root certificate >that is far away from expiring, and then to engineer a new hash >algorithm that appears sound and secure, except that it happens to >have a particularly interesting pre-image for the hash value from said >non-root certificate's signature: namely, a preimage that would >provide you with a certificate of your own with generous >basicConstraints, simply by reusing the previous signature coming from >the CA. So you submit this hash function to the SHA-3 competition, >provide a reference implementation and hope that it ends up in relying >parties' software. If this plan works out, suddenly you have become a >high-profile CA yourself -- even though in this particular example >none of the cryptographic algorithms involved would have to be >insecure in itself. Even if there were any "high-profile ECDSA or DSA root certificates", they would contain the signature algorithm, which includes the hash used, ecdsa-with-SHA1 or id-dsa-with-sha1, and that is covered by the signature itself. This is no different than RSA. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 23 11:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivbi8-0003wf-2c; Fri, 23 Nov 2007 11:49:00 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ivbi6-0003wS-8X for tls-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:48:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivbi5-0003wF-MN for TLS@lists.ietf.org; Fri, 23 Nov 2007 11:48:57 -0500 Received: from mailrelay.tu-graz.ac.at ([129.27.2.202] helo=mailrelay.tugraz.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivbi0-0006B2-F0 for TLS@lists.ietf.org; Fri, 23 Nov 2007 11:48:57 -0500 Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.2/8.14.2) with ESMTP id lANGmSFv006986; Fri, 23 Nov 2007 17:48:28 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.3.2 mailrelay2.tugraz.at lANGmSFv006986 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tugraz.at; s=mailrelay; t=1195836510; bh=m0lyRZARJL7Q3r+hwdPfsjuKHtCppe5Gz3238 1z2WiI=; h=X-Virus-Scanned:Message-ID:From:To:Cc:References:Subject: Date:MIME-Version:Content-Type:Content-Transfer-Encoding: X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-Spam-Scanner: X-Spam-Score-relay:X-Scanned-By; b=QZFpDq2UKWCSXBgDaDWW/ZfW8lhTuzs HFMGre1XQJcX6qxnRIyZB2vXdpVI6AM5cRGTu8TVB0iHgfi+aB1mDT+VaY/1n3xHZ1k 8thd11wJ7dw1nPOqsiokZSXHNYOdfm4Kz6QkHYwA/65QzvL+pqqO6Uan6vWDt3zoApk Frlw4s= Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 6EE4119C001; Fri, 23 Nov 2007 17:48:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at iaik.tugraz.at Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor.iaik.tugraz.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuyWyWG9YM+l; Fri, 23 Nov 2007 17:48:28 +0100 (CET) Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP; Fri, 23 Nov 2007 17:48:28 +0100 (CET) Received: from localhost [127.0.0.1] by vesta (IAIK S/MIME Mapper 2.02 12 June 2002); Fr, 23 Nov 2007 17:48:28 +0100 Message-ID: <00cf01c82df0$ac2cd780$6d981b81@iaik.tugraz.at> From: "Dieter Bratko" To: , References: Subject: Re: [TLS] CertificateRequest Date: Fri, 23 Nov 2007 17:48:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Scanner: SpamAssassin 3.002003 X-Spam-Score-relay: 1.4 X-Scanned-By: MIMEDefang 2.63 on 129.27.10.19 X-Spam-Score: 2.7 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: PSharkey@cleo.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 > Hmm, I see the potential for a nasty catch-22 here: Any server > that's stupid enough to send a list of 150-200 CAs in its request > probably isn't going to know about, or honour, the "Don't send > me a huge long list of junk" extension from the client :-). Do not call the poor server stupid - it is just doing what it has been configured to do :-). The same server -- if (by default) supporting such an (obviously remaining hypothetical :-) extension -- with the same (maybe careless) configuration settings would not send the long list. Regards, Dieter _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 23 12:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivcne-0003nE-FL; Fri, 23 Nov 2007 12:58:46 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ivcnc-0003kN-FZ for tls-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:58:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivcnc-0003jE-5P for tls@ietf.org; Fri, 23 Nov 2007 12:58:44 -0500 Received: from lain.randombit.net ([66.179.181.40] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvcnZ-0000Uo-Rx for tls@ietf.org; Fri, 23 Nov 2007 12:58:44 -0500 Received: by mail.randombit.net (Postfix, from userid 501) id B3E1D3B6298; Fri, 23 Nov 2007 12:58:43 -0500 (EST) Date: Fri, 23 Nov 2007 12:58:43 -0500 From: Jack Lloyd To: "ietf-pkix@imc.org" , "tls@ietf.org" Subject: Re: [TLS] DSA/SHA-1, and OIDs Message-ID: <20071123175843.GR7280@randombit.net> Mail-Followup-To: "ietf-pkix@imc.org" , "tls@ietf.org" , Bodo Moeller , max pritikin , Eric Rescorla , Paul Hoffman References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.com> <20071122115333.GA12388@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071122115333.GA12388@tau.invalid> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: max pritikin , Paul Hoffman 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 Thu, Nov 22, 2007 at 12:53:33PM +0100, Bodo Moeller wrote: > If your are ambitious about security, then to avoid hash algorithm > substitution attacks of any kind, generally you'd want to limit the > use of any given key beforehand if at all possible. I don't agree > that long-lived certificates are a severe obstacle to this. If you > want algorithm flexibility for everyday use, then you can introduce an > intermediate CA whose certificate is updated sufficiently often, The idea to "introduce an intermediate CA" seems to assume that either your CA will issue you new certificates as needed (and I'm sure they would be happy to do so, at $X00 per cert), or they will issue you a CA cert that allows you to generate new certificates when you want to (unlikely), or you form your own root CA (with all the many problems that entails). Am I missing something about this approach? -Jack _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 23 13:53:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdeq-0008NW-81; Fri, 23 Nov 2007 13:53:44 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ivdeo-0008NO-VL for tls-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 13:53:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdeo-0008NG-LL for tls@ietf.org; Fri, 23 Nov 2007 13:53:42 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivdeh-0002VU-Ot for tls@ietf.org; Fri, 23 Nov 2007 13:53:42 -0500 Received: from tau.invalid (p508EB083.dip0.t-ipconnect.de [80.142.176.131]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Ivdee0ENX-0002xb; Fri, 23 Nov 2007 19:53:33 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 3F47A1EBF0; Fri, 23 Nov 2007 19:53:31 +0100 (CET) Date: Fri, 23 Nov 2007 19:53:30 +0100 From: Bodo Moeller To: Paul Hoffman Subject: Re: [TLS] DSA/SHA-1, and OIDs Message-ID: <20071123185330.GA21317@tau.invalid> Mail-Followup-To: Bodo Moeller , Paul Hoffman , "ietf-pkix@imc.org" , "tls@ietf.org" , Eric Rescorla References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <20071121165258.6F56533C2B@delta.rtfm.com> <20071122115333.GA12388@tau.invalid> 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: V01U2FsdGVkX19qqDRMCwQpZJdxMRDp3+NzOvhBvr93NYteb42 gyRCjkMN4rHqPIoWjCc3rJixbWejDEfMDJM5T7PI6jlBdRU9D2 eikCeBcozvic4+AnLBK4ag0RLJM2Nnmsmz/nE8r7wrqS/Wi+jy 6Hw== X-Spam-Score: -0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "ietf-pkix@imc.org" , "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 Fri, Nov 23, 2007 at 07:20:46AM -0800, Paul Hoffman wrote: > At 12:53 PM +0100 11/22/07, Bodo Moeller wrote: >>On Wed, Nov 21, 2007 at 11:26:53AM -0600, max pritikin wrote: >>> Placing usage instructions in the certificate does not enforce the >>> verifying parties behavior any more than protocol handshakes would. >> It does provide authenticated usage information to the verifying >> parties, though. > Um, so? It is "authenticated" to be from a party that is not the > signer. In most situations, my CA doesn't have the slightest idea > what I am doing, or want to be doing, with my public key. Only if you haven't told the CA what you want to do, by using ExtensionReq and the like. Of course, if you can't trust a CA to achieve a sufficiently close approximation of what you want it do to, then that CA is pretty much worthless. If a CA starts to put other people's keys in certificates naming you as the subject, say, that's pretty bad; if it does not follow your requests regarding relevant certificate options, then that's pretty bad too. >> Consider the following scenario. The SHA-3 competition is now open. >> So one interesting business idea is to take the signature from any >> certificate signed by some high-profile ECDSA or DSA root certificate >> that is far away from expiring, and then to engineer a new hash >> algorithm that appears sound and secure, except that it happens to >> have a particularly interesting pre-image for the hash value from said >> non-root certificate's signature: namely, a preimage that would >> provide you with a certificate of your own with generous >> basicConstraints, simply by reusing the previous signature coming from >> the CA. So you submit this hash function to the SHA-3 competition, >> provide a reference implementation and hope that it ends up in relying >> parties' software. If this plan works out, suddenly you have become a >> high-profile CA yourself -- even though in this particular example >> none of the cryptographic algorithms involved would have to be >> insecure in itself. > Even if there were any "high-profile ECDSA or DSA root certificates", > they would contain the signature algorithm, which includes the hash > used, ecdsa-with-SHA1 or id-dsa-with-sha1, and that is covered by the > signature itself. This is no different than RSA. Actually, it is different from RSA signatures. PKCS #1 v1.5 RSA signatures do contain the hash used in unhashed form (i.e. as a literal part of what you get when computing x^e mod n, where x is the signature in question and e, n are the components of the public key). DSA and ECDSA signatures in a certificate, in contrast, involve the algorithm identifer determining the hash function only *as part of the hashed input*. The literal algorithm identifier does not affect the signature verification calculation beyond providing part of the input to the hash function. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 25 14:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwMtx-00032m-0g; Sun, 25 Nov 2007 14:12:21 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwMtv-00032g-Nc for tls-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 14:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwMtv-00032X-3i for tls@ietf.org; Sun, 25 Nov 2007 14:12:19 -0500 Received: from colo.trepanning.net ([69.55.226.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwMts-0004sx-Fx for tls@ietf.org; Sun, 25 Nov 2007 14:12:19 -0500 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E534D1FA61B5 for ; Sun, 25 Nov 2007 11:12:15 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 25 Nov 2007 11:12:15 -0800 (PST) Message-ID: <2969.69.12.173.8.1196017935.squirrel@www.trepanning.net> Date: Sun, 25 Nov 2007 11:12:15 -0800 (PST) From: "Dan Harkins" To: tls@ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [TLS] ciphersuites for AEAD using SIV 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, I have a brief slot on the agenda in Vancouver to discuss an I-D that proposes new ciphersuites for authenticated encryption using the SIV mode. I missed the cutoff for -00 versions but the I-D can be found here: http://www.lounge.org/draft-harkins-tls-rsa-aes-siv-00.txt If the WG is willing I'd like to make this a working group document. Please take a look and I look forward to seeing everyone in Vancouver, Dan. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 07:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwd43-0005tU-DN; Mon, 26 Nov 2007 07:27:51 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iwd42-0005tP-Te for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 07:27:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwd42-0005tH-Iz for tls@ietf.org; Mon, 26 Nov 2007 07:27:50 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwd42-0007K1-5S for tls@ietf.org; Mon, 26 Nov 2007 07:27:50 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 26 Nov 2007 12:27:49 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Mon, 26 Nov 2007 12:27:49 +0000 From: Stefan Santesson To: Eric Rescorla Date: Mon, 26 Nov 2007 12:27:23 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgsT7BNG6z5NU/ETZqOP4ktS7jcHgD1jWzQ Message-ID: <9F11911AED01D24BAA1C2355723C3D32032E20B33B@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> <20071121145750.3114833C2B@delta.rtfm.com> In-Reply-To: <20071121145750.3114833C2B@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "ietf-pkix@imc.org" , "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, Help me to understand the real security threat here. So you are concerned that someone can select a totally different hash algor= ithm than intended (H2), instead of using the intended hash algorithm (H1) = where H1(M) =3DX and H2(M2) =3D X. For this to work, the relying party needs to both implement and approve the= use of H2 within its environment, or it would never believe that M2 matche= s X (assuming that H1(M2) <> X). This is very different from any hash threats I've looked into. How likely i= s it, within the set of hash algorithms the relying party has agreed to use= (as they are considered good enough), that 2 different hash algorithms pro= duces the same output hash (with the same length) for 2 different meaningfu= l messages? What am I missing here? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 21 november 2007 15:58 > We're talking about two different kinds of downgrade here. > The S/MIME anti-downgrade issue is about signature stripping > when multiple signatures are applied. The downgrade issue > I'm concerned about is straight-line forgery: Alice always > signs with digest algorithm H1: she then generates a signature > over some message M where H1(M) =3D X. The attacker compromises H2 > and forms M' st. H2(M2) =3D X. He can then craft a new message > apparently signed by Alice. There's no act that Alice can take > involving H1 and her signature algorithm that can prevent this: > it has to be in information available to a verifier who has only > the cert and a candidate signature. > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 09:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweqR-0004cW-Ph; Mon, 26 Nov 2007 09:21:55 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IweqQ-0004cQ-Bz for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:21:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweqQ-0004cI-1p for tls@ietf.org; Mon, 26 Nov 2007 09:21:54 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IweqP-0001SZ-G3 for tls@ietf.org; Mon, 26 Nov 2007 09:21:53 -0500 Received: from tau.invalid ([134.147.40.222]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1IwepY3xGA-0002qN; Mon, 26 Nov 2007 15:21:51 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 1C2211EBCD; Mon, 26 Nov 2007 15:20:59 +0100 (CET) Date: Mon, 26 Nov 2007 15:20:59 +0100 From: Bodo Moeller To: Dan Harkins Subject: Re: [TLS] ciphersuites for AEAD using SIV Message-ID: <20071126142059.GA27589@tau.invalid> References: <2969.69.12.173.8.1196017935.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2969.69.12.173.8.1196017935.squirrel@www.trepanning.net> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+u/1uqh8D/kY+i+kQacNQDusXNin4+dbX9lMN 7EEgyqs9ArNAH0jMk2sEcxc6tX2DvYi0oQOmgbQPf8UNcLhcNc /3E5vqhn4oz08OtE4YPZ/3OkG/1ED4VvYQwf1u4byBQY0plqC0 8GQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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, Nov 25, 2007 at 11:12:15AM -0800, Dan Harkins wrote: > I have a brief slot on the agenda in Vancouver to discuss an I-D > that proposes new ciphersuites for authenticated encryption using > the SIV mode. I missed the cutoff for -00 versions but the I-D can > be found here: > > http://www.lounge.org/draft-harkins-tls-rsa-aes-siv-00.txt This has an essential normative reference to a second document "draft-harkins-siv-aes-01", which I cannot locate: neither this nor any other "draft-harkins-siv-aes-##.txt" draft is listed at http://www.ietf.org/internet-drafts/ , and there seems to be nothing at the obvious URLs of the form http://www.lounge.org/draft-harkins-....txt either. Where can we find the specification? Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 09:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwf4f-0004jX-Ml; Mon, 26 Nov 2007 09:36:37 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iwf4d-0004io-NI for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwf4d-0004ig-Dm for tls@ietf.org; Mon, 26 Nov 2007 09:36:35 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwf4W-0007Qa-QT for tls@ietf.org; Mon, 26 Nov 2007 09:36:35 -0500 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id lAQFXmaj397460 for ; Mon, 26 Nov 2007 15:33:48 GMT Message-ID: <474AD9CE.9010709@isima.fr> Date: Mon, 26 Nov 2007 15:35:58 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 26 Nov 2007 15:33:48 +0000 (WET) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] ECDHE_PSK Ciphersuites for TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear all, Please don't hesitate to read and submit your comments on the document "ECDHE_PSK Ciphersuites for TLS". I have a very brief slot on the agenda in Vancouver to discuss it. Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 10:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfXz-000514-3L; Mon, 26 Nov 2007 10:06:55 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwfXy-0004yd-GU for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:06:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfXy-0004yV-3G for tls@ietf.org; Mon, 26 Nov 2007 10:06:54 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfXx-0002ce-JB for tls@ietf.org; Mon, 26 Nov 2007 10:06:54 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5DA3133C21; Mon, 26 Nov 2007 07:01:53 -0800 (PST) Date: Mon, 26 Nov 2007 07:01:53 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: <9F11911AED01D24BAA1C2355723C3D32032E20B33B@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> <20071121145750.3114833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D32032E20B33B@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071126150153.5DA3133C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "ietf-pkix@imc.org" , "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 At Mon, 26 Nov 2007 12:27:23 +0000, Stefan Santesson wrote: > > Eric, > > Help me to understand the real security threat here. > > So you are concerned that someone can select a totally different > hash algorithm than intended (H2), instead of using the intended > hash algorithm (H1) where H1(M) =X and H2(M2) = X. For this to > work, the relying party needs to both implement and approve the use > of H2 within its environment, or it would never believe that M2 > matches X (assuming that H1(M2) <> X). > > This is very different from any hash threats I've looked into. Really? It's pretty commonly discussed in the signature literature. See: http://www.rsa.com/rsalabs/node.asp?id=2020 Also, it's the explicit reason why the OID is included in the PKCS1 RSA signature. > likely is it, within the set of hash algorithms the relying party > has agreed to use (as they are considered good enough), that 2 > different hash algorithms produces the same output hash (with the > same length) for 2 different meaningful messages? The likelihood is pretty much that an attacker has a working preimage attack on one accepted algorithm. The difficulty is this: say we have an expensive preimage attack on SHA-1--expensive enough that people don't delete it immediately, which I would say is pretty consistent with people's models so far of how aggressive they are about aging out algorithms. I note that TLS 1.1. still has DES-CBC. I get my first DSA certificate which we'll say is signed by SHA-256. I never sign with SHA-1. Without some indicator in the certificate, people can go around impersonating me as long as they can break SHA-1 and there's nothing I can do about it. That seems not so OK. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 11:02:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgPl-0006OI-MM; Mon, 26 Nov 2007 11:02:29 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwgPk-0006OC-C7 for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:02:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgPk-0006O4-2h for tls@ietf.org; Mon, 26 Nov 2007 11:02:28 -0500 Received: from colo.trepanning.net ([69.55.226.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwgPa-0001Tk-Gp for tls@ietf.org; Mon, 26 Nov 2007 11:02:28 -0500 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 04D1D1FA61BC; Mon, 26 Nov 2007 08:02:18 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 26 Nov 2007 08:02:18 -0800 (PST) Message-ID: <4544.69.12.173.8.1196092938.squirrel@www.trepanning.net> In-Reply-To: <20071126142059.GA27589@tau.invalid> References: <2969.69.12.173.8.1196017935.squirrel@www.trepanning.net> <20071126142059.GA27589@tau.invalid> Date: Mon, 26 Nov 2007 08:02:18 -0800 (PST) Subject: Re: [TLS] ciphersuites for AEAD using SIV From: "Dan Harkins" To: "Bodo Moeller" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 Hi Bodo, My apologies. It's draft-dharkins-siv-aes-01.txt. I fat-fingered my -00 draft by adding the d and now I'm stuck with it. Since draft-harkins-tls-rsa-aes-siv-00.txt has not officially been submitted I'll update it immediately. Thanks for spotting this! regards, Dan. On Mon, November 26, 2007 6:20 am, Bodo Moeller wrote: > On Sun, Nov 25, 2007 at 11:12:15AM -0800, Dan Harkins wrote: > >> I have a brief slot on the agenda in Vancouver to discuss an I-D >> that proposes new ciphersuites for authenticated encryption using >> the SIV mode. I missed the cutoff for -00 versions but the I-D can >> be found here: >> >> http://www.lounge.org/draft-harkins-tls-rsa-aes-siv-00.txt > > This has an essential normative reference to a second document > "draft-harkins-siv-aes-01", which I cannot locate: neither this nor > any other "draft-harkins-siv-aes-##.txt" draft is listed at > http://www.ietf.org/internet-drafts/ , and there seems to be nothing > at the obvious URLs of the form > http://www.lounge.org/draft-harkins-....txt > either. > > Where can we find the specification? > > Bodo > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 13:37:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwipN-0006zO-S8; Mon, 26 Nov 2007 13:37:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwipM-0006zJ-KJ for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:37:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwipM-0006ym-9e for tls@ietf.org; Mon, 26 Nov 2007 13:37:04 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwipL-0001f8-QM for tls@ietf.org; Mon, 26 Nov 2007 13:37:04 -0500 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAQIb1or029221 for ; Mon, 26 Nov 2007 13:37:01 -0500 (EST) X-AuditID: 90333308-00000f2c000007e0-4d-474b124d7bb2 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 13:37:01 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 13:37:00 -0500 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] DSA/SHA-1, and OIDs Date: Mon, 26 Nov 2007 13:36:45 -0500 Message-ID: In-Reply-To: <6215401E01247448A306C54F499111F20383906A@WSMSG2103V.srv.dir.telstra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAF1tZzAA7y+UIA== References: <20071112191115.543C833C2B@delta.rtfm.com><20071119164754.8147233C2B@delta.rtfm.com><6215401E01247448A306C54F499111F202C39470@WSMSG2103V.srv.dir.telstra.com> <6215401E01247448A306C54F499111F20383906A@WSMSG2103V.srv.dir.telstra.com> From: "Kemp, David P." To: , X-OriginalArrivalTime: 26 Nov 2007 18:37:00.0992 (UTC) FILETIME=[55378C00:01C8305B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Key usage (1), key purpose (2) and signature/encryption/transport > algorithm (3) are really three points on a continuum > for giving the certificate holder control over where the > key->name binding (which is the core of their certificate) will be used. > There is no theoretical reason to support controls 1 & 2, but not 3. It is not really a continuum. Key usage constrains the use of a key to support confidentiality or integrity, which are qualitatively different services, not just different thresholds along a single dimension. Confidentiality requires some sort of relationship between sender and recipient (the sender must know the public key of each recipient, and the sender and recipients must share a common algorithm). Integrity is a broadcast mechanism where the sender may know nothing about the universe of potential recipients - a data object is signed, and some recipients will accept the signature algorithm while others will not. All recipients have access to the same data but they make individual, potentially different, decisions on what to do with it. >From: Eric Rescorla > > My claim is that for security reasons it's necessary for DSA > certs to indicate the hash algorithm(s) that may be used with > the public key contained in the cert. This prevents hash > algorithm substitution in signatures formed with that key > (or rather the private key that corresponds to that key). Do > you agree with this? I do not agree. Assume that a recipient accepts weak hash algorithms for signatures, and that an attacker wishes to attack a signed object. If a cert contains the proposed constraint, then the attacker can just create a new cert without the constraint signed with the weak algorithm. The only way a certificate constraint would be useful is if the relying party believed that algorithm X is not broken (is acceptable) with respect to data signatures but is broken (is not acceptable) wrt certificate signatures. Why would any rational RP believe that? (Before saying that covering a certificate algorithm ID with a weak signature prevents that algid from being modified, perform a thought experiment assuming the recipient accepts a hypothetical DSA-with-CRC32 signature algorithm. If it is possible to compute preimages, why would it not be possible to compute a preimage containing the DSA-with-CRC32 algid? Extending to MD5 and SHA1 is just a matter of required and available resources.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 13:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwitF-0002aS-Vg; Mon, 26 Nov 2007 13:41:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwitF-0002aN-MG for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwitF-0002aF-Cl for tls@ietf.org; Mon, 26 Nov 2007 13:41:05 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwitA-00088A-2B for tls@ietf.org; Mon, 26 Nov 2007 13:41:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9327033C21; Mon, 26 Nov 2007 10:35:59 -0800 (PST) Date: Mon, 26 Nov 2007 10:35:58 -0800 From: Eric Rescorla To: "Kemp, David P." Subject: Re: [TLS] DSA/SHA-1, and OIDs In-Reply-To: References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F202C39470@WSMSG2103V.srv.dir.telstra.com> <6215401E01247448A306C54F499111F20383906A@WSMSG2103V.srv.dir.telstra.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071126183559.9327033C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf-pkix@imc.org, 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 At Mon, 26 Nov 2007 13:36:45 -0500, Kemp, David P. wrote: > > >From: Eric Rescorla > > > > My claim is that for security reasons it's necessary for DSA > > certs to indicate the hash algorithm(s) that may be used with > > the public key contained in the cert. This prevents hash > > algorithm substitution in signatures formed with that key > > (or rather the private key that corresponds to that key). Do > > you agree with this? > > I do not agree. Assume that a recipient accepts weak hash algorithms > for signatures, and that an attacker wishes to attack a signed object. > If a cert contains the proposed constraint, then the attacker can > just create a new cert without the constraint signed with the weak > algorithm. The only way a certificate constraint would be useful > is if the relying party believed that algorithm X is not broken > (is acceptable) with respect to data signatures but is broken > (is not acceptable) wrt certificate signatures. Why would any > rational RP believe that? You seem to be making the implicit assumption that the RP trusts a CA who signs certificates with a weak digest. Why need that be the case? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 15:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkRS-0002Oq-CE; Mon, 26 Nov 2007 15:20:30 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwkRR-0002Ok-ED for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 15:20:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkRR-0002Ob-4e for tls@ietf.org; Mon, 26 Nov 2007 15:20:29 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwkRO-0002Cm-KO for tls@ietf.org; Mon, 26 Nov 2007 15:20:29 -0500 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAQKKQdA010289 for ; Mon, 26 Nov 2007 15:20:26 -0500 (EST) X-AuditID: 90333308-00000f3c000007e0-41-474b2a8a5bc0 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 15:20:26 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 15:20:25 -0500 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] DSA/SHA-1, and OIDs Date: Mon, 26 Nov 2007 15:20:24 -0500 Message-ID: In-Reply-To: <20071126183559.9327033C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgwW+k3qeWXBTuqTTS918LjTfjKYgAA6JYg References: <20071112191115.543C833C2B@delta.rtfm.com><20071119164754.8147233C2B@delta.rtfm.com><6215401E01247448A306C54F499111F202C39470@WSMSG2103V.srv.dir.telstra.com><6215401E01247448A306C54F499111F20383906A@WSMSG2103V.srv.dir.telstra.com> <20071126183559.9327033C21@delta.rtfm.com> From: "Kemp, David P." To: , X-OriginalArrivalTime: 26 Nov 2007 20:20:25.0946 (UTC) FILETIME=[C7A863A0:01C83069] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 >=20 > You seem to be making the implicit assumption that the RP > trusts a CA who signs certificates with a weak digest. > Why need that be the case? It doesn't need to be the case. However, if an RP has an opinion about what is "weak", my assumption is that the RP would trust neither a CA who signs certificates with weak signatures nor another party who signs data with weak signatures. > It's pretty commonly discussed in the signature literature. > See: http://www.rsa.com/rsalabs/node.asp?id=3D2020 > Also, it's the explicit reason why the OID is included in > the PKCS1 RSA signature. Thanks for the pointer - very interesting. Fundamentally, I disagree with Kaliski's premise: "Signer accepts the risk from its own choices [of acceptable algorithms], but needs some way to mitigate the risk due to the verifier's choices." The premise is that the signer *has* some risk (faces some negative consequences) as a result of a verifier choosing to accept a weak signature. If a signer signs an electronic bank check, a forger receives the check, weakens the signature, and increases the amount, and a bank accepts the forged signature, my assumption is that the signer is not liable because the bank accepted an algorithm that is against generally accepted business practices. If Paypal accepted certificates for user authentication over TLS instead of passwords, I'd expect them to advertise "safe because we use SHA-256" the same way they say "safe because we use 128 bit SSL" today. If community standards regarded MD5 signatures to be the risk equivalent of 40 bit encryption, I (as a signer) wouldn't expect to be held responsible if Paypal accepted a forged MD5 signature as coming from me. (This whole discussion has something of an angels-on-pinheads flavor, given that even "weak" SHA-1 signatures are much stronger than the typical user-selected password. But I'll suspend disbelief and assume that signatures are being used in the first place. Note that most of my email is signed, but I turn off signatures for mail to IETF security-area WG lists. How Lewis Carroll is that?) What is a scenario in which "Signer needs to mitigate risk due to verifier accepting a weak signature"? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 26 18:15:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnAO-0007Lz-Ug; Mon, 26 Nov 2007 18:15:05 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IwnAN-0007Lm-FF for tls-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 18:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnAN-0007Ld-23; Mon, 26 Nov 2007 18:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwnAM-0007Bp-MQ; Mon, 26 Nov 2007 18:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4EFBB175CA; Mon, 26 Nov 2007 23:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwnAL-0001Z2-RD; Mon, 26 Nov 2007 18:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Nov 2007 18:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-07.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Transport Layer Security (TLS) Protocol Version 1.2 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc4346-bis-07.txt Pages : 99 Date : 2007-11-26 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-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4346-bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-26170120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-26170120.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 Nov 27 07:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix01Y-0005F8-1P; Tue, 27 Nov 2007 07:58:48 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ix01X-0005Ew-F4 for tls-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 07:58:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix01X-0005Eg-4i for tls@ietf.org; Tue, 27 Nov 2007 07:58:47 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix01W-0008AX-K8 for tls@ietf.org; Tue, 27 Nov 2007 07:58:47 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lARCwJPh008467 for ; Tue, 27 Nov 2007 14:58:44 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:58:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:58:19 +0200 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: Tue, 27 Nov 2007 14:58:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-tls-rfc4346-bis-07 Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIg== From: To: X-OriginalArrivalTime: 27 Nov 2007 12:58:19.0116 (UTC) FILETIME=[2ED91AC0:01C830F5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 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 message starts a WG last call on draft-ietf-tls-rfc4346-bis-07, prior to sending it to the IESG for publication as Proposed Standard. Please send your comments to the WG mailing list by Wednesday=20 December 19th. Comments along the lines "I've read it and it looks=20 OK" are helpful and encouraged.=20 The last call period is longer than usual to accommodate for=20 the IETF meeting, but if you manage to do some reading on your=20 flight to Vancouver, your comments can be discussed face-to-face=20 there. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 29 23:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxDj-0003x3-99; Thu, 29 Nov 2007 23:11:19 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IxxDi-0003ww-BC for tls-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 23:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxDi-0003wm-1A for tls@ietf.org; Thu, 29 Nov 2007 23:11:18 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxxDh-0005VV-G3 for tls@ietf.org; Thu, 29 Nov 2007 23:11:18 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 30 Nov 2007 04:11:16 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 30 Nov 2007 04:11:16 +0000 From: Stefan Santesson To: Eric Rescorla Date: Fri, 30 Nov 2007 04:11:07 +0000 Subject: RE: [TLS] DSA/SHA-1, and OIDs Thread-Topic: [TLS] DSA/SHA-1, and OIDs Thread-Index: AcgwPgz3EhyIY9lRRxCldMBYJtAaWgCxqybQ Message-ID: <9F11911AED01D24BAA1C2355723C3D320567D13817@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> <20071121145750.3114833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D32032E20B33B@EA-EXMSG-C332.europe.corp.microsoft.com> <20071126150153.5DA3133C21@delta.rtfm.com> In-Reply-To: <20071126150153.5DA3133C21@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "ietf-pkix@imc.org" , "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, > Really? It's pretty commonly discussed in the signature literature. > See: http://www.rsa.com/rsalabs/node.asp?id=3D2020 Yeah, really :) Maybe I should be more clear. AFAIK In order to substitute a message in thi= s way you would need to successfully do a preimage attack on the week hash = algorithm. A marginal attack with bit flipping is not enough, is has to be = a complete break so you can create a meaningful message substantially diffe= rent from the original message and make that match a given signed hash valu= e by including some nonce in a syntactically legal manner. Nothing in the article I could find in my quick read tells me how to do tha= t on any generally accepted hash algorithm, and as far as I know we should = be pretty safe. We start to move away from hash algorithms as soon as they show cracks agai= nst collision resistance. We should definitely have abandoned them before t= hey are completely broken. Or what have I missed? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 26 november 2007 16:02 > To: Stefan Santesson > Cc: Eric Rescorla; ietf-pkix@imc.org; tls@ietf.org > Subject: Re: [TLS] DSA/SHA-1, and OIDs > > At Mon, 26 Nov 2007 12:27:23 +0000, > Stefan Santesson wrote: > > > > Eric, > > > > Help me to understand the real security threat here. > > > > So you are concerned that someone can select a totally different > > hash algorithm than intended (H2), instead of using the intended > > hash algorithm (H1) where H1(M) =3DX and H2(M2) =3D X. For this to > > work, the relying party needs to both implement and approve the use > > of H2 within its environment, or it would never believe that M2 > > matches X (assuming that H1(M2) <> X). > > > > This is very different from any hash threats I've looked into. > > Really? It's pretty commonly discussed in the signature literature. > See: http://www.rsa.com/rsalabs/node.asp?id=3D2020 > Also, it's the explicit reason why the OID is included in the > PKCS1 RSA signature. > > > likely is it, within the set of hash algorithms the relying party > > has agreed to use (as they are considered good enough), that 2 > > different hash algorithms produces the same output hash (with the > > same length) for 2 different meaningful messages? > > The likelihood is pretty much that an attacker has a working > preimage attack on one accepted algorithm. The difficulty is > this: say we have an expensive preimage attack on SHA-1--expensive > enough that people don't delete it immediately, which I would say > is pretty consistent with people's models so far of how aggressive > they are about aging out algorithms. I note that TLS 1.1. still has > DES-CBC. > > I get my first DSA certificate which we'll say is signed by SHA-256. > I never sign with SHA-1. Without some indicator in the certificate, > people can go around impersonating me as long as they can break > SHA-1 and there's nothing I can do about it. That seems not so > OK. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 30 12:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9eR-0003JD-VQ; Fri, 30 Nov 2007 12:27:43 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iy42E-0008Cx-IV for tls-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 06:27:54 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Iy42E-00086P-37 for tls@ietf.org; Fri, 30 Nov 2007 06:27:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3ib-0000yF-52 for tls@ietf.org; Fri, 30 Nov 2007 06:07:37 -0500 Received: from a.mx.secunet.com ([213.68.205.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy3ia-0007EL-Lh for tls@ietf.org; Fri, 30 Nov 2007 06:07:36 -0500 Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 82A0620C09C; Fri, 30 Nov 2007 12:07:34 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 3894620C078; Fri, 30 Nov 2007 12:07:34 +0100 (CET) Received: from [10.208.1.212] ([10.208.1.212]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Nov 2007 12:07:34 +0100 Message-ID: <474FEEF5.5040800@secunet.com> Date: Fri, 30 Nov 2007 12:07:33 +0100 From: Johannes Merkle User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [TLS] DSA/SHA-1, and OIDs References: <20071112191115.543C833C2B@delta.rtfm.com> <20071119164754.8147233C2B@delta.rtfm.com> <6215401E01247448A306C54F499111F2037FFFC9@WSMSG2103V.srv.dir.telstra.com> <9F11911AED01D24BAA1C2355723C3D3223B387DF@EA-EXMSG-C332.europe.corp.microsoft.com> <20071120173336.B3C8133C21@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D3223B38B6E@EA-EXMSG-C332.europe.corp.microsoft.com> <20071121145750.3114833C2B@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D32032E20B33B@EA-EXMSG-C332.europe.corp.microsoft.com> <20071126150153.5DA3133C21@delta.rtfm.com> In-Reply-To: <20071126150153.5DA3133C21@delta.rtfm.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2007 11:07:34.0185 (UTC) FILETIME=[35665990:01C83341] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-TMDA-Confirmed: Fri, 30 Nov 2007 06:27:54 -0500 X-Mailman-Approved-At: Fri, 30 Nov 2007 12:27:43 -0500 Cc: "ietf-pkix@imc.org" , "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, > > I get my first DSA certificate which we'll say is signed by SHA-256. > I never sign with SHA-1. Without some indicator in the certificate, > people can go around impersonating me as long as they can break > SHA-1 and there's nothing I can do about it. That seems not so > OK. To me, this seems to be just one example of a general problem. If certain services accept / deploy weak identification and authentification methods, anybody can impersonate you there. This is the case with ebay accounts and could also happen with CAs deploying poor identification methods. Services / RP accepting MD4 based signatures are just another example. Of course, the hash function downgrade attack abuses a real signature and at first sight, it may seem logical to call for measures in the PKI to prevent that. But I can also understand PKIX being reluctant about including extensions / attributes in certificates (and hence, adding complexity and potential problems) to counter an attack which are leveraged by third parties applying poor security, and which can still occur on a different level. Johannes Merkle _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls