From turners@ieca.com Tue Jun 1 07:56:14 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210E93A684D for ; Tue, 1 Jun 2010 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui-29-Eu2-p5 for ; Tue, 1 Jun 2010 07:56:10 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id 7A0DA3A6A2A for ; Tue, 1 Jun 2010 07:56:10 -0700 (PDT) Received: (qmail 90532 invoked from network); 1 Jun 2010 14:55:53 -0000 Received: from thunderfish.local (turners@96.241.1.49 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 01 Jun 2010 07:55:53 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: CqlcPcMVM1kBjSCgf33hAn9.9eY_ItzbEbnUeq7TPqfBWh2fp_JJlTn4c_Bg9b._n2HXJsc.0tVw1qQ8va7ILXnVO71SjJ4LcGc9jE6Xv2X_xG6pOW7L.WLJ05sqauM1Q93k.6cMz4X1tAnz3xkRlwAZ0sv_ao3o2aTfvcJYNZUJb12Cx5Psxh69EEY2sbOMAkhct3kS8UttUMB.W4tuACkrDfgKoDJJpF7lJOGLkyFw5xyXk2D_XWP8uI.5FiWE2VhwVyEpFZwVbY9i2b6TOSpcg1b3MF01nUquUNRbkRsKf9az0i0Z.UQ7j8Jkgc.YAeS0lBy1G93zBlJ_lBftiYs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C051F78.2080600@ieca.com> Date: Tue, 01 Jun 2010 10:55:52 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, saag@ietf.org References: <4BFD1FE5.10207@ieca.com> <4BFD38F9.20800@gmail.com> In-Reply-To: <4BFD38F9.20800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] The IETF Security Area Wiki and our new AD blogs X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 14:56:14 -0000 I asked Henrik if Tim and I could get real blog with an RSS feed. Turns out we can. It's currently empty and I can pretty much guarantee that it won't be witty or entertaining but I'm hoping it will get you the information you need. It can be found by clicking on the "blog" link in the toolbar on the following page: http://trac.tools.ietf.org/area/sec/trac/wiki Tim and I are also updating the name of what we were calling the "TimsBlog" and "SeansBlog". I'm going to rename mine SeansMonthlyStatus and it will be the same as the email I'll send out. spt Yaron Sheffer wrote: > Hi Sean, > > the security AD blog is a very good idea. But (unless I'm missing > something) the Trac wiki doesn't support RSS or any other kind of > subscription, which makes it much less useful than plain old email. So I > hope you are still planning to mail out the AD notes. > > Thanks, > Yaron > > > On 05/26/2010 04:19 PM, Sean Turner wrote: >> While at the IESG retreat, Tim and I decided to update the Security Area >> wiki, which if you didn't know is located at: >> http://trac.tools.ietf.org/area/sec/trac/wiki >> >> Tim and I also decided to add a blog for each of us, which is going to >> be eerily similar to monthly AD notes: >> >> http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog >> http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog >> >> I'm hoping that we'll both update on it on a regular basis. >> >> spt >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > From turners@ieca.com Thu Jun 3 12:45:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F1428C0F1 for ; Thu, 3 Jun 2010 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzDJ60E9ymdb for ; Thu, 3 Jun 2010 12:45:42 -0700 (PDT) Received: from smtp112.biz.mail.mud.yahoo.com (smtp112.biz.mail.mud.yahoo.com [209.191.68.77]) by core3.amsl.com (Postfix) with SMTP id 82B0A3A6A09 for ; Thu, 3 Jun 2010 12:45:42 -0700 (PDT) Received: (qmail 30775 invoked from network); 3 Jun 2010 19:45:18 -0000 Received: from thunderfish.local (turners@71.191.5.250 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 03 Jun 2010 12:45:18 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: vGG6u1cVM1lM5.25uIv3XPOsjFvr7_c0__l8VOJa4vKIDf3JdhNRARhrpZfLwbcVfqel7qjmpR8ed1_RVZuUTFkN7JKgAI59POWm9mWylxeeUN2G3sSEEzRxv4_g_4W3nq0CnQLA4buJnnghHq8SK2b0vOf2Q8LLwV5dwQ1nF1nR97xZ1PREMkunjRxlRLf6VhNshh0cTDWBGZnDckZtpZ6olLhvRSs1A6o4O0KKizHV_TFo8xb_tAVrlZeF5atSWZgq4z5LR4BoPR5PZVx0TQGDfoTNfMt0Wtv_XDrDZZ_Y0P94EEBs7irP213wChy.GsXJvf0INGLkB5rl59IeAg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C08064D.4000704@ieca.com> Date: Thu, 03 Jun 2010 15:45:17 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Sean's AD Notes for 2010-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 19:45:44 -0000 These notes are identical to those posted on:http://trac.tools.ietf.org/area/sec/trac/wiki/SeansMonthlyUpdate. Note that there's also a blog with an RSS feed at: http://trac.tools.ietf.org/area/sec/trac/blog = Sean Turner's Monthly AD Notes - 2010-06-03 = Here's my monthly AD notes. It's a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. == MISC NOTES == * IETF 78 planning continued with Tim: SAAG presentations. * Sam, Josh, Tim, and I had a call to discuss the FEDAUTH BOF proposal. Will be discussed on 2010-06-02 BOF Coordination call. * Participated in weekly call with Tim. * Authors provided valuable information that Tim/I will use to resolve the ~100 errata received from Constantin Hagemeier on RFC 3447, RFC 4301, RFC 4302, RFC 4306, and RFC 4880. == WORKING GROUPS == === DKIM === * RFC 5863 published (dt:draft-ietf-dkim-deployment). Congrats! * Another ton of email that I haven't gotten all the way through. * Charter revision process started. Placed WG agreed charter on 2010-06-03 telechat. * Errata 1532 and 1596: Awaiting WG chairs proposal for new text and recommended status. 2010-05-05. === EMU === * dt:draft-ietf-emu-eaptunnel-req: Entered WGLC on 2010-05-20 and ends 2010-06-04. === IPSECME === * RFC 5879 published (was dt:draft-ietf-ipsecme-esp-null-heuristics). * dt:draft-ietf-ipsecme-aes-ctr-ikev2: Passed through IESG review with some minor changes and it now sits in the RFC editor's queue. * dt:draft-ietf-ipsecme-ikev2bis: Passed through IESG review with some minor changes and it now sits in the RFC editor's queue. * dt:draft-ietf-ipsecme-roadmap: New version posted on 2010-05-28. Yaron had some questions concerning the removal of Appendix A and another point. Awaiting author response 2010-05-28. * dt:draft-ietf-ipsecme-ipsec-ha: Revised and passed through WGLC. Awaiting AD review. 2010-06-01. I plan to have this done by 2010-06-07. * dt:draft-ietf-ipsecme-eap-mutual: Revised and placed on the 2010-06-17 IESG telechat. * (not a WG item) dt:draft-sheffer-ipsecme-pake-criteria-02.txt: Fair amount of discussion about definition of gateway. === ISMS === * dt:draft-ietf-isms-dtls-tm: Resolved IESG DISCUSS positions and entered RFC editor's queue. * dt:draft-ietf-isms-radius-vacm: Entered 2nd WGLC on 2010-05-15 ends 2010-05-22. === KEYPROV === (I know it's Tim's but I am following it closely) * dt:draft-ietf-keyprov-dskpp: Dealing with IESG DISCUSS positions. 2nd IETF LC issued to address DOWNREF. * dt:draft-ietf-keyprov-pskc: Dealing with IESG DISCUSS positions. 2nd IETF LC issued to address DOWNREF. * dt:draft-ietf-keyprov-symmetrickeyformat: Dealing with IESG DISCUSS positions. === SASL === * dt:draft-ietf-sasl-gs2 and draft-ietf-sasl-scram: In RFC editor queue, waiting for draft-altman-tls-channel-bindings. * (not WG item) dt:draft-altman-tls-channel-bindings: In RFC editor's queue. * Discussions about combining SASL/KITTEN are progressing. No major objections have been raised. === SYSLOG === * RFC 5848 published (was dt:draft-ietf-syslog-sign). * dt: draft-ietf-syslog-dtls: Resolving IESG DISCUSS positions. Since 2010-05-19. Ball is in Shepherd's court (he knows it is too). === TLS === * dt:draft-ietf-tls-rfc4366-bis: Revised. Hoping to have this come to me soon. About 3 people have asked me what the status of this I-D is. * dt:draft-ietf-tls-cached-info: Rehashing (no pun intended) why and how of this I-D. == OTHER DOCUMENTS == * dt:draft-hoffman-tls-additional-random-ext: IETF LC consensus was clear: don't progress this I-D. I will change the status to dead. * dt:draft-hoffman-tls-master-secret-input: IETF LC generated some comments. Will progress this one. == DISCUSSES == As an AD, the more DISCUSS positions you enter the more work you have to do (information for all those would be ADs). * dt:draft-moriarty-post-inch-rid-11: Awaiting response from author. 2010-06-02. * dt:draft-cheshire-dnsext-nbp: I picked up part of Pasi's DISCUSS and Russ picked up the rest. * dt:draft-ietf-bmwg-ipsec-term: I picked up Pasi's DISCUSS. 2010-03-31. * dt:draft-ietf-bmwg-ipsec-meth: I picked up Pasi's DISCUSS. 2010-04-08. * dt:draft-ietf-csi-hash-threat: I picked up Pasi's DISCUSS. 2010-04-08. * dt:draft-ietf-avt-register-srtp: Awaiting response from Robert wrt his discussions with Cullen. 2010-04-22. * dt:draft-denenberg-mods-etc-media-types-02: Awaiting response from authors. 2010-04-29. This one will probably be pinned for a while waiting for OASIS to stabilize a draft. * dt: draft-ietf-sipping-config-framework: Waiting for revised I-D. 2010-04-22. * dt:draft-ietf-avt-register-srtp-02: Waiting for revised I-D. 2010-05-06. * dt:draft-ietf-avt-rtp-ipmr-12: Waiting for revised I-D. 2010-05-06. * dt:draft-ietf-mext-flow-binding-06: Waiting for revised I-D. 2010-05-06. * dt:draft-ietf-keyprov-pskc-06: Waiting for revised I-D. 2010-05-06. * dt:draft-lawrence-sipforum-user-agent-config-01: Waiting for revised I-D. 2010-05-06. * dt:draft-ietf-6lowpan-routing-requirements-06: Waiting for revised I-D. 2010-05-20. * dt:draft-moriarty-post-inch-rid-transport-02: Waiting for revised I-D. 2010-06-02. * dt:draft-ietf-avt-rapid-rtp-sync-11: Waiting for revised I-D. 2010-06-02. * dt:draft-ietf-nsis-ntlp-sctp-12: Waiting for revised I-D. 2010-06-02. * dt:draft-zimmermann-avt-zrtp-21: Need to revise my comments. 2010-06-02. From turners@ieca.com Thu Jun 3 14:51:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29F23A6A2A for ; Thu, 3 Jun 2010 14:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=1.812, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOTGjN-n1xYx for ; Thu, 3 Jun 2010 14:51:52 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 309513A6A24 for ; Thu, 3 Jun 2010 14:51:52 -0700 (PDT) Received: (qmail 80352 invoked from network); 3 Jun 2010 21:51:37 -0000 Received: from thunderfish.local (turners@71.191.5.250 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 03 Jun 2010 14:51:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 9HR3AhAVM1nX9IF2umBrhY1Typ3eEoD3bYQT4YcTNh0nFjUrP7OSYsDV71yUg8rluvIQnfl13_U86xq50hvdgbHvQYsBmRDow1Ik_FKWEcGxjJPnMarx7MjWqKRBmTSsBKNUR5gB_sN9T47dLDo4hoSuwQVhhRbQVI3nyo1uhO2wPjXbz7BotTHtPrNSi12fyM.CDUNdJrOPeKLJ1jmyzjmE1Wbyze9JHSRBTA5CGoFbXiToxcftlwhtp37I1puBu.N0jXejMODinIc8U7agyoBbOe6Bans62SSZrP9lIEl1CLZrBaPJGJhXjDPxzGmG8OScrae6T4RoRewr2K5V7to20Dle0nbMUKjdNA5fJTfXZM62_TqBHx6sbTb.XWkwsJgVnPiTp.MILaCQDWl4c2mMX.HV_d1qxIiMZdJt9jILzOle.QYPGyzF4sp6V2vZvdpu9IVniyam1Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0823E9.7080504@ieca.com> Date: Thu, 03 Jun 2010 17:51:37 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: multipart/mixed; boundary="------------000202000408020800050803" Subject: [saag] [Fwd: IETF 78 - Meeting and Sponsorship Information] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:51:56 -0000 This is a multi-part message in MIME format. --------------000202000408020800050803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Forwarding as requested. --------------000202000408020800050803 Content-Type: message/rfc822; name="IETF 78 - Meeting and Sponsorship Information.eml" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="IETF 78 - Meeting and Sponsorship Information.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.72; Thu, 03 Jun 2010 12:51:28 -0700 Received-SPF: pass (mta1014.biz.mail.mud.yahoo.com: domain of wgchairs-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: S_lBEAUcZAoi6Ce1t5GesijBfrLv.0QscMquXGaa0LxhJgTQfat4hUROcz3V41L7V__2LpbH_rxUkn5sCWsI2WdQYHAMrvdDUwwHaSsODv7CGraxdv8aAEIqWgW4n81KB5giVcSUgWka5ncMFRMlhdJ0mfIbGu2i6QuU.lLTNB.nhnL2x3MeM0e8ln8fkltLsjwtGnmoJc6M69JW_k3fa9MnQF0WzdlNqKEHA.5mmIT.K18Vea4Vuj5GJAuo5Hg8PKOOh5XD.Yl9ta9IJVoVdq9ZSpvYjjiiBrMU2gAgfQPFAaba3tglli.m8B4Pbo4dVJM2ZmaoKJKt1Er3q.2T7A5gEeTrbqpzzSOIVfcTf6ftyWXbHFrEtnabNWSqg8tXU1.8mgJCnPc3Fqm1yDipossUyw8D8t3hOiuf6R92FJwVsESs9v1eTVkILggDUSHjCc5OICCxzU1Pf3TrMFB8QlG87WzNff8J5BT_0omjxp6MsAJetj7VPYywmACuWpISTXt7EDZL8gScaRV_CJc1tcKqVx6Rym9UL_9awmtL5ex838svjerJ_PP3XV.mutkltT4aNsYX5ry3iH48CGUoXNSn2FDyNDrZ X-Originating-IP: [64.170.98.32] Authentication-Results: mta1014.biz.mail.mud.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1014.biz.mail.mud.yahoo.com with SMTP; Thu, 03 Jun 2010 12:51:28 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDFC3A6A1D; Thu, 3 Jun 2010 12:51:41 -0700 (PDT) X-Original-To: wgchairs@ietf.org Delivered-To: wgchairs@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 70B7D3A68E6; Thu, 3 Jun 2010 12:51:40 -0700 (PDT) From: IETF Secretariat To: Working Group Chairs Subject: IETF 78 - Meeting and Sponsorship Information Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100603195140.70B7D3A68E6@core3.amsl.com> Date: Thu, 3 Jun 2010 12:51:40 -0700 (PDT) X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org Working Group Chairs, Can you please forward this message to your individual working group emails lists. We want to ensure that as many people as possible are aware of the sponsorship opportunities available at IETF meetings. Thank you. ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html “Sponsorship Opportunities” under “General”. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization’s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! --------------000202000408020800050803-- From turners@ieca.com Mon Jun 7 10:42:08 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119F53A6BA6 for ; Mon, 7 Jun 2010 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8u4paPP-oTG for ; Mon, 7 Jun 2010 10:42:04 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id 6E04528CB37 for ; Mon, 7 Jun 2010 09:56:46 -0700 (PDT) Received: (qmail 51304 invoked from network); 7 Jun 2010 16:56:44 -0000 Received: from thunderfish.local (turners@71.191.11.91 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 07 Jun 2010 09:56:44 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: K16yz6MVM1kx4fCa4eHpyR_ivtU0zyg1LHTlgzeVRxSb7f4cXcJanzCQWLiRB42IvYAJ.3AZFM0AQX2URjOt6yWaS9AlTK5NyrVl52wPVS5.ESsvYLJr1IARSDrmrzdegu45gAYPa26gOa8MNpQ0SM6Kv1OvmqqneLinoNYxnU.yzDPTu1rQ9POeH_SYvqwqug_tIFKm8GzuXhiEfvP9kMKMrnNrWFPCqeAWkpsQ4jyucAtv5M1KN1rQG8dXE8.68dmWtEfvDSP4Kw.How-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0D24CB.2020306@ieca.com> Date: Mon, 07 Jun 2010 12:56:43 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] IETF 78 Meeting Requests (so far) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:42:08 -0000 To date we've received meeting requests from the following WGs: EMU DKIM IPSECME PKIX SAAG TLS Just a reminder 2010-06-14 (next Monday) is the cutoff to request a WG session. We've also got one BOF scheduled: FEDAUTH. spt From turners@ieca.com Thu Jun 10 06:05:15 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A303A6A07 for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfJO2DLJnCNo for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) Received: from smtp115.biz.mail.sp1.yahoo.com (smtp115.biz.mail.sp1.yahoo.com [69.147.92.217]) by core3.amsl.com (Postfix) with SMTP id 0912D3A6A0F for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) Received: (qmail 44195 invoked from network); 10 Jun 2010 13:05:14 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 10 Jun 2010 06:05:14 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _Rl25_EVM1ky5hwSqTWVghQEspTRP9SpAfIHtwJfAQJkrVYySJwnb3ZyedRAP2HgcVGiKQBm3y6algvCdCHEsLXOzs4ksBcT0UTcoTTCmow3ljPjjsRVpfDqeRSze2LlDt3xR8q_JOUBducu153aLom1fOJuXZZJjNifX3Ezw_nsxdSMF8MTyAYoJGyXU3d6MJ8tLhwleNzPbRh9FZt3xoHTEigygbBrsa5_kroApZ3XqXkV8UR38JDgi10FUUCvz3srliZ72SQA8rOyxqHaCSq1YpMIzor99eNMFKabh9DXzIVQ52ibfKZ_XF.df0rxVp7Tkpp6.nXDZ52aAeQkjA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C10E308.9060503@ieca.com> Date: Thu, 10 Jun 2010 09:05:12 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org, smime@ietf.org, pkix@ietf.org, cfrg@irtf.org Content-Type: multipart/mixed; boundary="------------090806050806050406010805" Subject: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:05:16 -0000 This is a multi-part message in MIME format. --------------090806050806050406010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (apologies if you get this multiple times) I'm looking for feedback on this draft that proposes moving MD2 to historic status. Thanks, spt --------------090806050806050406010805 Content-Type: message/rfc822; name="I-D ACTION:draft-turner-md2-to-historic-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-turner-md2-to-historic-00.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.75; Wed, 09 Jun 2010 15:00:16 -0700 Received-SPF: pass (mta1000.biz.mail.sk1.yahoo.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: 1AsMrJEcZArVP5yvMJgkYXVp8sHZm2YoT3YrnKj0jSxGLEH6Kt.NSMPZPps_P.iiql7h.XHpvTdp6uVr6_2fzTF.8rnYMfYT_4od1k4dQ42fKQ5Wu2vJ1wsZDB2z1..W2BMMNY.R2XLpnQrQqJMpThN3graI5hPpqA.8bx92CYkSvto6p8PYpzRKhWwtvYlBy64Vs1rTZUYLvmTckHI2hmcxzdah9N3KlxcUb01IwzW6NYBvbkTHCApbX02X8Mt2FToQvCD6Lgm7.ZHpL2KxjGZL.JOC32D.Mw4meiYgElJjJysXjoYUY4FbvMNygT85VfBI9fnfg8tl7fyyqiJGcroHOdq4HclfxPbpp44C5.2lr1HCIElxy66OV9cmX6ct0Jle3YRSmfD8kfp3OAde1pOdLKyVVM.bP1lhuoXXzcC2uITmhIK0eiye_LILwVtfWiD.vy_hzAU3sOTXvGOtLQ5iJK5JmU11MUHJfW8pZGqJgIl7_OzdZawe4olPURy.pVZG2oS8afOLBo8N29pBMNLEOLd1cuUPjjh2B.RBw8Bp4MOaDrdN7Pu9f6jJwVNIiIyfVTZrZ4UMdQs8HRhTuJ8_1CgDUuGoPU8upQ-- X-Originating-IP: [64.170.98.32] Authentication-Results: mta1000.biz.mail.sk1.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1000.biz.mail.sk1.yahoo.com with SMTP; Wed, 09 Jun 2010 15:00:16 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9AE28C11A; Wed, 9 Jun 2010 15:00:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FC6E3A6872; Wed, 9 Jun 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-turner-md2-to-historic-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100609220002.2FC6E3A6872@core3.amsl.com> Date: Wed, 9 Jun 2010 15:00:02 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MD2 to Historic Status Author(s) : S. Turner Filename : draft-turner-md2-to-historic-00.txt Pages : 6 Date : 2010-6-8 This document recommends the retirement of MD2 and discusses the reasons for doing so. This document recommends RFC 1319 be moved to Historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-turner-md2-to-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-9145328.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------090806050806050406010805-- From prvs=37774d2c9b=uri@ll.mit.edu Thu Jun 10 06:29:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D903A6922; Thu, 10 Jun 2010 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRrW5niQWc7o; Thu, 10 Jun 2010 06:29:48 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id 175DF3A68B9; Thu, 10 Jun 2010 06:29:48 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o5ADIMJC018503; Thu, 10 Jun 2010 09:29:45 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: Sean Turner Date: Thu, 10 Jun 2010 09:29:34 -0400 Thread-Topic: [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Thread-Index: AcsIoPeV/k27F1q7S0Oq7aUCniS0fw== Message-ID: <3DCE88F1-C25D-45DE-B0F4-CD59FE54603C@ll.mit.edu> References: <4C10E308.9060503@ieca.com> In-Reply-To: <4C10E308.9060503@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3DCE88F1C25D45DEB0F4CD59FE54603Cllmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-10_02:2010-02-06, 2010-06-10, 2010-06-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006100074 Cc: "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:29:49 -0000 --_000_3DCE88F1C25D45DEB0F4CD59FE54603Cllmitedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd say - yes, about time. :-) On Jun 10, 2010, at 09:05 AM, Sean Turner wrote: (apologies if you get this multiple times) I'm looking for feedback on this draft that proposes moving MD2 to historic status. Thanks, spt From: "Internet-Drafts@ietf.org" > Date: June 9, 2010 18:00:02 PM EDT To: "i-d-announce@ietf.org" > Subject: I-D ACTION:draft-turner-md2-to-historic-00.txt Reply-To: "internet-drafts@ietf.org" > A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MD2 to Historic Status Author(s) : S. Turner Filename : draft-turner-md2-to-historic-00.txt Pages : 6 Date : 2010-6-8 This document recommends the retirement of MD2 and discusses the reasons for doing so. This document recommends RFC 1319 be moved to Historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_000_3DCE88F1C25D45DEB0F4CD59FE54603Cllmitedu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd say - yes, about time.= :-)


On Jun 10, 2010, at 09:05 AM, Sean Tu= rner wrote:

(apologies if you get this multiple times)

I'm looking for= feedback on this draft that proposes moving MD2 to
historic status.
Thanks,

spt

Date: June 9, 2010 18:00:02 PM ED= T
<= span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(127, 12= 7, 127, 1.0);">Subject: I-D ACTION:draft-turner-md2-to-historic-00.txt
Reply-To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>


A New Internet-Draft is available from the on-line Internet-Draf= ts
directories.


Title <= /span>: MD2 to Historic Status
Author(s) : S. Turner
Filename : draft-turner-md2-to-historic-00.txt
Pages : 6
Date : 2010-6-8

  This document recommends the= retirement of MD2 and discusses the
  reasons for doing so.=  This document recommends RFC 1319 be moved to
  Histo= ric status.


A URL for this Internet-Draft is:
http:= //www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.txt
<= br>Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.iet= f.org/internet-drafts/

Below is the data which will enable a MIME co= mpliant mail reader
implementation to automatically retrieve the ASCII v= ersion of the
Internet-Draft.
<draft-turner-md2-to-historic-= 00.url><ATT00001..txt>

<ATT000= 01..txt>

= --_000_3DCE88F1C25D45DEB0F4CD59FE54603Cllmitedu_-- From pgut001@cs.auckland.ac.nz Thu Jun 10 06:37:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72C13A6A28; Thu, 10 Jun 2010 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lZCIPoVCjnm; Thu, 10 Jun 2010 06:37:24 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A7B5D3A6A2A; Thu, 10 Jun 2010 06:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276177047; x=1307713047; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20simon@josefsson.org,=20turners@ieca.com|Subject: =20Re:=20[Cfrg]=20[Fwd:=20I-D=20ACTION:draft-turner-md2-t o-historic-00.txt]|Cc:=20cfrg@irtf.org,=20pkix@ietf.org, =20saag@ietf.org,=20smime@ietf.org|In-Reply-To:=20<87bpbj ko9d.fsf@mocca.josefsson.org>|Message-Id:=20|Date:=20Fri,=2011 =20Jun=202010=2001:37:08=20+1200; bh=2NTpe579zow3qtXS4N02EkTV7jWEdeU2XdK9mjNaF+U=; b=XyR3nwkuWqPgYImyCWU89zLMEHXtzampHv+y9kB+VWugd4Qy9j3t2lcy AdPTUoElZx3G+fzKbru4fXTKPaBto9o/z88GFwk+1fh6sm9CmlQb6jOoY Mn81mBDWnDp7c+JXyNTIVDmNqLKouu1014c7Cnl4cW8Aq/keddTmO7izD k=; X-IronPort-AV: E=Sophos;i="4.53,398,1272801600"; d="scan'208";a="10440674" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jun 2010 01:37:09 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMhwS-0001On-NR; Fri, 11 Jun 2010 01:37:08 +1200 From: Peter Gutmann To: simon@josefsson.org, turners@ieca.com In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Message-Id: Date: Fri, 11 Jun 2010 01:37:08 +1200 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:37:25 -0000 Simon Josefsson writes: >1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? It helps to have something like this formally retired so you have a document to point to when someone wants to use (or continue to use) MD2. Trying to explain to them the difference between "Informational" and "Standards Track" when their requirement is "must be specified in an RFC" isn't generally useful. (We really need an RFC equivalent of the UK's Great Repeal Bill at some point...). Peter. From simon@josefsson.org Thu Jun 10 06:45:27 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021AB3A6A0F; Thu, 10 Jun 2010 06:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XOW6EgCdkwD; Thu, 10 Jun 2010 06:45:26 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id ADC0B3A6A1D; Thu, 10 Jun 2010 06:45:25 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5ADivii017121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 15:44:58 +0200 From: Simon Josefsson To: Peter Gutmann References: <87bpbjko9d.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:pgut001@cs.auckland.ac.nz::ChhguUKHpZjABR4a:Y+Z X-Hashcash: 1:22:100610:pkix@ietf.org::ELbKJEqBcmWb5oZ9:4lnZ X-Hashcash: 1:22:100610:smime@ietf.org::dVO8LQ41HF3zk4k0:5KdG X-Hashcash: 1:22:100610:cfrg@irtf.org::VT0eNSiMU6DLreZt:5CNU X-Hashcash: 1:22:100610:saag@ietf.org::do2o383DR/37QJrJ:NFue X-Hashcash: 1:22:100610:turners@ieca.com::GsQku9cpvxcZcY8y:kJPb Date: Thu, 10 Jun 2010 15:44:57 +0200 In-Reply-To: (Peter Gutmann's message of "Fri, 11 Jun 2010 01:37:08 +1200") Message-ID: <87eigfj92e.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:45:27 -0000 Peter Gutmann writes: > Simon Josefsson writes: > >>1) MD2 is not on the standards track, it is Informational. I agree with >> wishes to move "poor" documents from the Standards Track to Historic, >> but I'm not sure I see such a big difference between having a "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? > > It helps to have something like this formally retired so you have a document > to point to when someone wants to use (or continue to use) MD2. Trying to > explain to them the difference between "Informational" and "Standards Track" > when their requirement is "must be specified in an RFC" isn't generally > useful. Sure, but MD2 is not used in isolation, it is used in a protocol like TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses of MD2 in these protocol to Historic? That would seem to carry much more weight -- then people cannot continue to support MD2 in these protocol and claim to be compliant with the latest specifications. Note that there are other uses of MD2 that are still fine even if MD2 is not collision resistant. Compare how rsync still uses MD4 for checksum computations, and that won't stop it being a reasonable choice. I'm mostly playing the devil's advocate here, and want to make sure we consider the consequences before giving a flippant +1. /Simon From touch@isi.edu Thu Jun 10 07:03:06 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5A3A6970; Thu, 10 Jun 2010 07:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TazvPLeXBlTZ; Thu, 10 Jun 2010 07:03:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C1FE53A6A0C; Thu, 10 Jun 2010 07:03:05 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5AE0u5l025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 07:01:06 -0700 (PDT) Message-ID: <4C10F018.8040401@isi.edu> Date: Thu, 10 Jun 2010 07:00:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <87bpbjko9d.fsf@mocca.josefsson.org> <87eigfj92e.fsf@mocca.josefsson.org> In-Reply-To: <87eigfj92e.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAEC8484ED9D4BD6862F18201" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: pkix@ietf.org, smime@ietf.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:03:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAEC8484ED9D4BD6862F18201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I agree with Simon. I don't know what it means to move a doc like the MD2= spec to historic even means. It's not standards track. It's not a protocol. AF= AICT, it's just a description of an algorithm. It might be useful to create a "security algorithms roadmap" doc, which l= ists all known alg RFCs, and describes which are useful in various ways, and w= hich are no longer typically used, but singling out MD2 (vs. MD5 except as an = HMAC) seems not particularly useful. Joe Simon Josefsson wrote: > Peter Gutmann writes: >=20 >> Simon Josefsson writes: >> >>> 1) MD2 is not on the standards track, it is Informational. I agree w= ith >>> wishes to move "poor" documents from the Standards Track to Histori= c, >>> but I'm not sure I see such a big difference between having a "poor= " >>> document as Informational or Historic. Especially for a crypto >>> algorithm, which the IETF typically does not put on the standards >>> track at all. Is there some precedent for moving Informational to >>> Historic? >> It helps to have something like this formally retired so you have a do= cument >> to point to when someone wants to use (or continue to use) MD2. Tryin= g to >> explain to them the difference between "Informational" and "Standards = Track" >> when their requirement is "must be specified in an RFC" isn't generall= y >> useful. >=20 > Sure, but MD2 is not used in isolation, it is used in a protocol like > TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses o= f > MD2 in these protocol to Historic? That would seem to carry much more > weight -- then people cannot continue to support MD2 in these protocol > and claim to be compliant with the latest specifications. >=20 > Note that there are other uses of MD2 that are still fine even if MD2 i= s > not collision resistant. Compare how rsync still uses MD4 for checksum= > computations, and that won't stop it being a reasonable choice. >=20 > I'm mostly playing the devil's advocate here, and want to make sure we > consider the consequences before giving a flippant +1. >=20 > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------enigAEC8484ED9D4BD6862F18201 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwQ8BgACgkQE5f5cImnZrv2xwCeKZvycpeI5nqIBub5U7QSG1Mz kRYAnRgvfgCoXTvJBs48lZc4E+cG0pYe =ccm1 -----END PGP SIGNATURE----- --------------enigAEC8484ED9D4BD6862F18201-- From simon@josefsson.org Thu Jun 10 07:04:28 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF583A696E; Thu, 10 Jun 2010 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBcsIKMeg2Bb; Thu, 10 Jun 2010 07:04:27 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 3CB613A68B9; Thu, 10 Jun 2010 07:04:27 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AE1qv8017520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:01:54 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:cfrg@irtf.org::iD7DUTilRnXEF9bP:0uQA X-Hashcash: 1:22:100610:saag@ietf.org::JRWASo4dEHey3f2U:4CiY X-Hashcash: 1:22:100610:turners@ieca.com::eeaWOgUpw/uFMsXc:9qwM X-Hashcash: 1:22:100610:smime@ietf.org::6KD93PXlax1GZNNA:IUxY X-Hashcash: 1:22:100610:pkix@ietf.org::X8Sp1IijYzCOI9it:ew1p X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::wwbDvv4GIds9Al3A:LleC Date: Thu, 10 Jun 2010 16:01:52 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 15:49:17 +0200 (CEST)") Message-ID: <87sk4vhtpr.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:04:28 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as >> recently as (according to NEWS logs) in 2005. If I recall correctly, >> some Verisign root certificates are MD2. Note that in GnuTLS, >> verifying a certificate involving a MD2 digital signature will fail >> because MD2 is insecure, but the algorithm is still implemented and >> supported. > > Verisign had a root cert that was self-signed by MD2. When Dan > Kaminsky and I found that, Dan talked to Versign, and they reissued > the cert signed with SHA-1. The original cert is still valid in older > browsers, but there should no longer be any MD2 certs in use in the > public CA system. (Who knows about private enterprise deployments, > however.) > > I support deprecating MD2. We are one incremental improvement in MD2 > attack speed away from a massive break. A self-signed trust root with MD2 is not a security problem by itself: it is not the digital signature that is trusted, it is the public key in the certificate. The MD2 roots are still shipped and trusted in several modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). I support deprecating MD2 for any purpose that requires a collision resistant function. The current proposal goes further and deprecates MD2 for any use. I don't see much argumentation for deprecating it for non-collision resistant use-cases. /Simon From simon@josefsson.org Thu Jun 10 07:05:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741CC3A697D; Thu, 10 Jun 2010 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9P4cbqgFyuu; Thu, 10 Jun 2010 07:05:49 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7FF923A6A20; Thu, 10 Jun 2010 07:05:49 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AE5hYl017613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:05:45 +0200 From: Simon Josefsson To: Sean Turner References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <4C10F020.4000102@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:turners@ieca.com::coc6vtrPHOwIeITE:8UAW X-Hashcash: 1:22:100610:saag@ietf.org::cEgqujMel70F0cZT:9L+H X-Hashcash: 1:22:100610:pkix@ietf.org::SM1iQiV0m8vqRVki:7MT8 X-Hashcash: 1:22:100610:cfrg@irtf.org::i+lSPmZjrbxnCy0z:IRZN X-Hashcash: 1:22:100610:smime@ietf.org::H0PgqDjekSGceAOS:IjQN Date: Thu, 10 Jun 2010 16:05:43 +0200 In-Reply-To: <4C10F020.4000102@ieca.com> (Sean Turner's message of "Thu, 10 Jun 2010 10:01:04 -0400") Message-ID: <87ocfjhtjc.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:05:51 -0000 Sean Turner writes: > But, what I was thinking was that if we've got an informational > specification of an algorithm that's broken (i.e., obsolete) we should > wave red flags announcing this. One way to do that is to write this > document and an another flag is to put it on a different track than > ones we don't think are broken. This might just be a process thing, > but I think we should be doing this. One alternative would be to supersede (or update) the original RFC with your document, and still have it on Informational status. That approach permits use-cases where a collision resistant function is not required, but still raises the red flags we all want to be there. /Simon From turners@ieca.com Thu Jun 10 07:07:42 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD3628C0E7 for ; Thu, 10 Jun 2010 07:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEa5aB7hDobh for ; Thu, 10 Jun 2010 07:07:42 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id 985123A6970 for ; Thu, 10 Jun 2010 07:07:42 -0700 (PDT) Received: (qmail 8660 invoked from network); 10 Jun 2010 14:01:05 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 10 Jun 2010 07:01:05 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: KPW1RO8VM1krMtzT8Yt64Os1a624dZ9jResMM6aj35MU63CcR0l2.XBG.foq4xi2ONwbe6p397H4blm99_PJOtr8zTPMBnvmV_afKuW5ihtC.znN9_tvd4IkQV5S0v4nIsJvZ4Ni_Rwo9GmWpecqXIqD6iCZ71MhbZb5glKPb3IKYVu2eTevNZNPddyiVPOJKSX7BAARIDTBZbCaRW4kvftgDwbn1FxfjCYLH43eQwH2zMblDgYHioEihGQ9OMg2U2QbdZg12lxibRHFcZtAokEVYHMpXnNFEbA3VaQ8nlhg8PUXiR8dqs0j5FGQSyqLJtOGYAeM8orCekxdVaevVw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C10F020.4000102@ieca.com> Date: Thu, 10 Jun 2010 10:01:04 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:07:42 -0000 Simon Josefsson wrote: > Sean Turner writes: > >> (apologies if you get this multiple times) >> >> I'm looking for feedback on this draft that proposes moving MD2 to >> historic status. > > In general I support this: MD2 should simply not be used. > > However I see two concerns: > > 1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? To be honest I'm not sure there's a precedent. I don't think RFC 2026 says that this can't be done; the definition of Historic is as follows: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) I think if it was just for standards track specifications, it would have said that. But, what I was thinking was that if we've got an informational specification of an algorithm that's broken (i.e., obsolete) we should wave red flags announcing this. One way to do that is to write this document and an another flag is to put it on a different track than ones we don't think are broken. This might just be a process thing, but I think we should be doing this. > 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as > recently as (according to NEWS logs) in 2005. If I recall correctly, > some Verisign root certificates are MD2. Note that in GnuTLS, > verifying a certificate involving a MD2 digital signature will fail > because MD2 is insecure, but the algorithm is still implemented and > supported. > > Thus the text in your document "many TLS implementations, OpenSSL, > Network Security Services, and GNUTLS, have disabled support for MD2" > may not be the entire story. GnuTLS "supports" MD2 even though it > does not consider it secure. I can't speak for OpenSSL or NSS, but I > suspect they implement MD2 too and can verify such digital hashes, > even if they don't consider them secure. Yeah that might have been a bit strong. Maybe: Additionally, many TLS implementations, OpenSSL, Network Security Services, and GNUTLS, support MD2 but recommend it only for backwards compatibility. > Even if these concerns cannot be fully addressed, I would likely still > support this document though. So they are "soft" concerns for me. Thanks, spt From simon@josefsson.org Thu Jun 10 07:22:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF728C121; Thu, 10 Jun 2010 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFEef8ku-+eM; Thu, 10 Jun 2010 07:22:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7FCBA28C0F8; Thu, 10 Jun 2010 07:22:28 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AEK5pW017997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:20:06 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:smime@ietf.org::FOgOV3dYn050dr6M:2OlW X-Hashcash: 1:22:100610:turners@ieca.com::zR5HdSxtl2fDkAHN:2iTH X-Hashcash: 1:22:100610:cfrg@irtf.org::eaoWXvdfE9tgXqNu:56it X-Hashcash: 1:22:100610:saag@ietf.org::IJaj4s48D8Ta0siT:BESu X-Hashcash: 1:22:100610:pkix@ietf.org::yBrNonfhOfOSK3Ua:Kiv4 X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::rcIcGONN4cDuMsfB:Kk1C Date: Thu, 10 Jun 2010 16:20:05 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 16:12:02 +0200 (CEST)") Message-ID: <87typbgeay.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:22:31 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> A self-signed trust root with MD2 is not a security problem by itself: >> it is not the digital signature that is trusted, it is the public key in >> the certificate. The MD2 roots are still shipped and trusted in several >> modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). > > No, it absolutely *is* a security problem. Should someone develop a > preimage attack on MD2, all they need do is move the (valid) MD2 > signature to an intermediate cert with BasicConstraints CA=yes, and > then they have themselves a CA. I don't see how that gains you anything: you still need to make clients place trust in the new CA, and if the attacker has that ability, all bets are off. /Simon From Jeff.Hodges@KingsMountain.com Thu Jun 10 12:13:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EAE28C0D0 for ; Thu, 10 Jun 2010 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je7QL07lsQVV for ; Thu, 10 Jun 2010 12:13:28 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 132453A69AD for ; Thu, 10 Jun 2010 12:13:28 -0700 (PDT) Received: (qmail 9406 invoked by uid 0); 10 Jun 2010 19:13:30 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 10 Jun 2010 19:13:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=2jHMW8fx+DFzpiZdd1HaRYQ8ZFUo/3Mbl89YjyDA16nYn9nUE0JhEIGjBpTHCRFu997ai4+/1SpdXo/rbamhCXiFzLJSI2VXvOe9LfbvgwSHH39/9nNCMStPP5ZwPush; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.109]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OMnBy-0006d8-1T for saag@ietf.org; Thu, 10 Jun 2010 13:13:30 -0600 Message-ID: <4C113959.7040503@KingsMountain.com> Date: Thu, 10 Jun 2010 12:13:29 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [saag] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application Security Minus Authentication and Transport X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:13:30 -0000 Hi, We will be hosting the "HTTP Application Security Minus Authentication and Transport (HASMAT)" Birds-of-a-Feather (BoF) session at IETF-78 in Maastricht NL during the week of July 25-30, 2010 (see [0] for mailing list). The purpose of IETF BoFs is to determine whether there is a problem worth solving, and whether the IETF is the right group to solve it. To that end, the problem statement is summarized below in the Draft HASMAT Working Group Charter, and is drawn from this paper [1]. Various facets of this work are already underway, as outlined below in the draft WG charter, e.g. Strict Transport Security (STS) [2]. Of course the scope of "HTTP application security" is quite broad (as outlined in [1]), thus the intent is to coordinate this work closely with related work likely to land in the W3C (and possibly other orgs), e.g. Content Security Policy (CSP) [3]. We have created a public mailing list [0] for pre-BoF discussion -- hasmat@ietf.org -- to which you can freely subscribe here: We encourage all interested parties to join the hasmat@ mailing list and engage in the on-going discussion there. thanks, =JeffH (current IETF HTTPstate WG chair) Peter Saint-Andre (IETF Applications Area Director) Hannes Tschofenig (IAB, IETF WG chair) ---------------------------------------------------- [0] HASMAT mailing list. https://www.ietf.org/mailman/listinfo/hasmat [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy Framework", W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf [2] Hodges, Jackson, and Barth, "Strict Transport Security (STS)", revision -06. http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html see also: http://en.wikipedia.org/wiki/Strict_Transport_Security [3] Sterne and Stamm, "Content Security Policy (CSP)". https://wiki.mozilla.org/Security/CSP/Specification see also: http://people.mozilla.org/~bsterne/content-security-policy/ https://wiki.mozilla.org/Security/CSP/Design_Considerations ### Proposed HASMAT BoF agenda -------------------------- Chairs: Hannes Tschofenig and Jeff Hodges 5 min Agenda bashing (Chairs) 10 min Description of the problem space (TBD) 20 min Motivation for standardizing (TBD) draft-abarth-mime-sniff draft-abarth-origin draft-hodges-stricttransportsec (to-be-submitted) 15 min Presentation of charter text (TBD) 60 min Discussion of charter text and choice of the initial specifications (All) 10 min Conclusion (Chairs/ADs) ### Draft Charter for HASMAT: HTTP Application Security Minus Authentication and Transport WG Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to standardize a small number of selected specifications that have proven to improve security of Internet Web applications. The requirements guiding the work will be taken from the Web application and Web security communities. Initial work will be limited to the following topics: - Same origin policy, as discussed in draft-abarth-origin - Strict transport security, as discussed in draft-hodges-stricttransportsec (to be submitted shortly) - Media type sniffing, as discussed in draft-abarth-mime-sniff In addition, this working group will consider the overall topic of HTTP application security and compose a "problem statement and requirements" document that can be used to guide further work. This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as W3C WebApps working group(s). Out of Scope As noted in this working group's title, this working group's scope does not include working on HTTP Authentication nor underlying transport (secure or not) topics. So, for example, these items are out-of-scope for this WG: - Replacements for BASIC and DIGEST authentication - New transports (e.g. SCTP and the like) Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. Goals and Milestones Oct 2010 Submit "HTTP Application Security Problem Statement and Requirements" as initial WG item. Oct 2010 Submit "Media Type Sniffing" as initial WG item. Oct 2010 Submit "Web Origin Concept" as initial WG item. Oct 2010 Submit "Strict Transport Security" as initial WG item. Feb 2011 Submit "HTTP Application Security Problem Statement and Requirements" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Strict Transport Security" to the IESG for consideration as a Standards Track RFC. Apr 2011 Possible re-chartering ### From sm@resistor.net Thu Jun 10 12:55:48 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD53A67EC for ; Thu, 10 Jun 2010 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkByH-eBw0rx for ; Thu, 10 Jun 2010 12:55:45 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id CA26C3A6783 for ; Thu, 10 Jun 2010 12:55:45 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o5AJtHdb013027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 12:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1276199744; x=1276286144; bh=byVpTNimeVlzjUk8zg7i0P5H+fiDaULMtIo52Ed2Z3Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Jq0jtM1kQFdMapuOKlaOJdd0vO9SRnggkmp2Je3RY5oPX8zBXXZfEacoWdXPU49CP QNzQp+nIL8ZvJ43/1vF5X4fmxPR0KkGTAPfvzPHSu0tAqt2KzK6zEoZ4Sp+b/Gup9k CKAcKlFC2hhkuqtbgDVO9DOHr0wTB2ZxGoLuLQ48= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1276199744; x=1276286144; bh=byVpTNimeVlzjUk8zg7i0P5H+fiDaULMtIo52Ed2Z3Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=UD1c2xTd85wc3zO8LlEgr2WYheo7Pn0DKVMnF9yzn2/uBWW4bnhRTRehIYvtyveMO 01NJ3d+I2IpA93pUraB5CELN6j+rlvRmB1hiuVpZkQuUqUI8O+XnbdpZlRm0Bcf6pU 3QI6mKhLL/ZPzKhGKxyVqeWw3DYajGrUoamiUW+g= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=txd3P6TNvEYu+wKJi/cHAdD9dTN3lys3b9o49AEXR1NkWBfvRDOu9Ef2XBLyjHtam PqFhk9trZb900I/mOh4mFqYL8J9mshQc4WHlfxruI2Bv6gNN6xknyzbu+H0pFUMfwTh SC2T/aD8DZvbBgSeGaT20GQ2aHGcfEe4m7pM/Lc= Message-Id: <6.2.5.6.2.20100610123606.0af32220@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jun 2010 12:54:29 -0700 To: Sean Turner From: SM In-Reply-To: <4C10E308.9060503@ieca.com> References: <4C10E308.9060503@ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:55:48 -0000 Hi Sean, At 06:05 10-06-10, Sean Turner wrote: >I'm looking for feedback on this draft that proposes moving MD2 to >historic status. Section 1.1 is not needed. The keywords in Section 5 and 7 are not needed. RFC 2246, RFC 2459, RFC 2313 and RFC 2437 are obsolete. RFC 1423 does not have to be mentioned as it is Historic. Regards, -sm From simon@josefsson.org Thu Jun 10 13:20:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A6F3A672E; Thu, 10 Jun 2010 13:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVNPp0Oq0P00; Thu, 10 Jun 2010 13:20:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8A5B33A6784; Thu, 10 Jun 2010 13:20:27 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AKJhcs031800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 22:19:46 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> <87typbgeay.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:smime@ietf.org::utAmCPfHI9SJWL0I:0fsU X-Hashcash: 1:22:100610:cfrg@irtf.org::Pes+7/Dm6OxJlQOo:2C4C X-Hashcash: 1:22:100610:saag@ietf.org::J0jt656oVj4YfgKD:9pjc X-Hashcash: 1:22:100610:turners@ieca.com::3JRdNsWExaMzsE9f:DVC4 X-Hashcash: 1:22:100610:pkix@ietf.org::wrDtcvYMC3EU4dqQ:I1dd X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::ZYiMNjpfpNPoCM7P:J4Vl Date: Thu, 10 Jun 2010 22:19:43 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 18:59:08 +0200 (CEST)") Message-ID: <8739wuej34.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:20:31 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> I don't see how that gains you anything: you still need to make clients >> place trust in the new CA, and if the attacker has that ability, all >> bets are off. > > The clients trust the new CA because it is an intermediate CA chained > to the original, MD2-signed top-level CA. The intermediate cert is > then treated with the same validity as *any* intermediate cert > generated by that top-level cert -- since the top-level cert's > signature verifies correctly on the intermediate cert, of course. > > Do you understand the attack now? Yes, I do, but that attack is not caused by a MD2 root. The attack is caused by software trusting MD2 to verify digital signatures. I believe the latter has been resolved in most security libraries already (it certainly has been resolved in GnuTLS, since January 2009, which treats both MD2 and MD5 as insecure). The former case (a MD2 root) is not a problem by itself, as far as I can tell, which is what I originally stated. As long as MD2 roots have not been shown to be a problem, by themselves, protocols and software will need to continue implement MD2 for operational reasons. There are still several MD2 roots in recently shipping operating systems. For example, my Ubuntu 10.04 LTS system has these RSA-MD2 roots: ./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: Issuer: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification Authority ./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority ./mozilla/Verisign_RSA_Secure_Server_CA.crt Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification Authority ./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt Issuer: C=US,O=VeriSign\, Inc.,OU=Class 2 Public Primary Certification Authority Right now, I think my preference would be to update RFC 1319 with something like Sean's document, to alert everyone of the security issues, but let the status of the algorithm description remain Informational. /Simon From SChokhani@cygnacom.com Thu Jun 10 18:18:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5D63A68C8; Thu, 10 Jun 2010 18:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORrO3exq3QCa; Thu, 10 Jun 2010 18:18:34 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id F3D273A68AA; Thu, 10 Jun 2010 18:18:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: SChokhani@cygnacom.com X-Msg-Ref: server-8.tower-75.messagelabs.com!1276219114!94418028!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.19] Received: (qmail 29481 invoked from network); 11 Jun 2010 01:18:35 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.19) by server-8.tower-75.messagelabs.com with SMTP; 11 Jun 2010 01:18:35 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Jun 2010 21:18:33 -0400 Message-ID: In-Reply-To: <8739wuej34.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Thread-Index: AcsI2mXcUs38m5trTNi+CvMoiCWxBgAKKTOw References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org><87sk4vhtpr.fsf@mocca.josefsson.org><87typbgeay.fsf@mocca.josefsson.org> <8739wuej34.fsf@mocca.josefsson.org> From: "Santosh Chokhani" To: "Simon Josefsson" , "Len Sassaman" Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 01:18:35 -0000 Len, I agree with Simon. Security strength of hash in self-signed certificate is irrelevant. It is an untrusted object. You might use the world's weakest hash or not sign it at all. That said, if you process that MD2, you may end up invoking it for other certificates. But, as Open SSL folks posted in this thread, they do not verify signatures on self-signed certificates, obviating the need for MD2. > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > Simon Josefsson > Sent: Thursday, June 10, 2010 4:20 PM > To: Len Sassaman > Cc: pkix@ietf.org; cfrg@irtf.org; saag@ietf.org; smime@ietf.org > Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic- > 00.txt] >=20 > Len Sassaman writes: >=20 > > On Thu, 10 Jun 2010, Simon Josefsson wrote: > > > >> I don't see how that gains you anything: you still need to make > clients > >> place trust in the new CA, and if the attacker has that ability, all > >> bets are off. > > > > The clients trust the new CA because it is an intermediate CA chained > > to the original, MD2-signed top-level CA. The intermediate cert is > > then treated with the same validity as *any* intermediate cert > > generated by that top-level cert -- since the top-level cert's > > signature verifies correctly on the intermediate cert, of course. > > > > Do you understand the attack now? >=20 > Yes, I do, but that attack is not caused by a MD2 root. The attack is > caused by software trusting MD2 to verify digital signatures. I > believe > the latter has been resolved in most security libraries already (it > certainly has been resolved in GnuTLS, since January 2009, which treats > both MD2 and MD5 as insecure). >=20 > The former case (a MD2 root) is not a problem by itself, as far as I > can > tell, which is what I originally stated. >=20 > As long as MD2 roots have not been shown to be a problem, by > themselves, > protocols and software will need to continue implement MD2 for > operational reasons. There are still several MD2 roots in recently > shipping operating systems. For example, my Ubuntu 10.04 LTS system > has > these RSA-MD2 roots: >=20 > ./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 1 Public Primary > Certification Authority > ./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 3 Public Primary > Certification Authority > ./mozilla/Verisign_RSA_Secure_Server_CA.crt > Issuer: C=3DUS,O=3DRSA Data Security\, Inc.,OU=3DSecure Server > Certification Authority > ./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 2 Public Primary > Certification Authority >=20 > Right now, I think my preference would be to update RFC 1319 with > something like Sean's document, to alert everyone of the security > issues, but let the status of the algorithm description remain > Informational. >=20 > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From pgut001@cs.auckland.ac.nz Thu Jun 10 19:58:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0123A69AC; Thu, 10 Jun 2010 19:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfp79rxq3QMO; Thu, 10 Jun 2010 19:58:48 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D2E783A681F; Thu, 10 Jun 2010 19:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276225131; x=1307761131; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Len.Sassaman@esat.kuleuven.be,=20simon@josefsson.o rg|Subject:=20Re:=20[Cfrg]=20[Fwd:=20I-D=20ACTION:draft-t urner-md2-to-historic-00.txt]|Cc:=20cfrg@irtf.org,=20pkix @ietf.org,=20saag@ietf.org,=20smime@ietf.org,=0D=0A=20=20 =20=20turners@ieca.com|In-Reply-To:=20|Message-Id:=20|Date:=20 Fri,=2011=20Jun=202010=2014:58:49=20+1200; bh=q+Y7TzdMHTtRIm2gaHbjhVyJtG4MdnAPEJbaFFGEJWA=; b=H3R/uHh2vEPdjv58qPdxo8LRwIZybXS53MQ28EzDJcxN34LKrZH1Y+gL qEZomeqR/iV2NFNp9IS/4ttZBQS+vpNyUkUV6NnaPDibh8TOQnr0mIJpd gPwoC5wf7dx+I9nY6kzIpq3LSFAvftIEewWdAPToBQAVnOvq1UDQlZ79Q U=; X-IronPort-AV: E=Sophos;i="4.53,401,1272801600"; d="scan'208";a="10555471" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jun 2010 14:58:49 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMuSH-0002U8-7p; Fri, 11 Jun 2010 14:58:49 +1200 From: Peter Gutmann To: Len.Sassaman@esat.kuleuven.be, simon@josefsson.org In-Reply-To: Message-Id: Date: Fri, 11 Jun 2010 14:58:49 +1200 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 02:58:49 -0000 Len Sassaman writes: >(At least, I personally verifed Chrome and FireFox. I *think* IE and Opera >were patched, too -- they should be.) So now we hope that browsers released >prior to mid-2009 are retired from use before MD2 is broken in practice. >Given the longevity of browsers, it's going to be close. I assume you're thinking of IE6 there :-). Was the fix done in CryptoAPI or in the browser itself? If it was an update to CryptoAPI then even IE6 should be OK (can anyone from MS comment on this?). Peter. From turners@ieca.com Fri Jun 11 09:03:25 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F058D3A690C for ; Fri, 11 Jun 2010 09:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBgulad9Xero for ; Fri, 11 Jun 2010 09:03:24 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id EB31A3A68A3 for ; Fri, 11 Jun 2010 09:03:23 -0700 (PDT) Received: (qmail 57766 invoked from network); 11 Jun 2010 15:47:52 -0000 Received: from thunderfish.local (turners@96.241.3.207 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 11 Jun 2010 08:47:51 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: izLdZJMVM1n6t7sSP3zEx8lT06nWpxBdjale0pwDEBDzKgRiFCJ8oIaKiI0xPBFyIUxNf0PDSCixWKMuX4rLSlq4Q3LhiBDsyENPdEZ8Sk1seWGWc1yK4QyGa4y9vDKXixvY7bwZixgh4WtafvbnSjHlotG9WWy5llT2G1touaLXjioceb_8I7YoNXkZT_z7VmoMkjMosaxpYj_G36upyPJJ7THq16q9R01P2VafSEscAmCE7CNoqSrHtIqpR.1jzf7AAkQjP9f5X1yw3cqEuU1bY_lg_Mn7NLc5bDi076Lzx4dWyAm1V_rgmfhR3aAn9Bzi.w0Ljeqxr_KaQ_bB9xBxd_axeBjR_e51TH_rck20fmyp2v_S8c3gocXRBG0G2Ew8luVs28pVof1eCGgpWdtJZ._8Jgtnh7ouQdcCf8Kx887QE7yw0qWTwip0bhEJ6iHwy6MTvYRGug-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C125AA7.3020208@ieca.com> Date: Fri, 11 Jun 2010 11:47:51 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: multipart/mixed; boundary="------------020003060705060307060406" Subject: [saag] [Fwd: Last Call: draft-mcgrew-fundamental-ecc (Fundamental Elliptic Curve Cryptography Algorithms) to Informational RFC] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 16:03:25 -0000 This is a multi-part message in MIME format. --------------020003060705060307060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This should be of interest to members on this list. spt --------------020003060705060307060406 Content-Type: message/rfc822; name="Last Call: draft-mcgrew-fundamental-ecc (Fundamental Elliptic Curve CryptographyAlgorithms) to Informational RFC.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Last Call: draft-mcgrew-fundamental-ecc (Fundamental Ellipti"; filename*1="c Curve Cryptography Algorithms) to Informational RFC.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.77; Fri, 11 Jun 2010 08:23:28 -0700 Received-SPF: pass (mta1001.biz.mail.mud.yahoo.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: USRZA20cZArIjVa12VE0jSrVAg.KohkfRqx5FH6NpuRNMQFJ2wDMBldSFpyqcOKvHTlqw_oEU_fjtR0uUmAqjyJ7p952o951Tp3hVtCnoAtNgrIFcdW_TUJVhlbBuel1w0DaXw.GkrxWBwAz.Qojj.iH359Q8HbK5udqeY18MSkbL_KvJIH8M3SSyTWF0aLuJBd139tR97yF6v5hfboSRCXt2Egj1xcCh.iEQDej9AtWITPVaOzX2f8OLqqBahEITjcGD78kExHIxWGnjwu045i_XIyrQeYLMyEuuyyHOQqpS4585NGmaTVZQTf8ElLUEQ3R3Zf01Yxz.iRqKu65R5bgTBQC4H3b.gdmDpVOuHKdannOVdq8O_F.17hnRuOaDOAl5GG1OcreGPm95VUiSz_I1Iw21sUkKE5ebC_R3BJ4c6K2xBDGYG2rBVWTS2e1IkFnJSSWTzeEvFTalJk2k38sLGtSd6XctO1toBo1D9da6K9E_sb.yu9ZL5ZzBBxf2KMnQEeBDo7lwqVKTWxmC3xGmVfKJZJdHI8vyq7Ug0xCtTvn57FNBr4EN8wuw3f1Z9NHXJm_vlf7zEo6HPKW3id44E.BGLgqIT8dU1Q- X-Originating-IP: [64.170.98.32] Authentication-Results: mta1001.biz.mail.mud.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1001.biz.mail.mud.yahoo.com with SMTP; Fri, 11 Jun 2010 08:23:27 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF0C3A68E7; Fri, 11 Jun 2010 08:22:12 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2B9473A6A07; Fri, 11 Jun 2010 08:21:12 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-mcgrew-fundamental-ecc (Fundamental Elliptic Curve Cryptography Algorithms) to Informational RFC Message-Id: <20100611152115.2B9473A6A07@core3.amsl.com> Date: Fri, 11 Jun 2010 08:21:13 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Fundamental Elliptic Curve Cryptography Algorithms ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mcgrew-fundamental-ecc-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18855&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------020003060705060307060406-- From paul.hoffman@vpnc.org Fri Jun 11 09:09:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C0C3A698E for ; Fri, 11 Jun 2010 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.687 X-Spam-Level: X-Spam-Status: No, score=0.687 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1r8ks3fkzsX for ; Fri, 11 Jun 2010 09:09:35 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E4E5E28C108 for ; Fri, 11 Jun 2010 09:09:34 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5BG9aRO059613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 09:09:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C125AA7.3020208@ieca.com> References: <4C125AA7.3020208@ieca.com> Date: Fri, 11 Jun 2010 09:09:34 -0700 To: saag@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [saag] [Fwd: Last Call: draft-mcgrew-fundamental-ecc (Fundamental Elliptic Curve Cryptography Algorithms) to Informational RFC] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 16:09:35 -0000 At 11:47 AM -0400 6/11/10, Sean Turner wrote: >The IESG has received a request from an individual submitter to consider >the following document: > >- 'Fundamental Elliptic Curve Cryptography Algorithms ' > as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2010-07-09. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-mcgrew-fundamental-ecc-03.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18855&rfc_flag=0 This is the draft that was discussed at the SAAG meeting in Anaheim; slides from the talk are at . There was a generally good response to the talk, and the entire IETF would be well-served by as much review of this document as possible. --Paul Hoffman, Director --VPN Consortium From turners@ieca.com Fri Jun 11 14:43:34 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195283A659B for ; Fri, 11 Jun 2010 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44RCC6HFjmtL for ; Fri, 11 Jun 2010 14:43:33 -0700 (PDT) Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id 6BA5B3A63CB for ; Fri, 11 Jun 2010 14:43:33 -0700 (PDT) Received: (qmail 39958 invoked from network); 11 Jun 2010 21:43:33 -0000 Received: from thunderfish.local (turners@96.241.3.207 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 11 Jun 2010 14:43:33 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: LPnHKI4VM1nPKOUwcZ.icjY.d9gwhnnMvSLHHgknOPGZLGO59aoorub8.xpJ57p9jsxS3STafZ_508d7_Cc8Mm03o46qJjthBQHQNd2bcg3.tjJ_nRxqLNHi.kKAl679pP70A4OSSipnhH7VshE44eGNra68MELsf2jA.3d4WYUfFtMnRTSk0qlScjOoKD5SR3aN9G8qlgK_jVFnKVx.VdjLRUOzJJYy8goLg1gk3Ior21Pu1w13OyWzSRnVDxeQlE_kltlZqyUT8HHg1Tz021FKVjLhncgUy6yPMphcS78xtltC.qsjTFG2wwSVq_e5A5C90G8HKrwZCvr91WzTBw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C12AE04.6070009@ieca.com> Date: Fri, 11 Jun 2010 17:43:32 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org References: <4C0D24CB.2020306@ieca.com> In-Reply-To: <4C0D24CB.2020306@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] IETF 78 Meeting Requests (so far) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:43:34 -0000 The following sessions have also been requested: KRB-WG MSEC NEA* I've heard that LTANS wants to meet but haven't seen the session request yet. spt * Should have been included on the original list. Sean Turner wrote: > To date we've received meeting requests from the following WGs: > > EMU > DKIM > IPSECME > PKIX > SAAG > TLS > > Just a reminder 2010-06-14 (next Monday) is the cutoff to request a WG > session. > > We've also got one BOF scheduled: FEDAUTH. > > spt > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From tobias.gondrom@gondrom.org Sat Jun 12 06:24:55 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF413A69AC for ; Sat, 12 Jun 2010 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.638 X-Spam-Level: **** X-Spam-Status: No, score=4.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86MjYjI84YIs for ; Sat, 12 Jun 2010 06:24:54 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 20DAC3A67B3 for ; Sat, 12 Jun 2010 06:24:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=qLNYff5LpJ5dn6tj7pGSjJz7EjQyCPM4pTPOw3lAWzSd6jIIXvia8n8TsEBmlLGWkm2g/2XNhjSKEDV+QjDYC+mMufufBGf/t+qvHqvBE7ii/3QaHY7A49qPc8XoRxBO; h=Received:Received:Message-ID:Disposition-Notification-To:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 11878 invoked from network); 12 Jun 2010 15:24:07 +0200 Received: from static-16-148-145-212.ipcom.comunitel.net (HELO ?10.4.243.123?) (212.145.148.16) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jun 2010 15:24:07 +0200 Message-ID: <4C138A76.5050703@gondrom.org> Date: Sat, 12 Jun 2010 14:24:06 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: saag@ietf.org References: <4C0D24CB.2020306@ieca.com> <4C12AE04.6070009@ieca.com> In-Reply-To: <4C12AE04.6070009@ieca.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tgondrom@gmx.net Subject: Re: [saag] IETF 78 Meeting Requests (so far) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 13:24:55 -0000 Sean, LTANS will meet. Session request has been posted a week ago. Will forward you the session request confirmation via email in a minute, if you don't see it in your system, please let me know, in case the system screwed up. BR, Tobias (co-chair of ltans) On 11/06/10 22:43, Sean Turner wrote: > The following sessions have also been requested: > > KRB-WG > MSEC > NEA* > > I've heard that LTANS wants to meet but haven't seen the session > request yet. > > spt > > * Should have been included on the original list. > > Sean Turner wrote: >> To date we've received meeting requests from the following WGs: >> >> EMU >> DKIM >> IPSECME >> PKIX >> SAAG >> TLS >> >> Just a reminder 2010-06-14 (next Monday) is the cutoff to request a >> WG session. >> >> We've also got one BOF scheduled: FEDAUTH. >> >> spt >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From jaltman@secure-endpoints.com Tue May 18 08:46:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6563A6A0D for ; Tue, 18 May 2010 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg2m4guXMqoA for ; Tue, 18 May 2010 08:46:59 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 37CAB3A6BFA for ; Tue, 18 May 2010 08:46:40 -0700 (PDT) Received: from www.secure-endpoints.com (cpe-24-193-47-88.nyc.res.rr.com [24.193.47.88]) (user=jea31 mech=LOGIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4IFkUYV029145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 May 2010 11:46:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1274197544; x=1274802344; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=QuN5fkVr9M13dN8OGH JK54Sxvx0X+f2rgCoNwIYknAk=; b=xFBLcUqFfP2Ocp1+oIVizmIH2sCdqrjtRu Yuev9TtXYCu+q1FOl8z6vDfhKlBmAgYJCjkeGn5NSLuLL3fYoERno5Drst4+o4WK 64y3FabxlZeckDFXOQyJ21RW944nrjXGRYfqo7mTAv4McnxQGFpe2AUvTaRpqDLu TwwK/79bk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=K5E8QVxy2mOpv8J3BMg7uNM33JaZketU8wlGwgrBhPUMvGlDNRgpktmDo2jR LRUDUo53j+8Z6btaQf0N9TP6nNFg8QY0h5ooeQmKCL/GKt5f8eb42QlgJ mArcTGnVnHlgNTCPvkEt2u0QjsCGwYW3Vk67ZQJCSDmtr21yqBdB4s=; X-MDAV-Processed: www.secure-endpoints.com, Tue, 18 May 2010 11:45:44 -0400 Received: from [172.16.1.5] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v11.0.1) with ESMTP id md50000239235.msg for ; Tue, 18 May 2010 11:45:42 -0400 X-Spam-Processed: www.secure-endpoints.com, Tue, 18 May 2010 11:45:42 -0400 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=ool-457cc3af.dyn.optonline.net (ip=69.124.195.175) (www.secure-endpoints.com) X-MDHeloLookup-Result: hardfail smtp.helo=[172.16.1.5] (does not match 69.124.195.175) (www.secure-endpoints.com) X-Authenticated-Sender: jaltman@secure-endpoints.com X-MDRemoteIP: 69.124.195.175 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: saag@ietf.org Message-ID: <4BF2B64D.60907@secure-endpoints.com> From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: jhutz@cmu.edu References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> <4BF21ADF.5090301@secure-endpoints.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080900000009040609030008" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 18 May 2010 15:46:59 -0000 X-Original-Date: Tue, 18 May 2010 11:46:21 -0400 X-List-Received-Date: Tue, 18 May 2010 15:46:59 -0000 This is a cryptographically signed message in MIME format. --------------ms080900000009040609030008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/18/2010 11:09 AM, Jeffrey Hutzelman wrote: > >> Not only do I believe it is out of scope but that it should actively b= e >> avoided. The Kerberos v5 credential cache does not have the appropria= te >> infrastructure to manage non-Kerberos tickets. > > You appear to be saying "it won't work", but that is demonstrably > untrue. If you think we should actively discourage this feature, you > need a stronger argument than that. > > -- Jeff It works with a particular implementation of a FILE: credential cache. =20 That is all. I have over the years proposed several modifications to the MIT credential cache apis to permit the storage of object types other than Kerberos v4 and Kerberos v5 tickets. There was always very strong objection to the notion that the credential cache API should become a mechanism for storing PGP keys, Cert/key pairs, and other credential forms.=20 While it is entirely possible to lie to the credential cache API and tell it that you are storing a Kerberos v5 ticket when you aren't, doing so has a negative impact on the usability of klist and other tools.=20 Besides which, where a cert is stored has nothing to do with the protocol and as such (in my opinion) should not be a part of an Internet-Draft. Jeffrey Altman --------------ms080900000009040609030008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6 y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF 9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/ QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6 m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4 Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/ bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2 Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MTgxNTQ2MjFaMCMGCSqGSIb3DQEJBDEWBBTLsPoz OVAxhesn3eMIl23J/EVUVzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs 9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBAAV32o3/On99VO4PBN2nN3SvI6z3lEuH4GWb oMeTwWoYZEiW95YlmgI24/A60P0sXt+jw8F7xsr8ncAS+tDD6DEKzzokRkNEvxiD/UETk5P0 pCXQ5Hygy26E/dp8MdNj1J44qRdFsJLA1npG/npPKr+41V2XjJdiwXVkcqKOt2S5cjGZR43C O8QkZ59hYqYFgYKto/cQ2//NJB95He1NDcSgcxPjHeeBVb9DUOQh9W5yDFfccORdJaWx5HCE LLNZXRFZeruoXP+xeaVGXaMu7iid/z1n7MWjoCz/Qk55Trsd8e5SZV/n7TtDL/Ax7xOIhb88 HI8ApOhl9xbjR5T4Dk8AAAAAAAA= --------------ms080900000009040609030008-- From stefan@aaa-sec.com Thu May 20 06:56:16 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47EB3A6C35 for ; Thu, 20 May 2010 06:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8jYiT1aUS83 for ; Thu, 20 May 2010 06:56:15 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id BC7A93A6C1F for ; Thu, 20 May 2010 06:56:11 -0700 (PDT) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4D561293505 for ; Thu, 20 May 2010 15:56:08 +0200 (CEST) Received: (qmail 53614 invoked from network); 20 May 2010 13:56:02 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 May 2010 13:56:02 -0000 User-Agent: Microsoft-Entourage/12.24.0.100205 From: Stefan Santesson To: "Henry B. Hotz" , , , Message-ID: Thread-Topic: [pkix] Draft KX509 Proposal Thread-Index: Acr4JC4i44Oh8BJya0WIFp6+/pjxqw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 20 May 2010 13:56:16 -0000 X-Original-Date: Thu, 20 May 2010 15:56:01 +0200 X-List-Received-Date: Thu, 20 May 2010 13:56:16 -0000 I'm replying to the initial message, having read the whole thread (at least the part that has been sent to the PKIX list). There are many things with this draft and the discussion which confuses me and I would be happy if you could help un-confuse me. Firstly I don't see the relevance of the discussion at large in relation to the draft. A lot of things discussed refers to use of name forms, trust policies and the potential use of a KCA certificates for PKINIT. Even though that is very interesting, I don't see anything in the draft that states that a KCA issues certificates for any particular purpose. Strictly reading the draft I see a CA that calls itself KCA only based on the fact that it can accept this form of request supported by Kerberos authentication. If that is true, then the issued certificate could be any type of certificate used for any purpose. The Kerberos ticket is then reduced to a means of authentication and optionally a source of subject name information (Kerberos principal name). However, I see nothing that prevents the KCA to map the authenticated Kerberos ticket to any other identity data based on a local identity database trusted by the KCA. If so, then I don't understand why you would limit the lifetime of the certificate to the lifetime of the ticket. Compare if I use an ID-card to authenticate my identity to the passport issuance service, that does not mean that my passport will be limited to the validity of my id-card. The only thing is that my ID-card is valid when it is used. I don't understand why we need to invent a new certificate request format. PKIX have already gone through the pain to develop certificate request formats that are widely deployed. An obvious flaw in the current draft is the lack of proof-of-possession of the corresponding private key, which would be avoided if an existing request format was used. Maybe small issue. The protocol has no wait message. It only delivers either a certificate or an error. What if the request is pending for some reason? Finally I don't understand why you need to limit the protocol to UDP, or even why you need to specify the use of UDP in the first place. /Stefan On 10-05-14 3:32 AM, "Henry B. Hotz" wrote: > I have just submitted the KX509 draft which I discussed in the Kerberos > working group in Anaheim. It's available at > https://datatracker.ietf.org/doc/draft-hotz-kx509/. > > The immediate question is where (if anywhere) should work on this draft take > place. Since it's function is to translate Kerberos tickets into X.509 > certificates, it might equally be handled by the krb-wg, or pkix. Since I > understand it's outside the precise charter of both, perhaps saag should step > in. > > What interest is there in handling work on this? > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Fri May 21 12:52:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9123A684B; Fri, 21 May 2010 12:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6th+ERaXHpMr; Fri, 21 May 2010 12:52:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 05EA93A7C3F; Fri, 21 May 2010 06:41:34 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4LDfRbS021636; Fri, 21 May 2010 09:41:28 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4LDfRDn021625; Fri, 21 May 2010 09:41:27 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 21 May 2010 09:41:27 -0400 From: "Miller, Timothy J." To: "'Stefan Santesson'" , "Douglas E. Engert" Thread-Topic: [pkix] [Ietf-krb-wg] Draft KX509 Proposal Thread-Index: Acr4ZgZT6zhHkxgzUkmHbRC7jXjbtQAhStgw Message-ID: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5E6@IMCMBX2.MITRE.ORG> References: <4BF561C7.10500@anl.gov> 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-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 21 May 2010 19:52:57 -0000 X-Original-Date: Fri, 21 May 2010 09:41:26 -0400 X-List-Received-Date: Fri, 21 May 2010 19:52:57 -0000 >That certainty brings a lot of clarity. If this is documenting an >existing protocol, then that should be clearly stated. Perhaps it is and I= just >missed it? Also, if it's only documenting only the existing protocol, shouldn't it be = on the info track instead? -- Tim From simon@josefsson.org Thu Jun 10 06:32:08 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C958F3A6A26; Thu, 10 Jun 2010 06:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3AaL-1XalWT; Thu, 10 Jun 2010 06:32:02 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id C18EC3A6A1F; Thu, 10 Jun 2010 06:31:59 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5ADVQi0016714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 15:31:32 +0200 From: Simon Josefsson To: Sean Turner References: <4C10E308.9060503@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:turners@ieca.com::zz/Cg7ph4i1/aCXj:0+rs X-Hashcash: 1:22:100610:saag@ietf.org::tLcs4tEQZJMaBi7F:6Xgy X-Hashcash: 1:22:100610:cfrg@irtf.org::4E+d5Tu3VmEuePAU:FDZ6 X-Hashcash: 1:22:100610:smime@ietf.org::utMUQRE/CqAUeKvk:SLGb X-Hashcash: 1:22:100610:pkix@ietf.org::Ob8s8AzYfEuSS/kl:aSs4 Date: Thu, 10 Jun 2010 15:31:26 +0200 In-Reply-To: <4C10E308.9060503@ieca.com> (Sean Turner's message of "Thu, 10 Jun 2010 09:05:12 -0400") Message-ID: <87bpbjko9d.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:32:09 -0000 Sean Turner writes: > (apologies if you get this multiple times) > > I'm looking for feedback on this draft that proposes moving MD2 to > historic status. In general I support this: MD2 should simply not be used. However I see two concerns: 1) MD2 is not on the standards track, it is Informational. I agree with wishes to move "poor" documents from the Standards Track to Historic, but I'm not sure I see such a big difference between having a "poor" document as Informational or Historic. Especially for a crypto algorithm, which the IETF typically does not put on the standards track at all. Is there some precedent for moving Informational to Historic? 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as recently as (according to NEWS logs) in 2005. If I recall correctly, some Verisign root certificates are MD2. Note that in GnuTLS, verifying a certificate involving a MD2 digital signature will fail because MD2 is insecure, but the algorithm is still implemented and supported. Thus the text in your document "many TLS implementations, OpenSSL, Network Security Services, and GNUTLS, have disabled support for MD2" may not be the entire story. GnuTLS "supports" MD2 even though it does not consider it secure. I can't speak for OpenSSL or NSS, but I suspect they implement MD2 too and can verify such digital hashes, even if they don't consider them secure. Even if these concerns cannot be fully addressed, I would likely still support this document though. So they are "soft" concerns for me. /Simon From len.sassaman@esat.kuleuven.be Thu Jun 10 06:49:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318E93A6968; Thu, 10 Jun 2010 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbEivEAQNxlz; Thu, 10 Jun 2010 06:49:18 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (cavuit01.kulnet.kuleuven.be [134.58.240.43]) by core3.amsl.com (Postfix) with ESMTP id 4ACBF3A6970; Thu, 10 Jun 2010 06:49:18 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id B0BC67B8050; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id A4326F3863; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id BFB8548002; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id B97A1E5E46; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id B7378E5DF4; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Date: Thu, 10 Jun 2010 15:49:17 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:49:19 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as > recently as (according to NEWS logs) in 2005. If I recall correctly, > some Verisign root certificates are MD2. Note that in GnuTLS, > verifying a certificate involving a MD2 digital signature will fail > because MD2 is insecure, but the algorithm is still implemented and > supported. Verisign had a root cert that was self-signed by MD2. When Dan Kaminsky and I found that, Dan talked to Versign, and they reissued the cert signed with SHA-1. The original cert is still valid in older browsers, but there should no longer be any MD2 certs in use in the public CA system. (Who knows about private enterprise deployments, however.) I support deprecating MD2. We are one incremental improvement in MD2 attack speed away from a massive break. --Len. From len.sassaman@esat.kuleuven.be Thu Jun 10 07:12:05 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407AC3A6976; Thu, 10 Jun 2010 07:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLHzPGsm-DVf; Thu, 10 Jun 2010 07:12:04 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (cavuit02.kulnet.kuleuven.be [134.58.240.44]) by core3.amsl.com (Postfix) with ESMTP id 4083B3A6921; Thu, 10 Jun 2010 07:12:03 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 5E5F551C008; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id 5813BF3862; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 543C148002; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id 44170E5E46; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id 3CBEEE5BF4; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Date: Thu, 10 Jun 2010 16:12:02 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87sk4vhtpr.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:12:05 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > A self-signed trust root with MD2 is not a security problem by itself: > it is not the digital signature that is trusted, it is the public key in > the certificate. The MD2 roots are still shipped and trusted in several > modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). No, it absolutely *is* a security problem. Should someone develop a preimage attack on MD2, all they need do is move the (valid) MD2 signature to an intermediate cert with BasicConstraints CA=yes, and then they have themselves a CA. --Len. From len.sassaman@esat.kuleuven.be Thu Jun 10 09:59:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D0A3A69FD; Thu, 10 Jun 2010 09:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJXGjqkMzvdl; Thu, 10 Jun 2010 09:59:09 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (cavuit02.kulnet.kuleuven.be [134.58.240.44]) by core3.amsl.com (Postfix) with ESMTP id 885033A67D6; Thu, 10 Jun 2010 09:59:08 -0700 (PDT) Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id C0B9251C003; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps01.kuleuven.be (Postfix) with ESMTP id AF86A31E705; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id D10BC48002; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id C5D8CE5E46; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id C319AE5BF4; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Date: Thu, 10 Jun 2010 18:59:08 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87typbgeay.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> <87typbgeay.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 16:59:10 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > I don't see how that gains you anything: you still need to make clients > place trust in the new CA, and if the attacker has that ability, all > bets are off. The clients trust the new CA because it is an intermediate CA chained to the original, MD2-signed top-level CA. The intermediate cert is then treated with the same validity as *any* intermediate cert generated by that top-level cert -- since the top-level cert's signature verifies correctly on the intermediate cert, of course. Do you understand the attack now? This isn't *quite* such an issue, since after we brought it to the attention of CERT and the browser vendors, they either eliminated MD2 support entirely, or restricted it so that if an intermediate CA cert signed with MD2 would be rejected. (At least, I personally verifed Chrome and FireFox. I *think* IE and Opera were patched, too -- they should be.) So now we hope that browsers released prior to mid-2009 are retired from use before MD2 is broken in practice. Given the longevity of browsers, it's going to be close. --Len. From len.sassaman@esat.kuleuven.be Fri Jun 11 08:54:11 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18153A6970; Fri, 11 Jun 2010 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdeWlWrjK5lo; Fri, 11 Jun 2010 08:54:11 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (cavuit01.kulnet.kuleuven.be [134.58.240.43]) by core3.amsl.com (Postfix) with ESMTP id C70983A68A3; Fri, 11 Jun 2010 08:54:08 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 4FFE97B802A; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id 46071F3864; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 42B2548002; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id 36AE2E5DFD; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id 338E0E57EB; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Date: Fri, 11 Jun 2010 17:54:06 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Peter Gutmann In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: simon@josefsson.org, smime@ietf.org, cfrg@irtf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:54:12 -0000 On Fri, 11 Jun 2010, Peter Gutmann wrote: > I assume you're thinking of IE6 there :-). Was the fix done in CryptoAPI or > in the browser itself? If it was an update to CryptoAPI then even IE6 should > be OK (can anyone from MS comment on this?). I *think* the fix was in CryptoAPI. Dan was the one who notified the vendors (OpenSSL, Mozilla, Verisign, etc.) about the MD2 signature transfer problem as well as the other flaws, so he'd be the person to ask (unless someone from MS wants to chime in.) --Len. From tgindin@us.ibm.com Sun Jun 13 20:54:25 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E1A3A6823; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hrk23iGf25U; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id B11D23A67CC; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5E3bMnu003282; Sun, 13 Jun 2010 23:37:22 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5E3sFCv137692; Sun, 13 Jun 2010 23:54:15 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5E3sFH8019042; Mon, 14 Jun 2010 00:54:15 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5E3sFgm019037; Mon, 14 Jun 2010 00:54:15 -0300 In-Reply-To: <87eigfj92e.fsf@mocca.josefsson.org> References: <87bpbjko9d.fsf@mocca.josefsson.org> <87eigfj92e.fsf@mocca.josefsson.org> To: Simon Josefsson MIME-Version: 1.0 X-KeepSent: 37730A2F:44CD33D9-8525773E:0074B574; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Sun, 13 Jun 2010 23:54:13 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/13/2010 23:54:15, Serialize complete at 06/13/2010 23:54:15 Content-Type: text/plain; charset="US-ASCII" X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Cc: smime@ietf.org, cfrg@irtf.org, pkix-bounces@ietf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [saag] [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 03:54:25 -0000 Where in TLS (or even SSL v3) is MD2 used in a cipher suite? I realize that it's in the document list for TLS 1.0. In RFC's 2459 and 3279 (11 and 8 years old) it gives OID's and says "the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures". I also can't find any current MD2 intermediate certificates. You are right that the signature of a root certificate is not a relevant exercise of trust, since one trusts either the public key of the root certificate or the content of the entire root certificate with the signature no more relevant to a trust decision than any other field in it. Tom Gindin From: Simon Josefsson To: Peter Gutmann Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Date: 06/10/2010 10:19 AM Subject: Re: [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Sent by: pkix-bounces@ietf.org Peter Gutmann writes: > Simon Josefsson writes: > >>1) MD2 is not on the standards track, it is Informational. I agree with >> wishes to move "poor" documents from the Standards Track to Historic, >> but I'm not sure I see such a big difference between having a "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? > > It helps to have something like this formally retired so you have a document > to point to when someone wants to use (or continue to use) MD2. Trying to > explain to them the difference between "Informational" and "Standards Track" > when their requirement is "must be specified in an RFC" isn't generally > useful. Sure, but MD2 is not used in isolation, it is used in a protocol like TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses of MD2 in these protocol to Historic? That would seem to carry much more weight -- then people cannot continue to support MD2 in these protocol and claim to be compliant with the latest specifications. Note that there are other uses of MD2 that are still fine even if MD2 is not collision resistant. Compare how rsync still uses MD4 for checksum computations, and that won't stop it being a reasonable choice. I'm mostly playing the devil's advocate here, and want to make sure we consider the consequences before giving a flippant +1. /Simon _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hartmans@painless-security.com Wed Jun 16 13:31:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C50E28C190; Wed, 16 Jun 2010 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eohXenAb6O3H; Wed, 16 Jun 2010 13:31:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 87EC43A6986; Wed, 16 Jun 2010 13:30:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DA52E20394; Wed, 16 Jun 2010 16:30:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0EC940D4; Wed, 16 Jun 2010 16:30:25 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org, emu@ietf.org, kitten@ietf.org, moonshot-community@jiscmail.ac.uk, saag@ietf.org mail-copies-to: never mail-followups-to: moonshot-community@jiscmail.ac.uk Date: Wed, 16 Jun 2010 16:30:25 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 17 Jun 2010 08:01:57 -0700 Subject: [saag] Federated Authentication BOF at IETF 78 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 20:31:54 -0000 Hi. I'd like to announce that there will be a BOF on federated authentication beyond the web at IETF 78. we'd like to form a working group to standardize protocols for federated access to applications that are not browser based. Targets include think client applications and some machine-to-machine authentication use cases. At this point we have not focused on requirements imposed by RAI applications. You can see draft specs at http://www.project-moonshot.org/specifications There is a BOF agenda at http://www.project-moonshot.org/bof/agenda We encourage you to join our mailing list, see http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY . To the extent we're able we'd love to collect comments or things people will want to discuss at the BOF now. Hopefully we can get as much as possible out of the way on the list and have a very productive session! We hope to see you there. From sm@resistor.net Thu Jun 17 10:19:21 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6C13A6929; Thu, 17 Jun 2010 10:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLad7jyBeKYZ; Thu, 17 Jun 2010 10:19:20 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 061A03A6915; Thu, 17 Jun 2010 10:19:19 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o5HHIx1i027598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 10:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1276795161; x=1276881561; bh=Qa6GCb9YgNm3Txw2Mne7v7P+4vvGfkxAA3kLbwi9d0s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=USWSXUOK+jyuNtXbRW1Mkl+4vvUvYvNlKikLlt3WIS6MmsSBs1A3xazZOyyRCt4NH ugy4rk5NoxbbVV0mL2vGSwwWrwacGR3r32c4KacAcXfzc8PKTppdZ0YUyTKBPij0sE 09cDeE1jnSJjGzKG+G8ErkXayb7nkzIU8wxdD0d4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1276795161; x=1276881561; bh=Qa6GCb9YgNm3Txw2Mne7v7P+4vvGfkxAA3kLbwi9d0s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wvkLVgwWWz7RNAUzQiGMQtaIWufWTHatcfdIbk51WaQLBYQ+7fVIB9zUJSJnY05l3 jprXM71Hd+K/Oka6nk2gDHxvrQqI8e8+pWTI0UvACYCqVfkBFuuAK4alUNstNRknBX xlRpwZ+BtntrO9RKXISClXoBrJ/YFHHs3gNQIn28= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=LUkRcWlsMeNtQ5CDmet+pktGhjUl/aMl0Rx20x+ayvy5UYKV7yVUF/GlxWLmo3fhl cbLbxeyEBwbNahvD7jb9XxXpypvTaIXSgxT7pco6nEl5VQer5WI1RmxEG7IksaPlKjL speGrVCAYvulqKDDiMdLtWGtolB20URvdL1kQes= Message-Id: <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 17 Jun 2010 10:18:38 -0700 To: Simon Josefsson From: SM In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:19:21 -0000 Hi Simon, At 06:31 10-06-10, Simon Josefsson wrote: >1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? There's RFC 4223, for example, that reclassifies a non-Standards Track document to Historic. This is more about saying that MD2 should not be used and "Historic" is generally the way to say that. Regards, -sm From hotz@jpl.nasa.gov Thu Jun 17 10:36:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BED3A6914; Thu, 17 Jun 2010 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T5fptx+idPP; Thu, 17 Jun 2010 10:36:55 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 3ACC23A67A7; Thu, 17 Jun 2010 10:36:55 -0700 (PDT) Received: from dhcp-137-79-179-99.jpl.nasa.gov (dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o5HHatgZ011837; Thu, 17 Jun 2010 10:36:55 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5E6@IMCMBX2.MITRE.ORG> Date: Thu, 17 Jun 2010 10:36:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C81D2BE-84BC-4394-84A3-482A201997A2@jpl.nasa.gov> References: <4BF561C7.10500@anl.gov> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5E6@IMCMBX2.MITRE.ORG> To: "Miller, Timothy J." X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "ietf-krb-wg@lists.anl.gov" , "pkix@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [pkix] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:36:56 -0000 On May 21, 2010, at 6:41 AM, Miller, Timothy J. wrote: >> That certainty brings a lot of clarity. If this is documenting an >> existing protocol, then that should be clearly stated. Perhaps it is = and I just >> missed it? >=20 > Also, if it's only documenting only the existing protocol, shouldn't = it be on the info track instead? >=20 > -- Tim >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Thu Jun 17 10:43:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C923A6A39; Thu, 17 Jun 2010 10:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-AwX0wmyWhk; Thu, 17 Jun 2010 10:43:23 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 8CBF43A6AFC; Thu, 17 Jun 2010 10:43:22 -0700 (PDT) Received: from dhcp-137-79-179-99.jpl.nasa.gov (dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o5HHhMOK016282; Thu, 17 Jun 2010 10:43:23 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <6BD67117-29AA-4F7C-9BF1-A46223123675@jpl.nasa.gov> Date: Thu, 17 Jun 2010 10:43:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <716DAF64-7C36-4A50-8F42-EC9A4780B044@jpl.nasa.gov> References: <4BF561C7.10500@anl.gov> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5E6@IMCMBX2.MITRE.ORG> <6BD67117-29AA-4F7C-9BF1-A46223123675@jpl.nasa.gov> To: "Miller, Timothy J." X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: saag@ietf.org, pkix@ietf.org, ietf-krb-wg@lists.anl.gov Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:43:25 -0000 Gaak! Sorry about my premature send of a reply to what was obviously an = erroneous resend of an old message from Tim. I'm trying to find time to do a new draft. I'll be collating responses = to go into the next (informational) draft versus responses that should = go into a new, incompatible version of kx509. =20 I'll post the latter for discussion before I do a new, presumably = standards track, draft. On May 21, 2010, at 8:31 AM, Henry B. Hotz wrote: > If you look at my first post, I said I already had some private = feedback. Changing this draft to informational and creating a new = version with incompatible fixes was the biggest thing I got (which I've = already agreed with). >=20 > On May 21, 2010, at 6:41 AM, Miller, Timothy J. wrote: >=20 >>> That certainty brings a lot of clarity. If this is documenting an >>> existing protocol, then that should be clearly stated. Perhaps it is = and I just >>> missed it? >>=20 >> Also, if it's only documenting only the existing protocol, shouldn't = it be on the info track instead? >>=20 >> -- Tim >>=20 >> _______________________________________________ >> ietf-krb-wg mailing list >> ietf-krb-wg@lists.anl.gov >> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg >=20 > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >=20 >=20 >=20 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From turners@ieca.com Tue Jun 22 14:57:05 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62B028C0F8 for ; Tue, 22 Jun 2010 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUedWorylyFz for ; Tue, 22 Jun 2010 14:57:05 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id A7E043A67D3 for ; Tue, 22 Jun 2010 14:57:05 -0700 (PDT) Received: (qmail 59013 invoked from network); 22 Jun 2010 21:50:33 -0000 Received: from thunderfish.local (turners@71.191.10.89 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 22 Jun 2010 14:50:33 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: HzGfjKAVM1nM2k_c64KyqVJQYZIo2fY.wEiiJo74yRwG1Kw qzMbUmjyigB19XkC1Umy0j2e8F2TprIkIz7ygkzkbl2b3eIjfa.yH1jlFGvc OsO3k._xEjLgC.Jffr9MN7VH45zBCSroVkbGMucCt6W5xL5_uhXbhtpuEKt1 Nk2Aq_P645Hy2XD7DhmY8Q1XP8lhvhqHm3w6mHD2w0Ypx7KmU73j.oiTD0CV EnkyDepaoNcqBrneN0i0b3QuurhGxcagG_7LJh47Myspf05ARuKxgEvqk8yz VMvu3063yiqXjwsv2IMDuhhyriiUdfjQMDeyd04XqwPEJtl3Vwa9ODaCft6A 3TUBTl4wf1nXETGcb1Q2zdDQuHG2T2ILxwt1pFSw.IbzU8a0nxQHUs5Rz30o L5fvmzT4RvjkE87RgTGM0roM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C213028.4000404@ieca.com> Date: Tue, 22 Jun 2010 17:50:32 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <4C10F020.4000102@ieca.com> In-Reply-To: <4C10F020.4000102@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:57:06 -0000 Sean Turner wrote: >> 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as >> recently as (according to NEWS logs) in 2005. If I recall correctly, >> some Verisign root certificates are MD2. Note that in GnuTLS, >> verifying a certificate involving a MD2 digital signature will fail >> because MD2 is insecure, but the algorithm is still implemented and >> supported. >> >> Thus the text in your document "many TLS implementations, OpenSSL, >> Network Security Services, and GNUTLS, have disabled support for MD2" >> may not be the entire story. GnuTLS "supports" MD2 even though it >> does not consider it secure. I can't speak for OpenSSL or NSS, but I >> suspect they implement MD2 too and can verify such digital hashes, >> even if they don't consider them secure. > > Yeah that might have been a bit strong. Maybe: > > Additionally, many TLS implementations, OpenSSL, Network Security > Services, and GNUTLS, support MD2 but recommend it only for backwards > compatibility. I went back and looked at this a little closer. I found that GNUTLS now turns MD2 off by default: https://rhn.redhat.com/errata/RHSA-2010-0166.html I also found that NSS does also have MD2 turned off, but it looks you can turn it back on by setting an environment variable. spt From andrea.caccia@studiocaccia.com Thu Jun 17 10:56:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4798228C10E for ; Thu, 17 Jun 2010 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgG4lEfXpQZU for ; Thu, 17 Jun 2010 10:56:16 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out14.aruba.it [62.149.158.34]) by core3.amsl.com (Postfix) with SMTP id CEDEE3A6A87 for ; Thu, 17 Jun 2010 10:56:15 -0700 (PDT) Received: (qmail 28298 invoked by uid 89); 17 Jun 2010 17:56:11 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.128.201) by smtplq04.aruba.it with SMTP; 17 Jun 2010 17:56:11 -0000 Received: (qmail 9705 invoked by uid 89); 17 Jun 2010 17:56:10 -0000 Received: from unknown (HELO ?192.168.10.102?) (andrea.caccia@studiocaccia.com@151.38.135.157) by smtp5.ad.aruba.it with ESMTPA; 17 Jun 2010 17:56:10 -0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Andrea Caccia In-Reply-To: <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> Date: Thu, 17 Jun 2010 19:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED57229-EFEF-4F32-934A-8FA1E70A2947@studiocaccia.com> References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> To: SM X-Mailer: Apple Mail (2.1078) X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N X-Mailman-Approved-At: Fri, 25 Jun 2010 08:24:04 -0700 Cc: Simon Josefsson , smime@ietf.org, cfrg@irtf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [saag] [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:56:17 -0000 I think it's hard to say that an algorithm is not to be used at all for = any purpose. Can MD5 be moved to Historic? I do not think so even if it has since = some time to be avoided for digital signatures but is still useful for = other purposes. The solution should be a document, regularly updated and specific for = electronic signature that list the algorithms, their correct = identification (e.g. for asn.1 and xml) and their suitability for = typical usages. Regards, Andrea Caccia Il giorno 17/giu/2010, alle ore 19.18, SM ha scritto: > Hi Simon, > At 06:31 10-06-10, Simon Josefsson wrote: >> 1) MD2 is not on the standards track, it is Informational. I agree = with >> wishes to move "poor" documents from the Standards Track to = Historic, >> but I'm not sure I see such a big difference between having a = "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? >=20 > There's RFC 4223, for example, that reclassifies a non-Standards Track = document to Historic. This is more about saying that MD2 should not be = used and "Historic" is generally the way to say that. >=20 > Regards, > -sm=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From yaronf.ietf@gmail.com Fri Jun 25 14:12:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5363A6A31 for ; Fri, 25 Jun 2010 14:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqdVT+SZL0CL for ; Fri, 25 Jun 2010 14:12:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 752B33A69C5 for ; Fri, 25 Jun 2010 14:12:49 -0700 (PDT) Received: by wye20 with SMTP id 20so2655535wye.31 for ; Fri, 25 Jun 2010 14:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=CA0Q+2ECxaN2cdAXXCmVk88uNezpd5qAl70fAKRDuSI=; b=J2NK6/ADNkjHjcXPr1qY41P1mWJr0zHrPqCEVbr3zid7ZPxLJv9p63FpY8/kdh3Rck z9VNaC5JPCOxV+0Y6z2nbyx6nBJk25+d/xipwHjGS02pe9qFTUzMpHoLRai0u7x5/umI CtwqQzzkxIkd/gGnOpDsJiKcVzbzjri3J0qbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=WR5cy5Q46eJd5D8M/+c6pCjZDs+BJEFzZ9yjMiHlyIeTsKNw0ADKi37psXDKC2RuDr E4wkOHxkjBtidDBxmd+mlSpUA7MrpgPQvah5NkbP1XPTsgE7YTqXSjzbkG/2tNw3YVmG LlQHMeakSBvYIyz9cx2qMYAjxB0louxXXzU/M= Received: by 10.227.144.129 with SMTP id z1mr1105703wbu.3.1277500364850; Fri, 25 Jun 2010 14:12:44 -0700 (PDT) Received: from [10.0.0.1] ([109.67.47.233]) by mx.google.com with ESMTPS id b17sm80853221wbd.19.2010.06.25.14.12.39 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 14:12:43 -0700 (PDT) Message-ID: <4C251BBE.1060908@gmail.com> Date: Sat, 26 Jun 2010 00:12:30 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Comments on draft-turner-ssl-must-not-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 21:12:51 -0000 Hi, in general, I support this approach. It's a good idea to advise the industry to retire old security protocols. But looking at this draft somewhat cynically as a PR piece, we could do a better job to get the message across. - The draft does not mention a venue where it should be discussed. I just guessed at SAAG. - The draft should talk a bit about deployment considerations, not just security. During the RI episode, there were numbers mentioned (published?) about the prevalence of different protocol versions. This is certainly relevant to the current discussion, and readers would benefit from having these statistics included. - Speaking about which, I'm surprised the draft does not mention that support of RFC 5746 (RI) is mandatory. After all this one has a practical exploit, which I'm not sure is the case for other security issues mentioned here. - The reference to the original Netscape spec is kind of useless. Please also mention that it was published as an I-D, still available at http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00. - The document provides some motivation on why TLS 1.1 is a SHOULD. However it RECOMMENDS TLS 1.2 (which today is very rarely implemented, AFAIK) and does not provide any motivation for that. I would say the document as written only supports a statement like "use of TLS 1.1 or higher is RECOMMENDED." Thanks, Yaron From turners@ieca.com Tue Jun 29 10:22:23 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E24B3A6A69 for ; Tue, 29 Jun 2010 10:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdaM40cQer24 for ; Tue, 29 Jun 2010 10:22:20 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 465563A697F for ; Tue, 29 Jun 2010 10:22:18 -0700 (PDT) Received: (qmail 52958 invoked from network); 29 Jun 2010 17:22:26 -0000 Received: from thunderfish.local (turners@96.231.119.129 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 29 Jun 2010 10:22:26 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: na1zqpIVM1npdQTmitiqK7QeKgfZAc89ipPnkjkl_rzkhKJ tpP_QmJPAPXNid0r3kigaZnzcU_8r5JdS9b51MhLH8_irfFMvJk2CF2wju1z iwERb5WjNqRZ9fsneKCeFBKtoL8l5h7UTxRE2EpmVoFVEot3pMjLRKLX0N_8 iao20TLg3tE3WbZVpJHvxM6WvgmgstjMM3uQc55KEiOYQuuVhuYH.tu1LcA1 kYmd9aA99xfyyhpmeJppUnw8n.c37gPNWLrGLai_sDuilwv5JtciEybSDjo. Hy8rwR.XBJYH2t87XC41aiKO8PCMRTR4Grrg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C2A2BD0.2010505@ieca.com> Date: Tue, 29 Jun 2010 13:22:24 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yaron Sheffer References: <4C251BBE.1060908@gmail.com> In-Reply-To: <4C251BBE.1060908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Comments on draft-turner-ssl-must-not-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 17:22:23 -0000 Yaron Sheffer wrote: > Hi, > > > in general, I support this approach. It's a good idea to advise the > industry to retire old security protocols. But looking at this draft > somewhat cynically as a PR piece, we could do a better job to get the > message across. I meant to send this around to tls & saag, but got swamped doing IESG things. I'll get back to you on these. spt > - The draft does not mention a venue where it should be discussed. I > just guessed at SAAG. > > > - The draft should talk a bit about deployment considerations, not just > security. During the RI episode, there were numbers mentioned > (published?) about the prevalence of different protocol versions. This > is certainly relevant to the current discussion, and readers would > benefit from having these statistics included. > > > - Speaking about which, I'm surprised the draft does not mention that > support of RFC 5746 (RI) is mandatory. After all this one has a > practical exploit, which I'm not sure is the case for other security > issues mentioned here. > > > - The reference to the original Netscape spec is kind of useless. Please > also mention that it was published as an I-D, still available at > http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00. > > > > - The document provides some motivation on why TLS 1.1 is a SHOULD. > However it RECOMMENDS TLS 1.2 (which today is very rarely implemented, > AFAIK) and does not provide any motivation for that. I would say the > document as written only supports a statement like "use of TLS 1.1 or > higher is RECOMMENDED." > > > Thanks, > > Yaron > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >