From saag-bounces@ietf.org Mon Dec 1 05:07:47 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED2B28D96F; Mon, 1 Dec 2008 05:07:47 -0800 (PST) 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 4826128D319 for ; Mon, 1 Dec 2008 05:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 3SmVNrOXNbeN for ; Mon, 1 Dec 2008 05:06:32 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id CD7F228C73D for ; Mon, 1 Dec 2008 05:01:57 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB1D1XFe022018; Mon, 1 Dec 2008 15:01:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 15:01:36 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 15:01:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 15:01:33 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720268A2BB@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SAAG minutes for IETF73 Thread-Index: AclTtO/CRO+rpPvrTVqwHK3Lwcldqg== From: To: X-OriginalArrivalTime: 01 Dec 2008 13:01:36.0338 (UTC) FILETIME=[F13E4B20:01C953B4] X-Nokia-AV: Clean Subject: [saag] SAAG minutes for IETF73 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org The draft minutes for SAAG session are now available: http://www.ietf.org/proceedings/08nov/minutes/saag.txt Big thanks to David Cooper and Paul Hoffman for taking notes! Please send any corrections and/or additions to me and Tim. Best regards, Pasi _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 1 05:28:27 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9183A6CE2; Mon, 1 Dec 2008 05:28:27 -0800 (PST) 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 1DA2E3A6C80; Mon, 1 Dec 2008 05:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 b987IDPqY1Od; Mon, 1 Dec 2008 05:28:25 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 796CF28C57B; Mon, 1 Dec 2008 05:17:36 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB1DHIXM012984; Mon, 1 Dec 2008 07:17:31 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 15:16:13 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 15:16:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 15:16:12 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720268A2F4@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD Notes for November 2008 Thread-Index: AclTtvt7wAXKXavoQBadDbxjKscd6g== From: To: , X-OriginalArrivalTime: 01 Dec 2008 13:16:13.0659 (UTC) FILETIME=[FC2ADAB0:01C953B6] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for November 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi all, Here's again 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. Best regards, Pasi MISC NOTES - December will be a very busy month for IESG; we're having three telechats with probably ~50 documents. Expect some delay in email, too... - IANA fixed the registries for RFC 4909 (needed for draft-jerichow-msec-mikey-genext-oma, currently in IETF Last Call). - Lars Eggert and I met with CERT-FI to discuss the TCP DoS vulnerabilities found by Outpost24. - I've continued tools development, and my first code fragment was deployed on datatracker.ietf.org during the IETF meeting week. More coming soon... WORKING GROUPS DKIM - draft-ietf-dkim-ssp: in IETF Last Call (ends 2008-12-09), on agenda of 2008-12-18 IESG telechat. - draft-ietf-dkim-overview: in Publication Requested, waiting for me to read it. - Waiting for WG to send list of RFC errata IDs the WG agrees on. EMU - draft-ietf-emu-gpsk: waiting for IANA to confirm that they're happy with version -17. - (not WG item) draft-arkko-eap-aka-kdf: was approved, now in RFC Editor Queue. IPSECME - I and Tim responded to an appeal by Hui Deng and Peny Yang. - (not wearing AD hat) I need to check that my comments got entered into the issue tracker, and reply to Paul about some of them. - (not wearing AD hat) Waiting for Russ to verify errata #1502 for RFC 4718 [since 2008-09-12] ISMS - All the WG documents went through WG Last Call; hoping to see revised IDs soon. KEYPROV - I sent a bunch of comments about DSKPP to the list; I'm hoping the WG decides soon how to simplify the protocol. PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: in IETF Last Call (ends 2008-12-09), on agenda of 2008-12-18 IESG telechat. - draft-ietf-pkix-rfc4055-update: in Publication Requested, waiting for me to read it. SASL - Lots of emails that I need to read, but haven't done so yet... SYSLOG - draft-ietf-syslog-transport-tls: now in AUTH48 state - draft-ietf-syslog-sign: hoping to see a revised ID that would handle the easy comments from my AD evaluation TLS - draft-ietf-tls-des-idea: went through IETF Last Call, on agenda of 2009-01-08 IESG telechat. - draft-ietf-tls-ecdhe-psk: in Publication Requested, waiting for me to read it (in January) - draft-ietf-tls-psk-new-mac-aes-gcm: same as ecdhe-psk - (not WG item) draft-rescorla-tls-suiteb: was approved, now in RFC Editor Queue - Errata #1585: I filed an errata for TLS 1.2; waiting for Ekr to confirm that it's correct. OTHER DOCUMENTS - draft-ietf-pkix-cmp-transport-protocols: It seems some folks are interested in reviving this long-expired draft, so that current implementation behavior is documented somewhere. I've promised to read and comment if/when something is submitted. - draft-randall-3447bis: James Randall posted the -00 draft; I should read this and comment. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this once there's a new version. - "Security roadmap for routing protocols": Gregory has sent the first draft-of-a-draft; Tim and I have promised to comment and contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. - draft-mattsson-srtp-store-and-forward: I've promised to read this and send comments, but haven't done so yet. DISCUSSES (active -- something happened within last month) - draft-ietf-dime-mip6-integrated: discussion ongoing [at 2008-11-28] - draft-ietf-enum-combined: waiting for the authors to reply to my comments [since 2008-11-28] - draft-ietf-mipshop-mstp-solution: I talked with Jari and the authors in Minneapolis, and I think we have a rough agreement about the next steps; waiting for authors to propose concrete text [since 2008-11-17] - draft-ietf-shim6-proto: Erik has sent proposed text; I need to read it [since 2008-11-20] - draft-ietf-simple-imdn: rough agreement on changes, waiting for authors to submit a revised ID [since 2008-11-17] - draft-ietf-sip-dtls-srtp-framework: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-28] - draft-kato-camellia-ctrccm: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] - draft-kato-ipsec-camellia-modes: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: waiting for authors to reply to my comments or submit a revised ID [since 2008-08-28] - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] --end-- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 1 07:47:12 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C5B3A6AD0; Mon, 1 Dec 2008 07:47:12 -0800 (PST) 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 858753A6AAE for ; Mon, 1 Dec 2008 07:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 VKwQgpWLKAwn for ; Mon, 1 Dec 2008 07:47:10 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F3FB83A6AB6 for ; Mon, 1 Dec 2008 07:46:24 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mB1FkIbg019945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 10:46:18 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 1 Dec 2008 10:35:24 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mB1Fk2rt011292; Mon, 1 Dec 2008 10:46:10 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 10:45:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 10:45:56 -0500 Message-ID: <9FA859626025B64FBC2AF149D97C944A010749E3@CORPUSMX80A.corp.emc.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720268A2BB@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SAAG minutes for IETF73 Thread-Index: AclTtO/CRO+rpPvrTVqwHK3LwcldqgAFRd5Q References: <1696498986EFEC4D9153717DA325CB720268A2BB@vaebe104.NOE.Nokia.com> To: , X-OriginalArrivalTime: 01 Dec 2008 15:45:56.0997 (UTC) FILETIME=[E6A77350:01C953CB] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow Subject: Re: [saag] SAAG minutes for IETF73 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org > * David Black and Lakshminath Dondeti had questions about how many > current protocols that might be helped by an insecure hash function. At least my question was more about degrees of insecurity, specifically I agree with Ekr that pre-image resistance may not be needed in many cases, but I am concerned that collision resistance may still be important. > * Vidya Narayanan asked whether Eric's requirements for speed was really > appropriate. David Black responded that people that do care about > speed just use GCM in a lot of applications. The longer version of my comment is that the strong interest in GCM in storage space is evidence that hardware speed & efficiency do matter to at least one community (GCM's hash is much more efficient and easier to implement in hardware than any of the SHA hashes). In addition, the GHASH construct in GCM might be a starting point for the sort of insecure hash that Ekr was discussing. Thanks, --David > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Monday, December 01, 2008 8:02 AM > To: saag@ietf.org > Subject: [saag] SAAG minutes for IETF73 > > > The draft minutes for SAAG session are now available: > http://www.ietf.org/proceedings/08nov/minutes/saag.txt > > Big thanks to David Cooper and Paul Hoffman for taking notes! > > Please send any corrections and/or additions to me and Tim. > > Best regards, > Pasi > _______________________________________________ > 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 saag-bounces@ietf.org Fri Dec 5 00:13:12 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66D53A6C2E; Fri, 5 Dec 2008 00:13:12 -0800 (PST) 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 9BE753A6C2E for ; Fri, 5 Dec 2008 00:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 UMPwKYEd2gxs for ; Fri, 5 Dec 2008 00:13:10 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7CA133A6C29 for ; Fri, 5 Dec 2008 00:13:10 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB58CewJ023880; Fri, 5 Dec 2008 10:13:00 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Dec 2008 10:12:43 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Dec 2008 10:12:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Dec 2008 10:12:40 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72027AC295@vaebe104.NOE.Nokia.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A010749E3@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SAAG minutes for IETF73 Thread-Index: AclTtO/CRO+rpPvrTVqwHK3LwcldqgAFRd5QALmpHuA= References: <1696498986EFEC4D9153717DA325CB720268A2BB@vaebe104.NOE.Nokia.com> <9FA859626025B64FBC2AF149D97C944A010749E3@CORPUSMX80A.corp.emc.com> From: To: , X-OriginalArrivalTime: 05 Dec 2008 08:12:43.0567 (UTC) FILETIME=[3FC253F0:01C956B1] X-Nokia-AV: Clean Subject: Re: [saag] SAAG minutes for IETF73 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi David, Thanks for the corrections! I've updated the minutes as noted below: > > * David Black and Lakshminath Dondeti had questions about how many > > current protocols that might be helped by an insecure > > hash function. > > At least my question was more about degrees of insecurity, > specifically I agree with Ekr that pre-image resistance may not be > needed in many cases, but I am concerned that collision resistance > may still be important. I rephrased this as follows: * David Black and Lakshminath Dondeti had questions about how many current protocols that might be helped by an insecure hash function. David was concerned that even if pre-image resistance is not needed, collision resistance may still be important. > > * Vidya Narayanan asked whether Eric's requirements for speed was > > really appropriate. David Black responded that people that do > > care about speed just use GCM in a lot of applications. > > The longer version of my comment is that the strong interest in GCM > in storage space is evidence that hardware speed & efficiency do > matter to at least one community (GCM's hash is much more efficient > and easier to implement in hardware than any of the SHA hashes). > > In addition, the GHASH construct in GCM might be a starting point > for the sort of insecure hash that Ekr was discussing. Rephrased as follows: * Vidya Narayanan asked whether Eric's requirements for speed was really appropriate. David Black responded that strong interest in GCM in storage space is evidence that hardware speed and efficiency do matter to at least one community. Best regards, Pasi _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 14:38:58 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069893A6ABD; Mon, 8 Dec 2008 14:38:58 -0800 (PST) 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 615E43A6ABB for ; Mon, 8 Dec 2008 14:38:57 -0800 (PST) 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 FH7VYHUVB7sV for ; Mon, 8 Dec 2008 14:38:56 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id A18323A6A9C for ; Mon, 8 Dec 2008 14:38:56 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 9276EAF677; Mon, 8 Dec 2008 22:38:50 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2C9D1AF63F for ; Mon, 8 Dec 2008 22:38:50 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 18CBE8386BF for ; Mon, 8 Dec 2008 17:38:40 -0500 (EST) Date: Mon, 8 Dec 2008 17:38:39 -0500 From: "Steven M. Bellovin" To: saag@ietf.org Message-ID: <20081208173839.0e26afe4@cs.columbia.edu> Organization: Columbia University X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) Mime-Version: 1.0 Subject: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_malware_evil-.html?nav=rss_blog But how, in a public setting? How can "Steve" (to use the name from the article) *realistically* tell his laptop the proper public key to expect? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 14:41:39 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569613A6A7B; Mon, 8 Dec 2008 14:41:39 -0800 (PST) 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 500793A6A19 for ; Mon, 8 Dec 2008 14:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 X1EbHG9Ec1oi for ; Mon, 8 Dec 2008 14:41:37 -0800 (PST) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 9E3EA3A6A7B for ; Mon, 8 Dec 2008 14:41:37 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KBK00IRHXOX1SG1@vms173003.mailsrvcs.net> for saag@ietf.org; Mon, 08 Dec 2008 16:41:22 -0600 (CST) Date: Mon, 08 Dec 2008 17:41:21 -0500 From: RJ Atkinson In-reply-to: <20081208173839.0e26afe4@cs.columbia.edu> To: Steven M. Bellovin Message-id: <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v929.2) X-Mailer: Apple Mail (2.929.2) References: <20081208173839.0e26afe4@cs.columbia.edu> Cc: "saag@ietf.org" Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 8 Dec 2008, at 17:38, Steven M. Bellovin wrote: > http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_malware_evil-.html?nav=rss_blog > > But how, in a public setting? How can "Steve" (to use the name from > the article) *realistically* tell his laptop the proper public key to > expect? After reading the article, it seems like the only real fix to the problem described is to accelerate widespread deployment of DNSsec... Yours, Ran _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 14:58:21 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21263A6928; Mon, 8 Dec 2008 14:58:20 -0800 (PST) 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 967DB3A6928 for ; Mon, 8 Dec 2008 14:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Oedc-Rsn+MmY for ; Mon, 8 Dec 2008 14:58:18 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id B95CA3A68DE for ; Mon, 8 Dec 2008 14:58:18 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mB8Mw03B031628; Mon, 8 Dec 2008 14:58:02 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 14:58:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 14:55:02 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC0B@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] time to authenticate dhcp? Thread-Index: AclZhiIM1Ib3aTbaRwOxLhfJ8JsKSQAAd9DZ References: <20081208173839.0e26afe4@cs.columbia.edu> <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> From: "Hallam-Baker, Phillip" To: "RJ Atkinson" , "Steven M. Bellovin" X-OriginalArrivalTime: 08 Dec 2008 22:58:00.0017 (UTC) FILETIME=[6ADEA410:01C95988] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============1847167818==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org This is a multi-part message in MIME format. --===============1847167818== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95988.6A5BAE9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95988.6A5BAE9A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is not necessarily enough. The critical weakness here is the braindamaged idea that you take DNS = from the local network that offers it. I am happy to collect IP packets = from Panera, but why would I rely on them for my DNS server to resolve = cnn.com? -----Original Message----- From: saag-bounces@ietf.org on behalf of RJ Atkinson Sent: Mon 12/8/2008 5:41 PM To: Steven M. Bellovin Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? =20 On 8 Dec 2008, at 17:38, Steven M. Bellovin wrote: > = http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_mal= ware_evil-.html?nav=3Drss_blog > > But how, in a public setting? How can "Steve" (to use the name from > the article) *realistically* tell his laptop the proper public key to > expect? After reading the article, it seems like the only real fix to the problem described is to accelerate widespread deployment of DNSsec... Yours, Ran _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C95988.6A5BAE9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] time to authenticate dhcp?

That is not necessarily enough.

The critical weakness here is the braindamaged idea that you take DNS = from the local network that offers it. I am happy to collect IP packets = from Panera, but why would I rely on them for my DNS server to resolve = cnn.com?




-----Original Message-----
From: saag-bounces@ietf.org on behalf of RJ Atkinson
Sent: Mon 12/8/2008 5:41 PM
To: Steven M. Bellovin
Cc: saag@ietf.org
Subject: Re: [saag] time to authenticate dhcp?


On  8 Dec 2008, at 17:38, Steven M. Bellovin wrote:

> http://voices.washingtonpost.com/= securityfix/2008/12/a_scary_twist_in_malware_evil-.html?nav=3Drss_blog
>
> But how, in a public setting?  How can "Steve" (to = use the name from
> the article) *realistically* tell his laptop the proper public key = to
> expect?

After reading the article, it seems like the only real fix to the
problem described is to accelerate widespread deployment of = DNSsec...

Yours,

Ran


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C95988.6A5BAE9A-- --===============1847167818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1847167818==-- From saag-bounces@ietf.org Mon Dec 8 15:00:04 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482BA28C0FD; Mon, 8 Dec 2008 15:00:04 -0800 (PST) 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 45C233A6AC2 for ; Mon, 8 Dec 2008 15:00:02 -0800 (PST) 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 Hm-FmlHyO0-o for ; Mon, 8 Dec 2008 15:00:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 759C43A6ABC for ; Mon, 8 Dec 2008 15:00:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,737,1220227200"; d="scan'208";a="121670720" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2008 22:59:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mB8MxpCu000601; Mon, 8 Dec 2008 14:59:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mB8MxpuA021973; Mon, 8 Dec 2008 22:59:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 14:59:51 -0800 Received: from [10.0.1.200] ([10.21.150.86]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 14:59:51 -0800 Message-Id: From: Mark Baugher To: RJ Atkinson In-Reply-To: <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 14:59:50 -0800 References: <20081208173839.0e26afe4@cs.columbia.edu> <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Dec 2008 22:59:51.0268 (UTC) FILETIME=[AD2E3240:01C95988] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=784; t=1228777191; x=1229641191; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[saag]=20time=20to=20authenticate=20dhc p? |Sender:=20; bh=NriRPW2trNbc2mmXXX55juuFYhPLWui5vb5fhSQZF4s=; b=Yiesk79CbCmcOf+CdRZyY+0bwgyJ/IrpKpSW7j8+eUMwbA70kKoEBzSUAe /TgnAt1ulCihGAF+d7uQfnS4R7cslvjNEeGH85+0+DDIi6TzBgfEGcjn2nP0 AZwu8bc1ix; Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "saag@ietf.org" Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org The near-term solution is to VPN to a network you trust for names and addresses. Mark On Dec 8, 2008, at 2:41 PM, RJ Atkinson wrote: > > On 8 Dec 2008, at 17:38, Steven M. Bellovin wrote: > >> http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_malware_evil-.html?nav=rss_blog >> >> But how, in a public setting? How can "Steve" (to use the name from >> the article) *realistically* tell his laptop the proper public key to >> expect? > > After reading the article, it seems like the only real fix to the > problem described is to accelerate widespread deployment of DNSsec... > > Yours, > > Ran > > > _______________________________________________ > 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 saag-bounces@ietf.org Mon Dec 8 15:05:38 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52FA28C11E; Mon, 8 Dec 2008 15:05:38 -0800 (PST) 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 5AEA83A6AED for ; Mon, 8 Dec 2008 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 OdEW20ejf+Ys for ; Mon, 8 Dec 2008 15:05:36 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 7EB193A6AD6 for ; Mon, 8 Dec 2008 15:05:36 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mB8N5MSf002810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 18:05:23 -0500 (EST) Date: Mon, 08 Dec 2008 18:05:22 -0500 From: Jeffrey Hutzelman To: "Steven M. Bellovin" , saag@ietf.org Message-ID: <21A85CF3345D934FF2787B76@minbar.fac.cs.cmu.edu> In-Reply-To: <200812082238.mB8MctJa001920@raisinbran.srv.cs.cmu.edu> References: <200812082238.mB8MctJa001920@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Monday, December 08, 2008 05:38:39 PM -0500 "Steven M. Bellovin" wrote: > http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_mal > ware_evil-.html?nav=rss_blog > > But how, in a public setting? How can "Steve" (to use the name from > the article) *realistically* tell his laptop the proper public key to > expect? He can't, of course. What he can do is use DNSSEC, or use TLS and actually validate server certificates, or use some other strong, DNS-independent authentication mechanism, or some combination of the three. Then it doesn't matter whose nameservers he's talking to, which protects him not only from Jill's infected machine but also from the evil coffee shop operator(*). The network operator can also take steps to limit the effectiveness of rogue DHCP servers, including filtering DHCP responses and/or simply removing offenders from the network. This is not too hard to do, and has already become essential when operating an open-access network. -- Jeff (*) I can't think of a greater evil than pushing coffee. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 15:08:23 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F1128C127; Mon, 8 Dec 2008 15:08:22 -0800 (PST) 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 172EF28C127 for ; Mon, 8 Dec 2008 15:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.889, 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 BFAxsFbU5WA2 for ; Mon, 8 Dec 2008 15:08:21 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4AF1E28C123 for ; Mon, 8 Dec 2008 15:08:21 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mB8N87iw002842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 18:08:07 -0500 (EST) Date: Mon, 08 Dec 2008 18:08:07 -0500 From: Jeffrey Hutzelman To: "Hallam-Baker, Phillip" , RJ Atkinson , "Steven M. Bellovin" Message-ID: <938C80EB8EF61006661ACABF@minbar.fac.cs.cmu.edu> In-Reply-To: <200812082258.mB8MwIdU007479@grapenut.srv.cs.cmu.edu> References: <20081208173839.0e26afe4@cs.columbia.edu> <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> <200812082258.mB8MwIdU007479@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Monday, December 08, 2008 02:55:02 PM -0800 "Hallam-Baker, Phillip" wrote: > That is not necessarily enough. > > The critical weakness here is the braindamaged idea that you take DNS > from the local network that offers it. I am happy to collect IP packets > from Panera, but why would I rely on them for my DNS server to resolve > cnn.com? Because they're in the best position to provide caching, and you shouldn't be in a position where your security depends on getting the correct answer to questions about cnn.com (even if you work for cnn.com). But yes, another solution is to use TSIG and send all of your DNS traffic to a server you trust. Of course, that works for you and me, but not for joe random internet user, who doesn't have any routable addresses at his disposal. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 15:29:29 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED7628C130; Mon, 8 Dec 2008 15:29:29 -0800 (PST) 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 7D96B28C111 for ; Mon, 8 Dec 2008 15:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 WKBDeXP4lUTi for ; Mon, 8 Dec 2008 15:29:27 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BF77C3A6AF1 for ; Mon, 8 Dec 2008 15:29:27 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7C8C039A214; Mon, 8 Dec 2008 15:29:21 -0800 (PST) From: Wes Hardaker To: "Steven M. Bellovin" Organization: Sparta References: <20081208173839.0e26afe4@cs.columbia.edu> Date: Mon, 08 Dec 2008 15:29:21 -0800 In-Reply-To: <20081208173839.0e26afe4@cs.columbia.edu> (Steven M. Bellovin's message of "Mon, 8 Dec 2008 17:38:39 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >>>>> On Mon, 8 Dec 2008 17:38:39 -0500, "Steven M. Bellovin" said: SMB> But how, in a public setting? How can "Steve" (to use the name SMB> from the article) *realistically* tell his laptop the proper public SMB> key to expect? As everyone on this list knows, you always have to have pre-existing knowledge in order to trust something. This could come from a number of forms: 1) leap-of-faith (ssh style: trust the offerer the first time, hopefully when no one else is in the coffee shop or by verifying it based on their public web page before you leave the house) (Then blindly accept it again when it changes because you know everyone will) 2) DNSSEC A number of us have been arguing for DNSSEC resolution directly on the client. Without doing resolution on the client you've gained nothing. There are a lot of people that don't want the maintenance headache though so you're back to square one if you're expecting a validating resolver in the coffee shop to take care of you. 3) Routing infrastructure I'm not a routing expert which means I'm just dangerous. I believe there is work in progress in the routing area to sign IP address ownership with public certificates. This obviously doesn't work when the local coffee shop is using a 10/8 address or similar pool though. So they'll need to switch to IPv6. This doesn't stop, however, the evil coffee company from coming into the good coffee companies free space and advertise routes through them. Unfortunately, X.509 cert doesn't have the evil bit that verifies you'll do no harm with the certificate. Thus, we only need to pick one of: - educate users to do leap of faith or pre-authentication properly - deploy DNSSEC in all devices with properly maintained trustanchors - Develop trustable routing ownership down to the end user over widely-deployed IPv6 Easy! -- Wes Hardaker Sparta, Inc. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 15:55:44 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D2F3A6A73; Mon, 8 Dec 2008 15:55:44 -0800 (PST) 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 AE50E3A6A73 for ; Mon, 8 Dec 2008 15:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UK8XASLFYjoF for ; Mon, 8 Dec 2008 15:55:42 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 00AD13A686D for ; Mon, 8 Dec 2008 15:55:41 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB8NYK7Q021472; Mon, 8 Dec 2008 15:34:20 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 15:55:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 15:54:35 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC0E@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] time to authenticate dhcp? Thread-Index: AclZidsxPQPvQGCzT+iCUTUpyXOjsQABnd1a References: <20081208173839.0e26afe4@cs.columbia.edu> <7C015416-C25F-4F0C-879F-0B4AEC2C1111@extremenetworks.com> <200812082258.mB8MwIdU007479@grapenut.srv.cs.cmu.edu> <938C80EB8EF61006661ACABF@minbar.fac.cs.cmu.edu> From: "Hallam-Baker, Phillip" To: "Jeffrey Hutzelman" , "RJ Atkinson" , "Steven M. Bellovin" X-OriginalArrivalTime: 08 Dec 2008 23:55:25.0724 (UTC) FILETIME=[70ABCDC0:01C95990] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============1339726508==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org This is a multi-part message in MIME format. --===============1339726508== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95990.70330EA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95990.70330EA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It should all just be part of an Internet service. -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Mon 12/8/2008 6:08 PM To: Hallam-Baker, Phillip; RJ Atkinson; Steven M. Bellovin Cc: saag@ietf.org; jhutz@cmu.edu Subject: Re: [saag] time to authenticate dhcp? =20 --On Monday, December 08, 2008 02:55:02 PM -0800 "Hallam-Baker, Phillip" = wrote: > That is not necessarily enough. > > The critical weakness here is the braindamaged idea that you take DNS > from the local network that offers it. I am happy to collect IP = packets > from Panera, but why would I rely on them for my DNS server to resolve > cnn.com? Because they're in the best position to provide caching, and you = shouldn't=20 be in a position where your security depends on getting the correct = answer=20 to questions about cnn.com (even if you work for cnn.com). But yes, another solution is to use TSIG and send all of your DNS = traffic=20 to a server you trust. Of course, that works for you and me, but not = for=20 joe random internet user, who doesn't have any routable addresses at his = disposal. ------_=_NextPart_001_01C95990.70330EA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] time to authenticate dhcp?

It should all just be part of an Internet service.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]
Sent: Mon 12/8/2008 6:08 PM
To: Hallam-Baker, Phillip; RJ Atkinson; Steven M. Bellovin
Cc: saag@ietf.org; jhutz@cmu.edu
Subject: Re: [saag] time to authenticate dhcp?

--On Monday, December 08, 2008 02:55:02 PM -0800 "Hallam-Baker, = Phillip"
<pbaker@verisign.com> wrote:

> That is not necessarily enough.
>
> The critical weakness here is the braindamaged idea that you take = DNS
> from the local network that offers it. I am happy to collect IP = packets
> from Panera, but why would I rely on them for my DNS server to = resolve
> cnn.com?

Because they're in the best position to provide caching, and you = shouldn't
be in a position where your security depends on getting the correct = answer
to questions about cnn.com (even if you work for cnn.com).

But yes, another solution is to use TSIG and send all of your DNS = traffic
to a server you trust.  Of course, that works for you and me, but = not for
joe random internet user, who doesn't have any routable addresses at = his
disposal.

------_=_NextPart_001_01C95990.70330EA2-- --===============1339726508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1339726508==-- From saag-bounces@ietf.org Mon Dec 8 18:00:47 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7BD3A6916; Mon, 8 Dec 2008 18:00:47 -0800 (PST) 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 BCECC3A6AD6 for ; Mon, 8 Dec 2008 18:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] 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 dJmTvCk62caC for ; Mon, 8 Dec 2008 18:00:44 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [192.139.46.41]) by core3.amsl.com (Postfix) with ESMTP id 8B1E83A6A83 for ; Mon, 8 Dec 2008 18:00:43 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTP id 3AB475C08C; Mon, 8 Dec 2008 19:35:49 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 185E14E7D7; Mon, 8 Dec 2008 20:27:41 -0500 (EST) From: Michael Richardson To: "Steven M. Bellovin" In-Reply-To: <20081208173839.0e26afe4@cs.columbia.edu> References: <20081208173839.0e26afe4@cs.columbia.edu> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Mon, 08 Dec 2008 20:27:41 -0500 Message-ID: <7460.1228786061@marajade.sandelman.ca> Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Steven" == Steven M Bellovin writes: Steven> But how, in a public setting? How can "Steve" (to use the Steven> name from the article) *realistically* tell his laptop the Steven> proper public key to expect? He can't until he is online to look it up. Naming it is easy. Once online, he can confirm it. What key? Why a DHCPKEY(tbd) or perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP. See www.wavesec.org. Also see http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth-sig0-00.txt which never got enough enthusiam to bother going forward (nor enough cycles from the freeswan team) Note that given a trusted anchor for in-addr.arpa (whether signed ., or DLV for in-addr.arpa, or whatever), you can confirm key. If your local DNS cache is not empty, you may already be able to authenticate it. If the machine doing a MITM on your DHCP server is doing such a good job of emulating the rest of the Internet that things check out, then I would suggest that you really are on the Internet :-) Note that of course, this completely fails when your DHCP server is 192.168.1.1. Is there some way to use the outer IP of the router in the cafe? But, if you postulate IPv6, you might as well postulate SEND as well. As far as I can tell, this "DNSChanger", "DHCPChanger" attack is completely untouched by using 802.1x/WPA/WPA2 "security", because the layer3 is not bound (as in channel bound) to the layer2 security. - -- ] Y avait une poule jammer dans le muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8 ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ== =fPHj -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Dec 8 18:13:06 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA50928C132; Mon, 8 Dec 2008 18:13:06 -0800 (PST) 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 6F25028C132 for ; Mon, 8 Dec 2008 18:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NLlAtEM14M9O for ; Mon, 8 Dec 2008 18:13:05 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 3E85528C123 for ; Mon, 8 Dec 2008 18:13:05 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB91pkR4025669; Mon, 8 Dec 2008 17:51:46 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 18:12:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 18:12:50 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC10@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] time to authenticate dhcp? Thread-Index: AclZofnPVS780rBrSQOiC+PscyMkpgAAOPVw References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> From: "Hallam-Baker, Phillip" To: "Michael Richardson" , "Steven M. Bellovin" X-OriginalArrivalTime: 09 Dec 2008 02:12:51.0179 (UTC) FILETIME=[A35863B0:01C959A3] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============0022332407==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org This is a multi-part message in MIME format. --===============0022332407== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C959A3.A2E84306" This is a multi-part message in MIME format. ------_=_NextPart_001_01C959A3.A2E84306 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that this particular conversation has gone from problem to = solution to quickly. Or rather we skipped straight from an attack to a = patch to defeat that one attack. I think Steve was right to ask the question whether we should think = about DHCP security. But we should do that by thinking about the = security properties we rely on from DHCP and might want to rely on in = future. In particular I think that we could do to think in terms of a secure = handshake for a client connecting to a WiFi node. Should we be putting = the security in the DHCP layer or somewhere else? Should a DHCP = handshake in Panera be equivalent to a DCHP handshake on a home network? What assets are involved here? What are the intrinsic risks that affect = those assets? Lets start thinking about the security of the systems that = a user is engaged in, not just ad hoc patches to fix one attack. -----Original Message----- From: saag-bounces@ietf.org on behalf of Michael Richardson Sent: Mon 12/8/2008 8:27 PM To: Steven M. Bellovin Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Steven" =3D=3D Steven M Bellovin writes: Steven> But how, in a public setting? How can "Steve" (to use the Steven> name from the article) *realistically* tell his laptop the Steven> proper public key to expect? He can't until he is online to look it up. Naming it is easy. Once online, he can confirm it. What key? Why a DHCPKEY(tbd) or perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP.=20 See www.wavesec.org. =20 Also see = http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth-sig0-00.tx= t which never got enough enthusiam to bother going forward (nor enough cycles from the freeswan team) Note that given a trusted anchor for in-addr.arpa (whether signed ., or DLV for in-addr.arpa, or whatever), you can confirm key. If your local DNS cache is not empty, you may already be able to authenticate it. If the machine doing a MITM on your DHCP server is doing such a good job of emulating the rest of the Internet that things check out, then I would suggest that you really are on the Internet :-) Note that of course, this completely fails when your DHCP server is 192.168.1.1. Is there some way to use the outer IP of the router in the cafe? =20 But, if you postulate IPv6, you might as well postulate SEND as well. As far as I can tell, this "DNSChanger", "DHCPChanger" attack is completely untouched by using 802.1x/WPA/WPA2 "security", because the layer3 is not bound (as in channel bound) to the layer2 security. - --=20 ] Y avait une poule jammer dans le muffler!!!!!!!!! | = firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device = driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security = guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8 ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ=3D=3D =3DfPHj -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C959A3.A2E84306 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] time to authenticate dhcp?

I think that this particular conversation has gone = from problem to solution to quickly. Or rather we skipped straight from = an attack to a patch to defeat that one attack.

I think Steve was right to ask the question whether we should think = about DHCP security. But we should do that by thinking about the = security properties we rely on from DHCP and might want to rely on in = future.

In particular I think that we could do to think in terms of a secure = handshake for a client connecting to a WiFi node. Should we be putting = the security in the DHCP layer or somewhere else? Should a DHCP = handshake in Panera be equivalent to a DCHP handshake on a home = network?


What assets are involved here? What are the intrinsic risks that affect = those assets? Lets start thinking about the security of the systems that = a user is engaged in, not just ad hoc patches to fix one attack.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Michael Richardson
Sent: Mon 12/8/2008 8:27 PM
To: Steven M. Bellovin
Cc: saag@ietf.org
Subject: Re: [saag] time to authenticate dhcp?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Steven" =3D=3D Steven M Bellovin = <smb@cs.columbia.edu> writes:
    Steven> But how, in a public setting?  How = can "Steve" (to use the
    Steven> name from the article) *realistically* = tell his laptop the
    Steven> proper public key to expect?

  He can't until he is online to look it up.  Naming it is = easy.

  Once online, he can confirm it.  What key?  Why a = DHCPKEY(tbd) or
perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP.
  See www.wavesec.org.
 
  Also see
     http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth= -sig0-00.txt

  which never got enough enthusiam to bother going forward (nor = enough
cycles from the freeswan team)

  Note that given a trusted anchor for in-addr.arpa (whether signed = .,
or DLV for in-addr.arpa, or whatever), you can confirm key.  If = your
local DNS cache is not empty, you may already be able to = authenticate
it.
  If the machine doing a MITM on your DHCP server is doing such a = good
job of emulating the rest of the Internet that things check out, then = I
would suggest that you really are on the Internet :-)

  Note that of course, this completely fails when your DHCP server = is
192.168.1.1.   Is there some way to use the outer IP of the = router in
the cafe? 

  But, if you postulate IPv6, you might as well postulate SEND as = well.

  As far as I can tell, this "DNSChanger", = "DHCPChanger" attack is
completely untouched by using 802.1x/WPA/WPA2 "security", = because the
layer3 is not bound (as in channel bound) to the layer2 security.

- --
]      Y avait une poule jammer dans le = muffler!!!!!!!!!        |  = firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, = ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.o= n.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, = security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ
ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK
UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp
ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8
ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i
kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ=3D=3D
=3DfPHj
-----END PGP SIGNATURE-----
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C959A3.A2E84306-- --===============0022332407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0022332407==-- From saag-bounces@ietf.org Tue Dec 9 06:58:38 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74383A6B24; Tue, 9 Dec 2008 06:58:38 -0800 (PST) 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 53AAF28C159 for ; Tue, 9 Dec 2008 06:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2QRKu1vbisL9 for ; Tue, 9 Dec 2008 06:58:29 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6B7973A6821 for ; Tue, 9 Dec 2008 06:58:29 -0800 (PST) Received: from Puki.ogud.com (puki-w.md.ogud.com [10.20.30.42]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mB9EwQvp092191 for ; Tue, 9 Dec 2008 09:58:26 -0500 (EST) (envelope-from ogud+saag@ogud.com) Message-Id: <200812091458.mB9EwQvp092191@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 09:54:39 -0500 To: saag@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============1150477887==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1150477887== Content-Type: multipart/alternative; boundary="=====================_158536233==.ALT" --=====================_158536233==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:32 09/12/2008, Hallam-Baker, Phillip wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C959A3.A2E84306" > >I think that this particular conversation has gone from problem to >solution to quickly. Or rather we skipped straight from an attack to >a patch to defeat that one attack. > >I think Steve was right to ask the question whether we should think >about DHCP security. But we should do that by thinking about the >security properties we rely on from DHCP and might want to rely on in future. Background: To some of us this is not a new problem but something that has surfaced a few times in the past 10+ years. Some of us have been arguing DHCP needs security, see: (shameless plugs) http://tools.ietf.org/html/draft-ietf-dhc-security-requirements-00 http://tools.ietf.org/html/draft-ietf-dhc-security-arch-01 The DHC working group decided that public key solutions were to "heavy" and elected to go with shared secret authentication model. The idea was that Public Key authentication could be added on later, the question is that time now? Olafur >In particular I think that we could do to think in terms of a secure >handshake for a client connecting to a WiFi node. Should we be >putting the security in the DHCP layer or somewhere else? Should a >DHCP handshake in Panera be equivalent to a DCHP handshake on a home network? > > >What assets are involved here? What are the intrinsic risks that >affect those assets? Lets start thinking about the security of the >systems that a user is engaged in, not just ad hoc patches to fix one attack. > > >-----Original Message----- >From: saag-bounces@ietf.org on behalf of Michael Richardson >Sent: Mon 12/8/2008 8:27 PM >To: Steven M. Bellovin >Cc: saag@ietf.org >Subject: Re: [saag] time to authenticate dhcp? > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >>>>> "Steven" == Steven M Bellovin writes: > Steven> But how, in a public setting? How can "Steve" (to use the > Steven> name from the article) *realistically* tell his laptop the > Steven> proper public key to expect? > > He can't until he is online to look it up. Naming it is easy. > > Once online, he can confirm it. What key? Why a DHCPKEY(tbd) or >perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP. > See www.wavesec.org. > > Also see > >http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth-sig0-00.txt > > which never got enough enthusiam to bother going forward (nor enough >cycles from the freeswan team) > > Note that given a trusted anchor for in-addr.arpa (whether signed ., >or DLV for in-addr.arpa, or whatever), you can confirm key. If your >local DNS cache is not empty, you may already be able to authenticate >it. > If the machine doing a MITM on your DHCP server is doing such a good >job of emulating the rest of the Internet that things check out, then I >would suggest that you really are on the Internet :-) > > Note that of course, this completely fails when your DHCP server is >192.168.1.1. Is there some way to use the outer IP of the router in >the cafe? > > But, if you postulate IPv6, you might as well postulate SEND as well. > > As far as I can tell, this "DNSChanger", "DHCPChanger" attack is >completely untouched by using 802.1x/WPA/WPA2 "security", because the >layer3 is not bound (as in channel bound) to the layer2 security. > >- -- >] Y avait une poule jammer dans le >muffler!!!!!!!!! | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca >http://www.sandelman.ottawa.on.ca/ >|device driver[ >] panic("Just another Debian GNU/Linux using, kernel hacking, >security guy"); [ >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (GNU/Linux) >Comment: Finger me for keys > >iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ >ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK >UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp >ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8 >ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i >kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ== >=fPHj >-----END PGP SIGNATURE----- >_______________________________________________ >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 --=====================_158536233==.ALT Content-Type: text/html; charset="us-ascii" At 10:32 09/12/2008, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C959A3.A2E84306"

I think that this particular conversation has gone from problem to solution to quickly. Or rather we skipped straight from an attack to a patch to defeat that one attack.

I think Steve was right to ask the question whether we should think about DHCP security. But we should do that by thinking about the security properties we rely on from DHCP and might want to rely on in future.

Background:
To some of us this is not a new problem but something that has
surfaced a few times in the past 10+ years. 
Some of us have been arguing DHCP needs security,
see: (shameless plugs)
         http://tools.ietf.org/html/draft-ietf-dhc-security-requirements-00
         http://tools.ietf.org/html/draft-ietf-dhc-security-arch-01

The DHC working group decided that public key solutions were to
"heavy" and elected to go with shared secret authentication model.
The idea was that Public Key authentication could be added on later,
the question is that time now?

        Olafur



In particular I think that we could do to think in terms of a secure handshake for a client connecting to a WiFi node. Should we be putting the security in the DHCP layer or somewhere else? Should a DHCP handshake in Panera be equivalent to a DCHP handshake on a home network?


What assets are involved here? What are the intrinsic risks that affect those assets? Lets start thinking about the security of the systems that a user is engaged in, not just ad hoc patches to fix one attack.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Michael Richardson
Sent: Mon 12/8/2008 8:27 PM
To: Steven M. Bellovin
Cc: saag@ietf.org
Subject: Re: [saag] time to authenticate dhcp?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Steven" == Steven M Bellovin <smb@cs.columbia.edu> writes:
    Steven> But how, in a public setting?  How can "Steve" (to use the
    Steven> name from the article) *realistically* tell his laptop the
    Steven> proper public key to expect?

  He can't until he is online to look it up.  Naming it is easy.

  Once online, he can confirm it.  What key?  Why a DHCPKEY(tbd) or
perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP.
  See www.wavesec.org .
 
  Also see
     http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth-sig0-00.txt

  which never got enough enthusiam to bother going forward (nor enough
cycles from the freeswan team)

  Note that given a trusted anchor for in-addr.arpa (whether signed .,
or DLV for in-addr.arpa, or whatever), you can confirm key.  If your
local DNS cache is not empty, you may already be able to authenticate
it.
  If the machine doing a MITM on your DHCP server is doing such a good
job of emulating the rest of the Internet that things check out, then I
would suggest that you really are on the Internet :-)

  Note that of course, this completely fails when your DHCP server is
192.168.1.1.   Is there some way to use the outer IP of the router in
the cafe?

  But, if you postulate IPv6, you might as well postulate SEND as well.

  As far as I can tell, this "DNSChanger", "DHCPChanger" attack is
completely untouched by using 802.1x/WPA/WPA2 "security", because the
layer3 is not bound (as in channel bound) to the layer2 security.

- --
]      Y avait une poule jammer dans le muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ
ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK
UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp
ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8
ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i
kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ==
=fPHj
-----END PGP SIGNATURE-----
_______________________________________________
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
--=====================_158536233==.ALT-- --===============1150477887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1150477887==-- From saag-bounces@ietf.org Tue Dec 9 17:25:25 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195113A6B05; Tue, 9 Dec 2008 17:25:25 -0800 (PST) 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 D913A3A6B05 for ; Tue, 9 Dec 2008 17:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 gahyqbSzqD1L for ; Tue, 9 Dec 2008 17:25:19 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5DA0B3A6A05 for ; Tue, 9 Dec 2008 17:25:17 -0800 (PST) Received: from LENOVO ([65.91.214.2]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LADp13R8B-0001AH; Tue, 09 Dec 2008 20:25:06 -0500 From: "Alper Yegin" To: "'Steven M. Bellovin'" References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> In-Reply-To: <7460.1228786061@marajade.sandelman.ca> Date: Wed, 10 Dec 2008 03:24:58 +0200 Message-ID: <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclZofOzFbvFv0IaTnaW/X5eIKVSigAv+wQA Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1+fT/i/+JlGxkfksp82TYMWpqW4KjPAp09yjJA rH0BM8BZcZfVPQ5YUyaiPiO1A7/yYJBcboM5yMrgPY0aI/Zsez J94bIksGnoRogHhZ6AGlw== Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org The simple solution would be to filter certain types of packets on the WiFi access point (AP) based on the ingress interface. For example, AP shall be configured to drop any DHCPOFFER packets received on the 802.11 interface (untrusted public side), and allow those received on the 802.3 interface (trusted intra-net side). That way a visiting host cannot inject a DHCP packet towards the other hosts. Note that, even if you secure DHCP there are other similar attacks to trick the victims leveraging ARP/ND and router discovery, unless those are secured as well. Filtering can be applied there as well. Alper _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 9 19:46:18 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198863A687E; Tue, 9 Dec 2008 19:46:18 -0800 (PST) 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 534253A687E for ; Tue, 9 Dec 2008 19:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Q0E1x1iU3ssJ for ; Tue, 9 Dec 2008 19:46:16 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 644F43A6806 for ; Tue, 9 Dec 2008 19:46:15 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBA3kAXh004037 for ; Wed, 10 Dec 2008 03:46:10 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mBA3k9qE058657 for ; Tue, 9 Dec 2008 20:46:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBA3UCC7005530; Tue, 9 Dec 2008 21:30:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBA3U9a1005529; Tue, 9 Dec 2008 21:30:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 9 Dec 2008 21:30:09 -0600 From: Nicolas Williams To: Michael Richardson Message-ID: <20081210033008.GW2463@Sun.COM> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <7460.1228786061@marajade.sandelman.ca> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Mon, Dec 08, 2008 at 08:27:41PM -0500, Michael Richardson wrote: > As far as I can tell, this "DNSChanger", "DHCPChanger" attack is > completely untouched by using 802.1x/WPA/WPA2 "security", because the > layer3 is not bound (as in channel bound) to the layer2 security. Interesting point. I'm not sure that anyone would be interested in building such a binding, and even we had it, when you use any random cafe's network there's nothing in L2 security that can help you establish trust in its DNS cache servers -- you still need DNSSEC. Also, such a binding would be simply another DNS bandaid. We need DNSSEC. (Although even just enlarging the DNS XID, if we could, would help enormously. I have not followed the DNS lists for a long time, so I don't know if anything's been tried w.r.t. enlarging the DNS XID.) Nico -- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 9 21:23:54 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94CF3A6820; Tue, 9 Dec 2008 21:23:54 -0800 (PST) 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 3618D3A6820 for ; Tue, 9 Dec 2008 21:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=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 Bih8SGWpxMlg for ; Tue, 9 Dec 2008 21:23:52 -0800 (PST) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by core3.amsl.com (Postfix) with ESMTP id 56E893A67F4 for ; Tue, 9 Dec 2008 21:23:52 -0800 (PST) Received: from BLU137-W12 ([65.55.111.72]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 21:23:35 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Alper Yegin , Date: Tue, 9 Dec 2008 21:23:35 -0800 Importance: Normal In-Reply-To: <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2008 05:23:35.0375 (UTC) FILETIME=[7307DDF0:01C95A87] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============1329996508==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1329996508== Content-Type: multipart/alternative; boundary="_a21c6a8a-c612-4281-907a-866e23ca6880_" --_a21c6a8a-c612-4281-907a-866e23ca6880_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed. For example=2C a wireless base station could drop the following i= ncoming packets on=20 the wireless link: 1. IPv6 Router Advertisement packets (ICMP Type 134) 2. DHCPv4 packets sent to the client port (68) 3. DHCPv6 packets sent to the client port (546) Alper said: > The simple solution would be to filter certain types of packets on the Wi= Fi > access point (AP) based on the ingress interface. For example=2C AP shall= be > configured to drop any DHCPOFFER packets received on the 802.11 interface > (untrusted public side)=2C and allow those received on the 802.3 interfac= e > (trusted intra-net side). That way a visiting host cannot inject a DHCP > packet towards the other hosts. >=20 > Note that=2C even if you secure DHCP there are other similar attacks to t= rick > the victims leveraging ARP/ND and router discovery=2C unless those are se= cured > as well. Filtering can be applied there as well.=20 --_a21c6a8a-c612-4281-907a-866e23ca6880_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed. =3B =3B For example=2C a wireless base station could drop t= he following incoming packets on
the wireless link:

1. IPv6 Rout= er Advertisement packets (ICMP Type 134)
2. DHCPv4 packets sent to the c= lient port (68)
3. DHCPv6 packets sent to the client port (546)

A= lper said:

>=3B The simple solution would be to filter certain typ= es of packets on the WiFi
>=3B access point (AP) based on the ingress = interface. For example=2C AP shall be
>=3B configured to drop any DHCP= OFFER packets received on the 802.11 interface
>=3B (untrusted public = side)=2C and allow those received on the 802.3 interface
>=3B (trusted= intra-net side). That way a visiting host cannot inject a DHCP
>=3B p= acket towards the other hosts.
>=3B
>=3B Note that=2C even if yo= u secure DHCP there are other similar attacks to trick
>=3B the victim= s leveraging ARP/ND and router discovery=2C unless those are secured
>= =3B as well. Filtering can be applied there as well.
= --_a21c6a8a-c612-4281-907a-866e23ca6880_-- --===============1329996508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1329996508==-- From saag-bounces@ietf.org Tue Dec 9 23:23:01 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C633A69A4; Tue, 9 Dec 2008 23:23:01 -0800 (PST) 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 2078C3A69A4 for ; Tue, 9 Dec 2008 23:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 X8GGRtbg4lqK for ; Tue, 9 Dec 2008 23:23:00 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 313073A696C for ; Tue, 9 Dec 2008 23:23:00 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBA7MrEY022786 for ; Wed, 10 Dec 2008 07:22:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mBA7MrJo065260 for ; Wed, 10 Dec 2008 00:22:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBA7ETin005708; Wed, 10 Dec 2008 01:14:29 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBA7ECpY005707; Wed, 10 Dec 2008 01:14:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Dec 2008 01:14:12 -0600 From: Nicolas Williams To: Michael Richardson Message-ID: <20081210071412.GY2463@Sun.COM> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <20081210033008.GW2463@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081210033008.GW2463@Sun.COM> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Tue, Dec 09, 2008 at 09:30:09PM -0600, Nicolas Williams wrote: > Also, such a binding would be simply another DNS bandaid. We need > DNSSEC. (Although even just enlarging the DNS XID, if we could, would > help enormously. I have not followed the DNS lists for a long time, so > I don't know if anything's been tried w.r.t. enlarging the DNS XID.) Stupid question(?): couldn't we define an echo/reply RR type as a way to add a larger XID to DNS? The RR name would be a long, randomly- generated string, acting as an extended XID. Follow-up stupid question(?): until such an RR type is specified and deployed, couldn't one use a convention for naming a special name for which one expects an NXDOMAIN result? This would be an approximation of an echo/reply RR type. The difference between an approximation and a real echo/reply RR type would be that caching servers would know about the echo/reply RR type and put in their own reply (and use different extended XIDs, if I may call them that, in their own queries to other servers). E.g., query for exid., type any, expect NXDOMAIN. Of course, clients couldn't count on this until servers that implement such a thing are widely deployed. An DNSSEC deployment would render the need for extended XIDs moot. But it'd have been great if in the randomized port patching frenzy we could have added support for extended XIDs. Nico -- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 01:00:37 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7119528C19B; Wed, 10 Dec 2008 01:00:37 -0800 (PST) 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 9FC6228C19B for ; Wed, 10 Dec 2008 01:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 TebyTcezRSpd for ; Wed, 10 Dec 2008 01:00:36 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A583428C19A for ; Wed, 10 Dec 2008 01:00:35 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mBA90F4a015557; Wed, 10 Dec 2008 11:00:27 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 10:59:49 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 10:59:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Dec 2008 10:59:46 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720286D049@vaebe104.NOE.Nokia.com> In-Reply-To: <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] time to authenticate dhcp? Thread-Index: AclZofOzFbvFv0IaTnaW/X5eIKVSigAv+wQAABB+p7A= References: <20081208173839.0e26afe4@cs.columbia.edu><7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> From: To: X-OriginalArrivalTime: 10 Dec 2008 08:59:46.0724 (UTC) FILETIME=[A68EA640:01C95AA5] X-Nokia-AV: Clean Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org As far as I know, many existing WiFi APs (those intended for public access/enterprise use, not home APs) already do what you're proposing, and similar filtering for ARP. SAVI WG is working on standardizing that behavior. Best regards, Pasi > -----Original Message----- > From: Alper Yegin > Sent: 10 December, 2008 03:25 > To: 'Steven M. Bellovin' > Cc: saag@ietf.org > Subject: Re: [saag] time to authenticate dhcp? > > The simple solution would be to filter certain types of packets on > the WiFi access point (AP) based on the ingress interface. For > example, AP shall be configured to drop any DHCPOFFER packets > received on the 802.11 interface (untrusted public side), and allow > those received on the 802.3 interface (trusted intra-net side). That > way a visiting host cannot inject a DHCP packet towards the other > hosts. > > Note that, even if you secure DHCP there are other similar attacks > to trick the victims leveraging ARP/ND and router discovery, unless > those are secured as well. Filtering can be applied there as well. > > > Alper _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 06:07:01 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507163A6BB3; Wed, 10 Dec 2008 06:07:01 -0800 (PST) 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 273D23A6B9F for ; Wed, 10 Dec 2008 06:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=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 7yzgQqnn+K2C for ; Wed, 10 Dec 2008 06:06:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [192.139.46.41]) by core3.amsl.com (Postfix) with ESMTP id 63D003A6BB0 for ; Wed, 10 Dec 2008 06:06:58 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTP id 49F315C08C; Wed, 10 Dec 2008 08:14:24 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EBB564E7DC; Wed, 10 Dec 2008 09:06:36 -0500 (EST) From: Michael Richardson To: Nicolas Williams In-Reply-To: <20081210033008.GW2463@Sun.COM> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <20081210033008.GW2463@Sun.COM> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) MIME-Version: 1.0 Date: Wed, 10 Dec 2008 09:06:36 -0500 Message-ID: <6843.1228917996@marajade.sandelman.ca> Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >>>>> "Nicolas" =3D=3D Nicolas Williams writes: >> As far as I can tell, this "DNSChanger", "DHCPChanger" attack is >> completely untouched by using 802.1x/WPA/WPA2 "security", because >> the layer3 is not bound (as in channel bound) to the layer2 >> security. Nicolas> Interesting point. I'm not sure that anyone would be Nicolas> interested in building such a binding, and even we had it, Nicolas> when you use any random cafe's network there's nothing in Nicolas> L2 security that can help you establish trust in its DNS Nicolas> cache servers -- you still need DNSSEC. ... layer-3 security. That's why I find WPA/etc. such a waste of time. We need security that applications can find and trust. -- = ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 06:07:34 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9359F3A6BAD; Wed, 10 Dec 2008 06:07:34 -0800 (PST) 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 43F953A6BAF for ; Wed, 10 Dec 2008 06:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=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 oTBhS1o52iKr for ; Wed, 10 Dec 2008 06:07:32 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [192.139.46.41]) by core3.amsl.com (Postfix) with ESMTP id 9BC093A6BAD for ; Wed, 10 Dec 2008 06:07:32 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTP id 9062A5C08C; Wed, 10 Dec 2008 08:15:13 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 420704E7DC; Wed, 10 Dec 2008 09:07:26 -0500 (EST) From: Michael Richardson To: Bernard Aboba In-Reply-To: References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) MIME-Version: 1.0 Date: Wed, 10 Dec 2008 09:07:26 -0500 Message-ID: <6890.1228918046@marajade.sandelman.ca> Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >>>>> "Bernard" =3D=3D Bernard Aboba writes: Bernard> Indeed. For example, a wireless base station could drop Bernard> the following incoming packets on the wireless link: Bernard> 1. IPv6 Router Advertisement packets (ICMP Type 134) Bernard> 2. DHCPv4 packets sent to the client port (68) 3. DHCPv6 Bernard> packets sent to the client port (546) You mean, create more deep packet inspection requirements in intermediate nodes to get around the lack of end-to-end security? -- = ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 07:50:34 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCCC3A68D4; Wed, 10 Dec 2008 07:50:34 -0800 (PST) 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 B3FFE3A68D4 for ; Wed, 10 Dec 2008 07:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 SF+XKx6pZbwR for ; Wed, 10 Dec 2008 07:50:32 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 1576F3A677D for ; Wed, 10 Dec 2008 07:50:32 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBAFoHwF010779; Wed, 10 Dec 2008 15:50:17 GMT Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBAFoGHn014166; Wed, 10 Dec 2008 10:50:17 -0500 (EST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAFoGrC010494; Wed, 10 Dec 2008 10:50:16 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBAFo4C5010216; Wed, 10 Dec 2008 10:50:04 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Bernard Aboba In-Reply-To: References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org> Date: Wed, 10 Dec 2008 10:50:02 -0500 Message-Id: <1228924202.28471.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.0 Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Tue, 2008-12-09 at 21:23 -0800, Bernard Aboba wrote: > For example, a wireless base station could drop the following incoming > packets on the wireless link: > > 1. IPv6 Router Advertisement packets (ICMP Type 134) > 2. DHCPv4 packets sent to the client port (68) > 3. DHCPv6 packets sent to the client port (546) That doesn't make things worse, but it also doesn't help if the attacker's system is acting as a base station (bridging selected traffic through to the legitimate base station). - Bill _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 08:03:17 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A343A6BCA; Wed, 10 Dec 2008 08:03:17 -0800 (PST) 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 B33EC3A6BCB for ; Wed, 10 Dec 2008 08:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=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 mAWikf9IACG5 for ; Wed, 10 Dec 2008 08:03:16 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by core3.amsl.com (Postfix) with ESMTP id E12023A6866 for ; Wed, 10 Dec 2008 08:03:15 -0800 (PST) Received: from BLU137-W36 ([65.55.116.72]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 08:03:10 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , Alper Yegin Date: Wed, 10 Dec 2008 08:03:10 -0800 Importance: Normal In-Reply-To: <1696498986EFEC4D9153717DA325CB720286D049@vaebe104.NOE.Nokia.com> References: <20081208173839.0e26afe4@cs.columbia.edu><7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$@yegin@yegin.org> <1696498986EFEC4D9153717DA325CB720286D049@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2008 16:03:10.0213 (UTC) FILETIME=[CC377350:01C95AE0] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============2124034800==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============2124034800== Content-Type: multipart/alternative; boundary="_289f26c8-2bce-492b-b997-63368249b158_" --_289f26c8-2bce-492b-b997-63368249b158_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C hotspot and enterprise class APs typically do support IP filtering a= nd have for quite a while. Some of the open source AP distributions suitable for h= ome use also support IP filtering.=20 > Date: Wed=2C 10 Dec 2008 10:59:46 +0200 > From: Pasi.Eronen@nokia.com > To: alper.yegin@yegin.org > CC: saag@ietf.org > Subject: Re: [saag] time to authenticate dhcp? >=20 > As far as I know=2C many existing WiFi APs (those intended for public > access/enterprise use=2C not home APs) already do what you're > proposing=2C and similar filtering for ARP. SAVI WG is working > on standardizing that behavior. >=20 > Best regards=2C > Pasi=20 --_289f26c8-2bce-492b-b997-63368249b158_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C hotspot and enterprise class APs typically do support IP filtering a= nd have
for quite a while. =3B Some of the open source AP distributi= ons suitable for home use
also support IP filtering.

>=3B Date= : Wed=2C 10 Dec 2008 10:59:46 +0200
>=3B From: Pasi.Eronen@nokia.com>=3B To: alper.yegin@yegin.org
>=3B CC: saag@ietf.org
>=3B Su= bject: Re: [saag] time to authenticate dhcp?
>=3B
>=3B As far as= I know=2C many existing WiFi APs (those intended for public
>=3B acce= ss/enterprise use=2C not home APs) already do what you're
>=3B proposi= ng=2C and similar filtering for ARP. SAVI WG is working
>=3B on standa= rdizing that behavior.
>=3B
>=3B Best regards=2C
>=3B Pasi =

= --_289f26c8-2bce-492b-b997-63368249b158_-- --===============2124034800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============2124034800==-- From saag-bounces@ietf.org Wed Dec 10 09:52:23 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E083A6868; Wed, 10 Dec 2008 09:52:23 -0800 (PST) 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 1622B3A6868 for ; Wed, 10 Dec 2008 09:52:23 -0800 (PST) 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 03Ri8sbKrF8D for ; Wed, 10 Dec 2008 09:52:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EE4453A6847 for ; Wed, 10 Dec 2008 09:52:21 -0800 (PST) Received: from [10.20.30.163] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBAHqCNU057096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 10:52:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081210071412.GY2463@Sun.COM> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <20081210033008.GW2463@Sun.COM> <20081210071412.GY2463@Sun.COM> Date: Wed, 10 Dec 2008 09:52:10 -0800 To: Nicolas Williams , Michael Richardson From: Paul Hoffman Cc: saag@ietf.org Subject: [saag] DNS XID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 1:14 AM -0600 12/10/08, Nicolas Williams wrote: >Stupid question(?): couldn't we define an echo/reply RR type as a way to >add a larger XID to DNS? The RR name would be a long, randomly- >generated string, acting as an extended XID. Not a stupid question, but SAAG is the wrong mailing list for this: this is pertinent to the DNSEXT WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 10 15:49:35 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B992B3A6C13; Wed, 10 Dec 2008 15:49:35 -0800 (PST) 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 8A35428C180 for ; Wed, 10 Dec 2008 15:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 ZhIb+58wBcRU for ; Wed, 10 Dec 2008 15:49:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id CD5EE3A6C09 for ; Wed, 10 Dec 2008 15:49:33 -0800 (PST) Received: from LENOVO ([65.91.214.2]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LAYns03WI-0001xJ; Wed, 10 Dec 2008 18:49:22 -0500 From: "Alper Yegin" To: "'Bill Sommerfeld'" , "'Bernard Aboba'" References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org> <1228924202.28471.6.camel@localhost> In-Reply-To: <1228924202.28471.6.camel@localhost> Date: Thu, 11 Dec 2008 01:49:07 +0200 Message-ID: <090e01c95b21$e7cadd50$b76097f0$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acla3wXmLKElGGN8QhqsMMdEzx3hygAQcwCQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18GXtzIUI4Y8uv6pez4AKxaWHR8L9MHlyVVRSy AHMXddV97paR4mjrgvBo5fX7NOPlLxl5K1UTIJv8OgxwpVz7+c gxe/RpCm8CKjQOM9Nrm5Q== Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org > > For example, a wireless base station could drop the following > incoming > > packets on the wireless link: > > > > 1. IPv6 Router Advertisement packets (ICMP Type 134) > > 2. DHCPv4 packets sent to the client port (68) > > 3. DHCPv6 packets sent to the client port (546) > > That doesn't make things worse, but it also doesn't help if the > attacker's system is acting as a base station (bridging selected > traffic > through to the legitimate base station). The rogue entity inserting itself between the victim host and legitimate base station (Mitm) is a much harder attack. So, the filtering has considerable value. Furthermore, one way to address this "MitM" attack is to use L2 access authentication. That way the host knows it is connected to a legitimate network. Even than (when your attack scenario is out of our way), the aforementioned filtering is needed so that other authenticated on-link hosts cannot inject the bogus DHCP/ARP/ND packets to the network. Alper _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 11 08:04:36 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09443A6931; Thu, 11 Dec 2008 08:04:36 -0800 (PST) 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 778E03A6931 for ; Thu, 11 Dec 2008 08:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 zYYRx8bwQdyK for ; Thu, 11 Dec 2008 08:04:34 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A38023A6782 for ; Thu, 11 Dec 2008 08:04:34 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBBG4LHl008464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:04:21 -0500 (EST) Date: Thu, 11 Dec 2008 11:04:21 -0500 From: Jeffrey Hutzelman To: Alper Yegin , "'Bill Sommerfeld'" , "'Bernard Aboba'" Message-ID: In-Reply-To: <200812102349.mBANnWRU021832@raisinbran.srv.cs.cmu.edu> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org> <1228924202.28471.6.camel@localhost> <200812102349.mBANnWRU021832@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Thursday, December 11, 2008 01:49:07 AM +0200 Alper Yegin wrote: >> > For example, a wireless base station could drop the following >> incoming >> > packets on the wireless link: >> > >> > 1. IPv6 Router Advertisement packets (ICMP Type 134) >> > 2. DHCPv4 packets sent to the client port (68) >> > 3. DHCPv6 packets sent to the client port (546) >> >> That doesn't make things worse, but it also doesn't help if the >> attacker's system is acting as a base station (bridging selected >> traffic >> through to the legitimate base station). > > > The rogue entity inserting itself between the victim host and legitimate > base station (Mitm) is a much harder attack. So, the filtering has > considerable value. > > Furthermore, one way to address this "MitM" attack is to use L2 access > authentication. That way the host knows it is connected to a legitimate > network. What's a "legitimate network"? I don't share any authentication secrets with my local Panera Bread. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 11 08:17:15 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D12B3A6867; Thu, 11 Dec 2008 08:17:15 -0800 (PST) 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 EB0F23A6867 for ; Thu, 11 Dec 2008 08:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.693 X-Spam-Level: X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 6b53tbNvq1rU for ; Thu, 11 Dec 2008 08:17:13 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id F27113A6844 for ; Thu, 11 Dec 2008 08:17:12 -0800 (PST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBBGH1G8013297; Thu, 11 Dec 2008 11:17:01 -0500 Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <17204A44-37B0-4054-B760-F884AD057499@nist.gov> From: Tim Polk Date: Thu, 11 Dec 2008 11:17:29 -0500 To: saag@ietf.org X-Mailer: Apple Mail (2.753.1) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: [saag] Request for review: NIST key transport specification 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Folks, Here is another request from NIST for document review (for SP = 800-56B, see the first paragraph in the quoted text) and a reminder = that the comment period will close soon for the draft FIPS 186-3 and = SP 800-102. While I have not yet read it myself, I am particularly concerned = about 800-56B. This is the companion to 800-56A, which complicated = using existing IETF protocol standards with FIPS approved = cryptography. I would like to avoid repeating that particular = process! I know this is a busy time (this will probably be my in- = flight reading material over the holidays) but I hope that other = IETFers will budget some time for this document. An ounce of = prevention, etc., etc. > NIST requests comments on Draft SP 800-56B, Recommendation for Pair- = > Wise Key Establishment Using Integer Factorization Cryptography. = > This Recommendation provides the specifications of asymmetric-based = > key agreement and key transport schemes that are based on the = > Rivest Shamir Adleman (RSA) algorithm. The draft is available at = > http://www.csrc.nist.gov/publications/drafts/800-56B/ = > Draft_SP800-56B_Dec2008.pdf.. Please provide comments to = > ebarker@nist.gov by February 12, 2009, with =93Comments on SP = > 800-56B=94 in the subject line. > > Please note that the public comments period for FIPS 186-3, the = > Digital Signature Standard, closes on Friday, December 12, 2008. = > The draft is available at http://www.csrc.nist.gov/publications/ = > drafts/800-57-part3/Draft_SP800-57- = > Part3_Recommendationforkeymanagement.pdf. Send any comments by the = > due date, as we intend to finalize this Standard as soon as = > possible. Please submit comments to ebarker@nist.gov with "Comments = > on Draft 186-3" in the subject line. > > Also, the public comment period on SP 800-102, Recommendation for = > Digital Signature Timeliness, closes on Friday, December 19, 2008. = > The draft is available at http://www.csrc.nist.gov/publications/ = > drafts/800-102/Draft_SP800-102.pdf. Please provide comments to = > ebarker@nist.gov with =93Comments on SP 800-102=94 in the subject line Thanks, Tim Polk _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 11 08:29:17 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB8828C1E4; Thu, 11 Dec 2008 08:29:17 -0800 (PST) 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 2DDF63A6931 for ; Thu, 11 Dec 2008 08:29:16 -0800 (PST) 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=[AWL=0.000, 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 Jrs7MbCoDKOD for ; Thu, 11 Dec 2008 08:29:15 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D471D3A6C53 for ; Thu, 11 Dec 2008 08:29:14 -0800 (PST) Received: from [10.20.30.163] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBGT53b021339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 09:29:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17204A44-37B0-4054-B760-F884AD057499@nist.gov> References: <17204A44-37B0-4054-B760-F884AD057499@nist.gov> Date: Thu, 11 Dec 2008 08:29:04 -0800 To: saag@ietf.org From: Paul Hoffman Subject: Re: [saag] Request for review: NIST key transport specification 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 11:17 AM -0500 12/11/08, Tim Polk wrote: >Here is another request from NIST for document review (for SP 800-56B, see the first paragraph in the quoted text) and a reminder that the comment period will close soon for the draft FIPS 186-3 and SP 800-102. For those of you who read the title (Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography) and don't get the connection: it's RSA encryption, something that most security WGs use. Of particular interest should be the large number of schemes described in Section 8. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 11 15:45:13 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F65A28C108; Thu, 11 Dec 2008 15:45:13 -0800 (PST) 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 E528A28C108 for ; Thu, 11 Dec 2008 15:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 tPvwaYS3c7cP for ; Thu, 11 Dec 2008 15:45:12 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id AE1AA28C102 for ; Thu, 11 Dec 2008 15:45:11 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.8+Sun/8.12.9) with ESMTP id mBBNivQw020005 for ; Thu, 11 Dec 2008 23:44:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mBBNiuFU027940 for ; Thu, 11 Dec 2008 16:44:56 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBBNaSnI007375; Thu, 11 Dec 2008 17:36:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBBNaJQ2007374; Thu, 11 Dec 2008 17:36:19 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Dec 2008 17:36:19 -0600 From: Nicolas Williams To: Paul Hoffman Message-ID: <20081211233619.GF2463@Sun.COM> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <20081210033008.GW2463@Sun.COM> <20081210071412.GY2463@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] DNS XID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Wed, Dec 10, 2008 at 09:52:10AM -0800, Paul Hoffman wrote: > At 1:14 AM -0600 12/10/08, Nicolas Williams wrote: > >Stupid question(?): couldn't we define an echo/reply RR type as a way to > >add a larger XID to DNS? The RR name would be a long, randomly- > >generated string, acting as an extended XID. > > Not a stupid question, but SAAG is the wrong mailing list for this: > this is pertinent to the DNSEXT WG. Looking at the namedroppers list archive, the idea has been discussed already, in various independent threads, and apparently many have come up with much the same idea independently. I'm just late to that party :) Nico -- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 11 16:54:30 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AE23A6ABC; Thu, 11 Dec 2008 16:54:30 -0800 (PST) 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 A1A4A3A6AAF for ; Thu, 11 Dec 2008 16:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 Ru-+pGidGb-f for ; Thu, 11 Dec 2008 16:54:29 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D41D73A696E for ; Thu, 11 Dec 2008 16:54:28 -0800 (PST) Received: from LENOVO ([65.91.214.2]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LAwII2x6U-00011h; Thu, 11 Dec 2008 19:54:21 -0500 From: "Alper Yegin" To: "'Jeffrey Hutzelman'" , "'Bill Sommerfeld'" , "'Bernard Aboba'" References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org> <1228924202.28471.6.camel@localhost> <200812102349.mBANnWRU021832@raisinbran.srv.cs.cmu.edu> In-Reply-To: Date: Fri, 12 Dec 2008 02:54:06 +0200 Message-ID: <0aeb01c95bf4$2618ff10$724afd30$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclbqiYvetdzIIzjSaeVWHZR7bdrCAASPRNg Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19YmPZP6z1i2TtY/rpIjUGom2fBEyZruT/SUZT bz5BeSfeJzjKJyJR3F3AOhRAu6Nv0v6ZXs+8TViVbK/lap6ZVN B6osbMgGOZMQ3GffRTn6g== Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org > --On Thursday, December 11, 2008 01:49:07 AM +0200 Alper Yegin > wrote: > > >> > For example, a wireless base station could drop the following > >> incoming > >> > packets on the wireless link: > >> > > >> > 1. IPv6 Router Advertisement packets (ICMP Type 134) > >> > 2. DHCPv4 packets sent to the client port (68) > >> > 3. DHCPv6 packets sent to the client port (546) > >> > >> That doesn't make things worse, but it also doesn't help if the > >> attacker's system is acting as a base station (bridging selected > >> traffic > >> through to the legitimate base station). > > > > > > The rogue entity inserting itself between the victim host and > legitimate > > base station (Mitm) is a much harder attack. So, the filtering has > > considerable value. > > > > Furthermore, one way to address this "MitM" attack is to use L2 > access > > authentication. That way the host knows it is connected to a > legitimate > > network. > > What's a "legitimate network"? I don't share any authentication > secrets > with my local Panera Bread. I was referring to "L2 authentication." In cases where L2 authentication is used, you host has either a PSK with the WiFi AP (e.g., home gateway), or a PSK/cert with a AAA server that has a direct (or hop-by-hop) PSK with the AAA client on the AP (e.g., enterprise/operator WiFi). Alper _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Dec 12 00:54:54 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D9B3A6AD6; Fri, 12 Dec 2008 00:54:54 -0800 (PST) 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 045A53A6AD6 for ; Fri, 12 Dec 2008 00:54:53 -0800 (PST) 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 4lDuiJCo50iF for ; Fri, 12 Dec 2008 00:54:52 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 031AF3A695C for ; Fri, 12 Dec 2008 00:54:52 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id D37E8AF673; Fri, 12 Dec 2008 08:54:45 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E15A9AF640; Fri, 12 Dec 2008 08:54:44 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 35B1A838732; Fri, 12 Dec 2008 03:54:39 -0500 (EST) Date: Fri, 12 Dec 2008 03:54:39 -0500 From: "Steven M. Bellovin" To: "Alper Yegin" Message-ID: <20081212035439.1c4cecbb@cs.columbia.edu> In-Reply-To: <0aeb01c95bf4$2618ff10$724afd30$@yegin@yegin.org> References: <20081208173839.0e26afe4@cs.columbia.edu> <7460.1228786061@marajade.sandelman.ca> <078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org> <1228924202.28471.6.camel@localhost> <200812102349.mBANnWRU021832@raisinbran.srv.cs.cmu.edu> <0aeb01c95bf4$2618ff10$724afd30$@yegin@yegin.org> Organization: Columbia University X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) Mime-Version: 1.0 Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Fri, 12 Dec 2008 02:54:06 +0200 "Alper Yegin" wrote: > > > --On Thursday, December 11, 2008 01:49:07 AM +0200 Alper Yegin > > wrote: > > > > >> > For example, a wireless base station could drop the following > > >> incoming > > >> > packets on the wireless link: > > >> > > > >> > 1. IPv6 Router Advertisement packets (ICMP Type 134) > > >> > 2. DHCPv4 packets sent to the client port (68) > > >> > 3. DHCPv6 packets sent to the client port (546) > > >> > > >> That doesn't make things worse, but it also doesn't help if the > > >> attacker's system is acting as a base station (bridging selected > > >> traffic > > >> through to the legitimate base station). > > > > > > > > > The rogue entity inserting itself between the victim host and > > legitimate > > > base station (Mitm) is a much harder attack. So, the filtering has > > > considerable value. > > > > > > Furthermore, one way to address this "MitM" attack is to use L2 > > access > > > authentication. That way the host knows it is connected to a > > legitimate > > > network. > > > > What's a "legitimate network"? I don't share any authentication > > secrets > > with my local Panera Bread. > > I was referring to "L2 authentication." In cases where L2 > authentication is used, you host has either a PSK with the WiFi AP > (e.g., home gateway), or a PSK/cert with a AAA server that has a > direct (or hop-by-hop) PSK with the AAA client on the AP (e.g., > enterprise/operator WiFi). > Again, what about Panera? They don't charge; they don't have much need for that sort of infrastructure. Besides, how do people register in the first place? Is this the real AP, or is it an evil twin pointing at a credit card-stealing service? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Dec 12 07:26:16 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671583A6B26; Fri, 12 Dec 2008 07:26:16 -0800 (PST) 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 DBBA43A6B26 for ; Fri, 12 Dec 2008 07:26:14 -0800 (PST) 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.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WvvzuQ0oY4ii for ; Fri, 12 Dec 2008 07:26:13 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id C40F53A6B22 for ; Fri, 12 Dec 2008 07:26:13 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mBCF4icU000491; Fri, 12 Dec 2008 07:04:44 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 07:25:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 07:25:57 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC19@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] time to authenticate dhcp? Thread-Index: AclcN01qi8rzho0PSiKavCNPIXPw0AANaNTL References: <20081208173839.0e26afe4@cs.columbia.edu><7460.1228786061@marajade.sandelman.ca><078a01c95a66$1f63ad80$5e2b0880$%yegin@yegin.org><1228924202.28471.6.camel@localhost><200812102349.mBANnWRU021832@raisinbran.srv.cs.cmu.edu><0aeb01c95bf4$2618ff10$724afd30$@yegin@yegin.org> <20081212035439.1c4cecbb@cs.columbia.edu> From: "Hallam-Baker, Phillip" To: "Steven M. Bellovin" , "Alper Yegin" X-OriginalArrivalTime: 12 Dec 2008 15:25:57.0888 (UTC) FILETIME=[EE793000:01C95C6D] Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? 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: , Content-Type: multipart/mixed; boundary="===============1117702347==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org This is a multi-part message in MIME format. --===============1117702347== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95C6D.EE21EF0C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95C6D.EE21EF0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As I said earlier, lets look at the system.=20 Steve is right here, we need to start from a use case and work out the = security requirements. The problem here is to provide security to real = people in real situations. If we just look at one particular attack and = jump to securing DHCP we will still be stuck in a reactive mode that is = ineffective in dealing with organized crime. Lets take Alice goes to Panera as a use case and look for ways to meet = the whole needs of the system, including Panera's need to be able to = present terms and conditions and possibly employ mechanism to limit = access to actual customers. And also including the need to integrate = strong encryption into the wireless link itself because not every = Internet protocol and server has application layer security. And then lets consider the subtly different use case of Joe's coffee = house that nobody really knows and does not have a trusted brand, or an = extended network of shops. -----Original Message----- From: saag-bounces@ietf.org on behalf of Steven M. Bellovin Sent: Fri 12/12/2008 3:54 AM To: Alper Yegin Cc: saag@ietf.org Subject: Re: [saag] time to authenticate dhcp? =20 On Fri, 12 Dec 2008 02:54:06 +0200 "Alper Yegin" wrote: > =20 > > --On Thursday, December 11, 2008 01:49:07 AM +0200 Alper Yegin > > wrote: > >=20 > > >> > For example, a wireless base station could drop the following > > >> incoming > > >> > packets on the wireless link: > > >> > > > >> > 1. IPv6 Router Advertisement packets (ICMP Type 134) > > >> > 2. DHCPv4 packets sent to the client port (68) > > >> > 3. DHCPv6 packets sent to the client port (546) > > >> > > >> That doesn't make things worse, but it also doesn't help if the > > >> attacker's system is acting as a base station (bridging selected > > >> traffic > > >> through to the legitimate base station). > > > > > > > > > The rogue entity inserting itself between the victim host and > > legitimate > > > base station (Mitm) is a much harder attack. So, the filtering has > > > considerable value. > > > > > > Furthermore, one way to address this "MitM" attack is to use L2 > > access > > > authentication. That way the host knows it is connected to a > > legitimate > > > network. > >=20 > > What's a "legitimate network"? I don't share any authentication > > secrets > > with my local Panera Bread. >=20 > I was referring to "L2 authentication." In cases where L2 > authentication is used, you host has either a PSK with the WiFi AP > (e.g., home gateway), or a PSK/cert with a AAA server that has a > direct (or hop-by-hop) PSK with the AAA client on the AP (e.g., > enterprise/operator WiFi).=20 >=20 Again, what about Panera? They don't charge; they don't have much need for that sort of infrastructure. Besides, how do people register in the first place? Is this the real AP, or is it an evil twin pointing at a credit card-stealing service? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C95C6D.EE21EF0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] time to authenticate dhcp?

As I said earlier, lets look at the system.

Steve is right here, we need to start from a use case and work out the = security requirements. The problem here is to provide security to real = people in real situations. If we just look at one particular attack and = jump to securing DHCP we will still be stuck in a reactive mode that is = ineffective in dealing with organized crime.


Lets take Alice goes to Panera as a use case and look for ways to meet = the whole needs of the system, including Panera's need to be able to = present terms and conditions and possibly employ mechanism to limit = access to actual customers. And also including the need to integrate = strong encryption into the wireless link itself because not every = Internet protocol and server has application layer security.

And then lets consider the subtly different use case of Joe's coffee = house that nobody really knows and does not have a trusted brand, or an = extended network of shops.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Steven M. Bellovin
Sent: Fri 12/12/2008 3:54 AM
To: Alper Yegin
Cc: saag@ietf.org
Subject: Re: [saag] time to authenticate dhcp?

On Fri, 12 Dec 2008 02:54:06 +0200
"Alper Yegin" <alper.yegin@yegin.org> wrote:

> 
> > --On Thursday, December 11, 2008 01:49:07 AM +0200 Alper = Yegin
> > <alper.yegin@yegin.org> wrote:
> >
> > >> > For example, a wireless base station could drop = the following
> > >> incoming
> > >> > packets on the wireless link:
> > >> >
> > >> > 1. IPv6 Router Advertisement packets (ICMP Type = 134)
> > >> > 2. DHCPv4 packets sent to the client port = (68)
> > >> > 3. DHCPv6 packets sent to the client port = (546)
> > >>
> > >> That doesn't make things worse, but it also doesn't = help if the
> > >> attacker's system is acting as a base station = (bridging selected
> > >> traffic
> > >> through to the legitimate base station).
> > >
> > >
> > > The rogue entity inserting itself between the victim host = and
> > legitimate
> > > base station (Mitm) is a much harder attack. So, the = filtering has
> > > considerable value.
> > >
> > > Furthermore, one way to address this "MitM" = attack is to use L2
> > access
> > > authentication. That way the host knows it is connected = to a
> > legitimate
> > > network.
> >
> > What's a "legitimate network"?  I don't share = any authentication
> > secrets
> > with my local Panera Bread.
>
> I was referring to "L2 authentication." In cases where = L2
> authentication is used, you host has either a PSK with the WiFi = AP
> (e.g., home gateway), or a PSK/cert with a AAA server that has = a
> direct (or hop-by-hop) PSK with the AAA client on the AP (e.g.,
> enterprise/operator WiFi).
>
Again, what about Panera?  They don't charge; they don't have much = need
for that sort of infrastructure.

Besides, how do people register in the first place?  Is this the = real
AP, or is it an evil twin pointing at a credit card-stealing = service?


        =         --Steve Bellovin, http://www.cs.columbia.edu/~smb<= /A>
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C95C6D.EE21EF0C-- --===============1117702347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1117702347==-- From saag-bounces@ietf.org Fri Dec 12 21:32:15 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A573A6808; Fri, 12 Dec 2008 21:32:15 -0800 (PST) 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 728273A6808 for ; Fri, 12 Dec 2008 21:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 vX9aQyZtHCVv for ; Fri, 12 Dec 2008 21:32:13 -0800 (PST) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 72E383A67AD for ; Fri, 12 Dec 2008 21:32:13 -0800 (PST) Received: from pgpdev.ihtfp.org (c-76-109-66-143.hsd1.fl.comcast.net [76.109.66.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id E181BBD8556; Sat, 13 Dec 2008 00:32:05 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id mBD14Tcd007859; Fri, 12 Dec 2008 20:04:29 -0500 To: Paul Hoffman References: <17204A44-37B0-4054-B760-F884AD057499@nist.gov> From: Derek Atkins Date: Fri, 12 Dec 2008 20:04:28 -0500 In-Reply-To: (Paul Hoffman's message of "Thu\, 11 Dec 2008 08\:29\:04 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Cc: saag@ietf.org Subject: Re: [saag] Request for review: NIST key transport specification 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Paul Hoffman writes: > At 11:17 AM -0500 12/11/08, Tim Polk wrote: >>Here is another request from NIST for document review (for SP 800-56B, see the first paragraph in the quoted text) and a reminder that the comment period will close soon for the draft FIPS 186-3 and SP 800-102. > > For those of you who read the title (Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography) and don't get the connection: it's RSA encryption, something that most security WGs use. Of particular interest should be the large number of schemes described in Section 8. Is there any particular reason that NIST decided to change the name of every construct in this document? Why did they invent their own terms instead of using the existing nomenclature? It makes it orders of magnitude more difficult to compare this document to existing standards (e.g. PKCS). > --Paul Hoffman, Director > --VPN Consortium -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sat Dec 13 16:43:35 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598513A6809; Sat, 13 Dec 2008 16:43:35 -0800 (PST) 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 EAB7F3A6809 for ; Sat, 13 Dec 2008 16:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 mKLC1fnyu2q3 for ; Sat, 13 Dec 2008 16:43:34 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 29BCC3A6452 for ; Sat, 13 Dec 2008 16:43:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 83AE7196A8; Sun, 14 Dec 2008 13:43:22 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffKS+EXS+BSh; Sun, 14 Dec 2008 13:43:22 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4810219680; Sun, 14 Dec 2008 13:43:19 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 10D0C1A04001; Sun, 14 Dec 2008 13:43:18 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LBf4n-0003CK-Tq; Sun, 14 Dec 2008 13:43:17 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: derek@ihtfp.com, paul.hoffman@vpnc.org In-Reply-To: Message-Id: Date: Sun, 14 Dec 2008 13:43:17 +1300 Cc: saag@ietf.org Subject: Re: [saag] Request for review: NIST key transport specification 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Derek Atkins writes: >Is there any particular reason that NIST decided to change the name of every >construct in this document? Why did they invent their own terms instead of >using the existing nomenclature? It makes it orders of magnitude more >difficult to compare this document to existing standards (e.g. PKCS). It's not NIST so much, it's P1363, they've been busy standardising away in their own pocket universe for the last 10 years or so and have created a terminology that only makes sense to someone else trapped in their reality. Compare RFC 2313 and RFC 2347 for an illustrative example of this, anyone who's familiar with PKCS #1 can read 2437 and see what it's trying to say, but only because they already know what's supposed to be there and can map from the P1363-created terminology to what they're used to (and 2347 is only a very mild form of P1363-itis, more recent docs like the NIST one are far, far worse). It's like trying to work out a restaurant menu in Cyrillic, you know roughly what each bit of the menu corresponds to and what should be there, but it takes a considerable amount of effort to map to it and confirm your suspicion ("bOPW"? Hmm, well it's under soup, so ...). Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sat Dec 13 17:13:09 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB353A6841; Sat, 13 Dec 2008 17:13:09 -0800 (PST) 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 6AE9B3A680E for ; Sat, 13 Dec 2008 17:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.242 X-Spam-Level: X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, 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 BNWsRN2zABwH for ; Sat, 13 Dec 2008 17:13:07 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 99D603A6452 for ; Sat, 13 Dec 2008 17:13:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A68C09E9C2; Sun, 14 Dec 2008 14:13:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKBFXTlnN9sq; Sun, 14 Dec 2008 14:13:00 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8A5959E9C0; Sun, 14 Dec 2008 14:12:58 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4C5181AE4001; Sun, 14 Dec 2008 14:12:56 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LBfXU-0004b2-5X; Sun, 14 Dec 2008 14:12:56 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: derek@ihtfp.com, , paul.hoffman@vpnc.org, , saag@ietf.org Message-Id: Date: Sun, 14 Dec 2008 14:12:56 +1300 Subject: Re: [saag] Request for review: NIST key transport specification 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Actually from a quick look through this doc (to see if it's as bad as Derek pointed out), there's some really bizarre stuff in here. For example 6.4.1.2 is completely backwards, in normal RSA keygen you generate p and q and take it from there. Section 6.4.1.2 assumes you have a d and then work backwards from there to get p and q (!!?!?!) and then apply primality tests to them... this is almost exactly backwards from how you'd normally get an RSA key, and in any case can't ever work in devices that use the CRT for which there's never any d present to begin with (although in that case I guess you'd use the CRT-only validation given later). And that's not even beginning to touch on some of the other problems, e.g. the fact that under this scheme the cost of loading a key is now as high or higher than generating it was in the first place because you have to repeat all of the keygen primality checks and whatnot. That's just from a quick glance so far... it looks like the doc consists of a few good ideas mixed in with a huge amount of... really weird... confusion. Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Thu Dec 18 08:13:30 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5F03A6B12; Thu, 18 Dec 2008 08:13:30 -0800 (PST) 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 5FA5E3A6B18 for ; Wed, 17 Dec 2008 08:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 Oc1ago+0zw13 for ; Wed, 17 Dec 2008 08:34:33 -0800 (PST) Received: from smtp180.iad.emailsrvr.com (smtp180.iad.emailsrvr.com [207.97.245.180]) by core3.amsl.com (Postfix) with ESMTP id 2C0503A6B14 for ; Wed, 17 Dec 2008 08:34:33 -0800 (PST) Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 55008206F75 for ; Wed, 17 Dec 2008 11:34:25 -0500 (EST) Received: by relay8.relay.iad.mlsrvr.com (Authenticated sender: craemer-AT-isoc.org) with ESMTPSA id 47F2A2069EB for ; Wed, 17 Dec 2008 11:34:25 -0500 (EST) From: "Kevin Craemer" To: Date: Wed, 17 Dec 2008 11:34:25 -0500 Message-ID: <006e01c96065$52edcf50$e501a8c0@ISOC.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclgZVKx/tQ869edRo+dB6g3oQkKdA== X-Mailman-Approved-At: Thu, 18 Dec 2008 08:13:29 -0800 Subject: [saag] NDSS Security Symposium 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org An update on ISOC's NDSS security symposium, for your consideration. Kevin Craemer Internet Society (ISOC) = = = = = = = = = The 16th Annual Network and Distributed System Security Symposium (NDSS '09), February 8-11 in San Diego, is pleased to announce the following confirmed speakers: Keynote: Ivan Arce, CTO and Co-Founder, Core Security Technologies Penetration Testing for Grown Ups Penetration testing is more than 30 years old, yet for the most part of its history has been deemed a costly, obscure and narrowly focused security practice delivered as craftsmanship of limited value by very technically skilled security teams. In this opening presentation, Arce will discuss the evolution of penetration testing, the current challenges and opportunities, and the open and unexplored territory that 'grown up' security practitioners will face in the next decade. Invited Talk: Brian Chess, Chief Scientist, Fortify Software Secure Programming with Static Analysis Creating secure code requires more than just good intentions. Programmers need to know how to make their code safe in an almost infinite number of scenarios and configurations. Static source code analysis gives programmers the ability to review their work with a fine tooth comb and uncover many of the kinds of errors that lead directly to vulnerabilities. Learn how static analysis works, how to integrate it into software development processes, and how to make the most of it during security code review. Also to be featured at NDSS'09: * Presentation of 20 Refereed Papers * National Science Foundation's GENI Project * Work-in-Progress Presentations * Best "Hall Track" in the Business Additional information and paper abstract summaries are at: http://www.isoc.org/ndss09/ Register by January 9 for discount. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Fri Dec 19 09:55:38 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD9F28C136; Fri, 19 Dec 2008 09:55:38 -0800 (PST) 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 8BF433A6A51; Fri, 19 Dec 2008 09:55:36 -0800 (PST) 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=[AWL=0.000, 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 V0IIVqWFW6JN; Fri, 19 Dec 2008 09:55:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 80C943A6842; Fri, 19 Dec 2008 09:55:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,250,1228089600"; d="scan'208";a="120757482" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Dec 2008 17:55:27 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mBJHtRiK030810; Fri, 19 Dec 2008 09:55:27 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJHtRQh013267; Fri, 19 Dec 2008 17:55:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 09:55:27 -0800 Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 09:55:26 -0800 Message-Id: <84C25F56-E917-4347-96A6-714CAB178E1B@cisco.com> From: David McGrew To: David McGrew In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Dec 2008 09:55:25 -0800 References: <20081219172158.9B50F3A6886@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 19 Dec 2008 17:55:26.0921 (UTC) FILETIME=[F9534390:01C96202] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1740; t=1229709327; x=1230573327; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[Cfrg]=20draft-mcgrew-tss-01 |Sender:=20; bh=6LR14untmSFQ7Bx6kGJWkD7gwQhf/d8GmqO/14MnsBM=; b=FOzJctBo9kXXVutnS9uAeCV8frcS7vv9I5unM4dqBNx/Acm+ZP8gopGtB7 9gCX5OkJ6hu3dRPtU2YMtEPxOcLpBxqSYx80PpRNCZjRDpIrRuqQP9VYgH9v 9h23RDJ5zG; Authentication-Results: sj-dkim-3; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: cfrg@ietf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] draft-mcgrew-tss-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Correcting the SAAG address. On Dec 19, 2008, at 9:39 AM, David McGrew wrote: > Hello, > > this new draft describes a threshold secret sharing method. I > suggest that this draft be the basis for an RFC (informational would > be fine, I expect), and I welcome comments on it. > > best regards, > > David > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: December 19, 2008 9:21:58 AM PST >> To: mcgrew@cisco.com >> Cc: praveenpatnala@yahoo.com >> Subject: New Version Notification for draft-mcgrew-tss-01 >> >> >> A new version of I-D, draft-mcgrew-tss-01.txt has been successfuly >> submitted by David McGrew and posted to the IETF repository. >> >> Filename: draft-mcgrew-tss >> Revision: 01 >> Title: Threshold Secret Sharing >> Creation_date: 2008-12-19 >> WG ID: Independent Submission >> Number_of_pages: 24 >> >> Abstract: >> Threshold secret sharing (TSS) provides a way to generate N shares >> from a value, so that any M of those shares can be used to >> reconstruct the original value, but any M-1 shares provide no >> information about that value. This method can provide shared access >> control on key material and other secrets that must be strongly >> protected. >> >> This note defines a threshold secret sharing method based on >> polynomial interpolation in GF(256) and a format for the storage and >> transmission of shares. It also provides usage guidance, describes >> how to test an implementation, and supplies test cases. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 23 12:24:36 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CF23A68B6; Tue, 23 Dec 2008 12:24:36 -0800 (PST) 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 9D2823A68B6 for ; Tue, 23 Dec 2008 12:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 5ZKU+ylzo6LA for ; Tue, 23 Dec 2008 12:24:34 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id 654503A6870 for ; Tue, 23 Dec 2008 12:24:34 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so528221nfh.39 for ; Tue, 23 Dec 2008 12:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=fUfWqAq67Lm9Sr0bAPIUatoZvC+E+WrXuBybf0SMadg=; b=gLSOuWIPfSuHXsB6mfONPFllZIn6rkx7nMTuVw1olyPmlSdi52+72AYOHS+38NmJbS 7y1BN3nASnuVQPYgdo76ReWky0TUlyl8TpY7I5iIMS1qB6jZBm1+z7ZOxE3Il0UVeL3X JvyCmAErA19A+Wq0y51ex5Ippk348W1c+axbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=rrFsstZc9Zg/CT5ePc1a3nYJXK9woIeveGNThYEeNt2H5Y6lsgW7zCmZnBdG8tUOLZ LFcyJLoxgxeVmlXsk7x1rLlFZDXKdVKsvTktI8Ree231VkGMFQPvD9wwZDFd94m5K52S 4WJt2BBLRXFvjlQdQKNHIkmUfodXc0fxfYy5I= Received: by 10.210.50.5 with SMTP id x5mr9336895ebx.3.1230063863989; Tue, 23 Dec 2008 12:24:23 -0800 (PST) Received: by 10.210.111.11 with HTTP; Tue, 23 Dec 2008 12:24:23 -0800 (PST) Message-ID: <98f5f260812231224m646b4a1ar48424d8061b368d1@mail.gmail.com> Date: Tue, 23 Dec 2008 15:24:23 -0500 From: "=?ISO-8859-1?Q?Katrin_H=F6per?=" To: saag@ietf.org In-Reply-To: <98f5f260812231220uc00d853i383ad2a3eecca3a@mail.gmail.com> MIME-Version: 1.0 References: <98f5f260812231220uc00d853i383ad2a3eecca3a@mail.gmail.com> Subject: [saag] NIST public call for comments: "Recommendation for EAP Methods Used in Wireless Network Access Authentication" 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: , Content-Type: multipart/mixed; boundary="===============0138571727==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0138571727== Content-Type: multipart/alternative; boundary="----=_Part_97758_6532314.1230063863971" ------=_Part_97758_6532314.1230063863971 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, This is a NIST public call for comments that is of interest for all IETF WGs that deal with EAP. The draft contains security requirements for key deriving EAP methods that are used for wireless access authentication. It covers non-tunneled as well as tunneled EAP methods. Please send your comments to the email address provided in the original message below. http://csrc.nist.gov/publications/PubsDrafts.html#800-120 Katrin Hoeper -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- NIST announces the release of draft Special Publication 800-120, Recommendation for EAP Methods Used in Wireless Network Access Authentication. This Recommendation specifies security requirements for authentication methods with key establishment supported by the Extensible Authentication Protocol (EAP) defined in IETF RFC 3748 for wireless access authentications to federal networks. Please submit comments to 800-120comments@nist.gov<800-120comments@nist.gov?Subject=Comments%20SP%20800-120>with "Comments on SP 800-120" in the subject line. The comment period closes on January 30, 2009. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------=_Part_97758_6532314.1230063863971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
This is a NIST public call for comments that is of interest for all IETF WGs that deal with EAP.
The draft contains security requirements for key deriving EAP methods that are used for wireless access authentication.
It covers non-tunneled as well as tunneled EAP methods.
 
Please send your comments to the email address provided in the original message below.
 
 
Katrin Hoeper
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
NIST announces the release of draft Special Publication 800-120, Recommendation for EAP Methods Used in Wireless Network Access Authentication. This Recommendation specifies security requirements for authentication methods with key establishment supported by the Extensible Authentication Protocol (EAP) defined in IETF RFC 3748 for wireless access authentications to federal networks. Please submit comments to 800-120comments@nist.gov with "Comments on SP 800-120" in the subject line. The comment period closes on January 30, 2009.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

------=_Part_97758_6532314.1230063863971-- --===============0138571727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0138571727==-- From saag-bounces@ietf.org Tue Dec 23 15:35:04 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D95428C174; Tue, 23 Dec 2008 15:35:04 -0800 (PST) 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 838113A6B37; Tue, 23 Dec 2008 15:35:03 -0800 (PST) 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 8s9Q1gwEWs1N; Tue, 23 Dec 2008 15:35:02 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id ACC5B3A67A5; Tue, 23 Dec 2008 15:35:02 -0800 (PST) Received: from ATLANTIS.PC.CS.CMU.EDU (cpe-24-165-179-134.neo.res.rr.com [24.165.179.134]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBNNYO2O010693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 18:34:25 -0500 (EST) Date: Tue, 23 Dec 2008 18:32:47 -0500 From: Jeffrey Hutzelman To: David McGrew Message-ID: In-Reply-To: <200812191755.mBJHtWQm008375@toasties.srv.cs.cmu.edu> References: <20081219172158.9B50F3A6886@core3.amsl.com> <200812191755.mBJHtWQm008375@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: cfrg@ietf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] draft-mcgrew-tss-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Friday, December 19, 2008 09:55:25 AM -0800 David McGrew wrote: >> this new draft describes a threshold secret sharing method. I >> suggest that this draft be the basis for an RFC (informational would >> be fine, I expect), and I welcome comments on it. In general, this seems like a good idea. I don't believe we have a good TSS algorithm suitable for use in IETF protocols, and I can think of some possible uses for one. Just a few thoughts... - The definition of the exponentiation operation fails to take into account the case where i is 0. - The field multiplication operation is more than a little opaque. How were the EXP and LOG tables generated? Is there any convenient way to demonstrate that that the tables are actually correct and result in an invertible operation? I'm afraid I'm being dragged out the door before having a chance to finish reading; I'll comment on the rest if/when I have more to add. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Sun Dec 28 23:13:55 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB5828C213; Sun, 28 Dec 2008 23:13:55 -0800 (PST) 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 163313A6814; Tue, 23 Dec 2008 17:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.541 X-Spam-Level: X-Spam-Status: No, score=-8.541 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_18=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8] 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 1Aorlpmdvb-c; Tue, 23 Dec 2008 17:56:49 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 44D063A67DD; Tue, 23 Dec 2008 17:56:48 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA04704; Tue, 23 Dec 2008 20:56:22 -0500 (EST) From: der Mouse Message-Id: <200812240156.UAA04704@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 23 Dec 2008 19:47:00 -0500 (EST) To: cfrg@ietf.org, saag@ietf.org In-Reply-To: References: <20081219172158.9B50F3A6886@core3.amsl.com> <200812191755.mBJHtWQm008375@toasties.srv.cs.cmu.edu> X-Mailman-Approved-At: Sun, 28 Dec 2008 23:13:53 -0800 Subject: Re: [saag] [Cfrg] draft-mcgrew-tss-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org > - The field multiplication operation is more than a little opaque. > How were the EXP and LOG tables generated? Is there any convenient > way to demonstrate that that the tables are actually correct and > result in an invertible operation? The simple thing to do is to build a small program that uses the tables, and definitions of multiplication and division, from the draft, and verifies that a*b/a=b and a*b/b=a whenever, respectively, a or b is nonzero, and that, for any nonzero a, the function x->a*x is a permutation on the nonzero values of x. I've done this (test program source is below), and they pass. I'm hardly an expert group theorist, but I *think* that the underlying math will work for any tables that pass those two tests. (Since the definition of multiplication is symmetric, there is no need to test separately that x->x*b is a permutation for any nonzero b.) As for how EXP and LOG were generated, I don't know, since I didn't generate them. :) I suspect EXP was generated by computing successive powers of 3 in the field used by Rijndael (ie, GF(256) with reducing polynomial 0x11b); the values match values computed that way, so even if it wasn't it might as well have been. (LOG is just the inverse of EXP.) My program checks that EXP matches the powers of 3 in GF(256) with polynomial 0x11b, and that EXP and LOG are inverses. (I actually would prefer that the spec define multiplication and division in terms of GF(256) and a particular reducing polynomial rather than in terms of tables, even if the operations defined are identical.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Here's that test program. It prints any errors it finds, so it should produce no output. #include #include #include static unsigned char EXP[] = { 0x01, 0x03, 0x05, 0x0f, 0x11, 0x33, 0x55, 0xff, 0x1a, 0x2e, 0x72, 0x96, 0xa1, 0xf8, 0x13, 0x35, 0x5f, 0xe1, 0x38, 0x48, 0xd8, 0x73, 0x95, 0xa4, 0xf7, 0x02, 0x06, 0x0a, 0x1e, 0x22, 0x66, 0xaa, 0xe5, 0x34, 0x5c, 0xe4, 0x37, 0x59, 0xeb, 0x26, 0x6a, 0xbe, 0xd9, 0x70, 0x90, 0xab, 0xe6, 0x31, 0x53, 0xf5, 0x04, 0x0c, 0x14, 0x3c, 0x44, 0xcc, 0x4f, 0xd1, 0x68, 0xb8, 0xd3, 0x6e, 0xb2, 0xcd, 0x4c, 0xd4, 0x67, 0xa9, 0xe0, 0x3b, 0x4d, 0xd7, 0x62, 0xa6, 0xf1, 0x08, 0x18, 0x28, 0x78, 0x88, 0x83, 0x9e, 0xb9, 0xd0, 0x6b, 0xbd, 0xdc, 0x7f, 0x81, 0x98, 0xb3, 0xce, 0x49, 0xdb, 0x76, 0x9a, 0xb5, 0xc4, 0x57, 0xf9, 0x10, 0x30, 0x50, 0xf0, 0x0b, 0x1d, 0x27, 0x69, 0xbb, 0xd6, 0x61, 0xa3, 0xfe, 0x19, 0x2b, 0x7d, 0x87, 0x92, 0xad, 0xec, 0x2f, 0x71, 0x93, 0xae, 0xe9, 0x20, 0x60, 0xa0, 0xfb, 0x16, 0x3a, 0x4e, 0xd2, 0x6d, 0xb7, 0xc2, 0x5d, 0xe7, 0x32, 0x56, 0xfa, 0x15, 0x3f, 0x41, 0xc3, 0x5e, 0xe2, 0x3d, 0x47, 0xc9, 0x40, 0xc0, 0x5b, 0xed, 0x2c, 0x74, 0x9c, 0xbf, 0xda, 0x75, 0x9f, 0xba, 0xd5, 0x64, 0xac, 0xef, 0x2a, 0x7e, 0x82, 0x9d, 0xbc, 0xdf, 0x7a, 0x8e, 0x89, 0x80, 0x9b, 0xb6, 0xc1, 0x58, 0xe8, 0x23, 0x65, 0xaf, 0xea, 0x25, 0x6f, 0xb1, 0xc8, 0x43, 0xc5, 0x54, 0xfc, 0x1f, 0x21, 0x63, 0xa5, 0xf4, 0x07, 0x09, 0x1b, 0x2d, 0x77, 0x99, 0xb0, 0xcb, 0x46, 0xca, 0x45, 0xcf, 0x4a, 0xde, 0x79, 0x8b, 0x86, 0x91, 0xa8, 0xe3, 0x3e, 0x42, 0xc6, 0x51, 0xf3, 0x0e, 0x12, 0x36, 0x5a, 0xee, 0x29, 0x7b, 0x8d, 0x8c, 0x8f, 0x8a, 0x85, 0x94, 0xa7, 0xf2, 0x0d, 0x17, 0x39, 0x4b, 0xdd, 0x7c, 0x84, 0x97, 0xa2, 0xfd, 0x1c, 0x24, 0x6c, 0xb4, 0xc7, 0x52, 0xf6, 0x00 }; static unsigned char LOG[] = { 0x00, 0x00, 0x19, 0x01, 0x32, 0x02, 0x1a, 0xc6, 0x4b, 0xc7, 0x1b, 0x68, 0x33, 0xee, 0xdf, 0x03, 0x64, 0x04, 0xe0, 0x0e, 0x34, 0x8d, 0x81, 0xef, 0x4c, 0x71, 0x08, 0xc8, 0xf8, 0x69, 0x1c, 0xc1, 0x7d, 0xc2, 0x1d, 0xb5, 0xf9, 0xb9, 0x27, 0x6a, 0x4d, 0xe4, 0xa6, 0x72, 0x9a, 0xc9, 0x09, 0x78, 0x65, 0x2f, 0x8a, 0x05, 0x21, 0x0f, 0xe1, 0x24, 0x12, 0xf0, 0x82, 0x45, 0x35, 0x93, 0xda, 0x8e, 0x96, 0x8f, 0xdb, 0xbd, 0x36, 0xd0, 0xce, 0x94, 0x13, 0x5c, 0xd2, 0xf1, 0x40, 0x46, 0x83, 0x38, 0x66, 0xdd, 0xfd, 0x30, 0xbf, 0x06, 0x8b, 0x62, 0xb3, 0x25, 0xe2, 0x98, 0x22, 0x88, 0x91, 0x10, 0x7e, 0x6e, 0x48, 0xc3, 0xa3, 0xb6, 0x1e, 0x42, 0x3a, 0x6b, 0x28, 0x54, 0xfa, 0x85, 0x3d, 0xba, 0x2b, 0x79, 0x0a, 0x15, 0x9b, 0x9f, 0x5e, 0xca, 0x4e, 0xd4, 0xac, 0xe5, 0xf3, 0x73, 0xa7, 0x57, 0xaf, 0x58, 0xa8, 0x50, 0xf4, 0xea, 0xd6, 0x74, 0x4f, 0xae, 0xe9, 0xd5, 0xe7, 0xe6, 0xad, 0xe8, 0x2c, 0xd7, 0x75, 0x7a, 0xeb, 0x16, 0x0b, 0xf5, 0x59, 0xcb, 0x5f, 0xb0, 0x9c, 0xa9, 0x51, 0xa0, 0x7f, 0x0c, 0xf6, 0x6f, 0x17, 0xc4, 0x49, 0xec, 0xd8, 0x43, 0x1f, 0x2d, 0xa4, 0x76, 0x7b, 0xb7, 0xcc, 0xbb, 0x3e, 0x5a, 0xfb, 0x60, 0xb1, 0x86, 0x3b, 0x52, 0xa1, 0x6c, 0xaa, 0x55, 0x29, 0x9d, 0x97, 0xb2, 0x87, 0x90, 0x61, 0xbe, 0xdc, 0xfc, 0xbc, 0x95, 0xcf, 0xcd, 0x37, 0x3f, 0x5b, 0xd1, 0x53, 0x39, 0x84, 0x3c, 0x41, 0xa2, 0x6d, 0x47, 0x14, 0x2a, 0x9e, 0x5d, 0x56, 0xf2, 0xd3, 0xab, 0x44, 0x11, 0x92, 0xd9, 0x23, 0x20, 0x2e, 0x89, 0xb4, 0x7c, 0xb8, 0x26, 0x77, 0x99, 0xe3, 0xa5, 0x67, 0x4a, 0xed, 0xde, 0xc5, 0x31, 0xfe, 0x18, 0x0d, 0x63, 0x8c, 0x80, 0xc0, 0xf7, 0x70, 0x07 }; static unsigned char m(unsigned char a, unsigned char b) { return((a&&b)?EXP[(LOG[a]+LOG[b])%255]:0); } static unsigned char d(unsigned char a, unsigned char b) { if (! b) abort(); return(a?EXP[(255+LOG[a]-LOG[b])%255]:0); } int main(void); int main(void) { unsigned int a; unsigned int b; unsigned int p; unsigned int q; char v[256]; p = 1; for (a=0;a<255;a++) { if (EXP[a] != p) { printf("EXP[%02x] = %02x, not %02x\n",a,EXP[a],p); } p = (p ^ ((p&0x7f)<<1)) ^ ((p&0x80) ? 0x1b : 0); } for (a=1;a<256;a++) { if (EXP[LOG[a]] != a) { printf("EXP[LOG[%02x]] = %02x\n",a,EXP[LOG[a]]); } bzero(&v[0],256); for (b=1;b<256;b++) { p = m(a,b); v[p] = 1; q = d(p,a); if (q != b) { printf("%02x * %02x = %02x / %02x = %02x\n",a,b,p,a,q); } q = d(p,b); if (q != a) { printf("%02x * %02x = %02x / %02x = %02x\n",a,b,p,b,q); } } for (b=1;b<256;b++) { if (! v[b]) { printf("%02x * all misses %02x\n",a,b); } } } return(0); } _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 06:00:48 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2F228C0DE; Tue, 30 Dec 2008 06:00:48 -0800 (PST) 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 3D8953A6A57; Tue, 30 Dec 2008 06:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 kTXa9YOa3aio; Tue, 30 Dec 2008 06:00:44 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B51913A68B5; Tue, 30 Dec 2008 06:00:44 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mBUDxTOE015474; Tue, 30 Dec 2008 08:00:32 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Dec 2008 16:00:29 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Dec 2008 16:00:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Dec 2008 16:00:23 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202B43725@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD Notes for December 2008 Thread-Index: AclqhvWTq5UlslgQQpCkE8JTXl8MHw== From: To: , X-OriginalArrivalTime: 30 Dec 2008 14:00:28.0980 (UTC) FILETIME=[F8D76F40:01C96A86] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for December 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi all, Here's again 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. Best regards, Pasi MISC NOTES - After an extremely busy December, I'm somewhat behind in my emails. I won't mind being pinged again if I haven't replied in two weeks. - Security area WG chairs will have a virtual meeting on January 12 to discuss having "virtual interim meetings" to help WGs get more work done between the IETF meetings. - draft-eronen-enterprise-number-documentation: a new draft written together with David Harrington, related to syslog WG documents. - Processed a bunch of errata (18) for security area RFCs. - (not wearing AD hat): Errata #1623 (for RFC 4282): waiting for Dan Romascanu to mark this as "Rejected" with note explaining why WORKING GROUPS DKIM - draft-ietf-dkim-ssp: went through IETF Last Call; waiting for proposed text and a revised ID to clarify some parts. Tentatively placed on agenda of 2008-01-15 IESG telechat. - draft-ietf-dkim-overview: in Publication Requested, waiting for me to read it. - Waiting for WG to send list of RFC errata IDs the WG agrees on. EMU - draft-ietf-emu-gpsk: was approved by IESG, now in RFC Editor Queue - NIST requested comments about draft SP 800-120, "Recommendation for EAP Methods Used in Wireless Network Access Authentication" IPSECME - Lots of emails that I need to read, but haven't done so yet... - (not wearing AD hat) Waiting for Russ to verify errata #1502 for RFC 4718 [since 2008-09-12] ISMS - All the WG documents went through WG Last Call; hoping to see revised IDs soon. KEYPROV - Hoping the WG soon decides what "client side" authentication options are the most important for DSKPP. PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: was approved by IESG, now in RFC Editor Queue - draft-ietf-pkix-rfc4055-update: will go to IETF Last Call first thing in January. SASL - Hoping the WG soon converges on SCRAM design SYSLOG - draft-ietf-syslog-transport-tls: now in AUTH48 state - draft-ietf-syslog-sign: in AD Evaluation, waiting for me to read version -24 [since 2008-12-11] TLS - IESG approved Eric Rescorla as the IANA expert for TLS registries. - draft-ietf-tls-des-idea: went through IETF Last Call, on agenda of 2009-01-08 IESG telechat. - draft-ietf-tls-ecdhe-psk: in Publication Requested, waiting for me to read it (in January) - draft-ietf-tls-psk-new-mac-aes-gcm: same as ecdhe-psk - Errata #1585: waiting for Ekr to confirm that this errata is correct [since 2008-11-06] - (not WG item) Two IPR disclosures related to draft-hajjeh-tls-identity- protection were filed (1036 and 1044) OTHER DOCUMENTS - draft-ietf-pkix-cmp-transport-protocols: It seems some folks are interested in reviving this long-expired draft, so that current implementation behavior is documented somewhere. I've promised to read and comment if/when something is submitted. - draft-randall-3447bis: James Randall posted the -00 draft; I should read this and comment. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this. - "Security roadmap for routing protocols": Gregory has sent the first draft-of-a-draft; Tim and I have promised to comment and contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. - draft-mattsson-srtp-store-and-forward: I've promised to read this and send comments, but haven't done so yet. DISCUSSES (active -- something happened within last month) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-housley-internet-draft-sig-file: I need to read version -07 and related emails [since 2008-12-24] - draft-ietf-calsify-rfc2445bis: waiting for authors to reply to my comment [since 2008-12-18] - draft-ietf-dime-mip6-integrated: I need to read the proposed text sent on 2008-12-30 and reply [since 2008-12-30] - draft-ietf-enum-combined: waiting for authors to propose text or a revised ID [since 2008-12-11] - draft-ietf-l1vpn-ospfv3-auto-discovery: text agreed, waiting for a revised ID or RFC Editor Note [since 2008-12-19] - draft-ietf-mext-nemo-v4traversal: some text agreed, waiting for authors to propose text for the remaining comments [since 2008-12-30] - draft-ietf-mip4-dsmipv4: some text agreed, waiting for authors to reply to my remaining comments [since 2008-12-19] - draft-ietf-mipshop-mstp-solution: discussion ongoing, I need to read and reply to the latest emails [since 2008-12-17] - draft-ietf-monami6-multiplecoa: some text agreed, waiting for authors to reply to my remaining comments [since 2008-12-05] - draft-ietf-nfsv4-rfc1831bis: waiting for authors to reply to my remaining comments or submit a revised ID [since 2008-12-15] - draft-ietf-nfsv4-rpc-netid: waiting for authors to reply to my comments or submit a revised ID [since 2008-12-16] - draft-ietf-ospf-lls: waiting for a revised ID or RFC Editor Notes to address my remaining comments [since 2008-12-18] - draft-ietf-roll-urban-routing-reqs: discussion ongoing, I need to read and reply to emails [since 2008-12-19] - draft-ietf-shim6-proto: discussion ongoing, waiting for authors to propose approach [since 2008-12-30] - draft-ietf-smime-sha2: text agreed, waiting for a revised ID or RFC Editor Note to fix the DER hex strings [since 2008-12-29] - draft-ietf-tcpm-tcp-uto: waiting for authors to reply to my comments or submit a revised ID [since 2008-12-16] - draft-igoe-secsh-aes-gcm: discussions ongoing, hoping to have more information in early January - draft-kato-camellia-ctrccm: authors have proposed text that would resolve my comments; waiting for a revised ID [since 2008-12-19] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-kato-ipsec-camellia-modes: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] - draft-ietf-sip-dtls-srtp-framework: waiting for authors to reply to my comments or submit a revised ID [since 2008-11-06] - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: waiting for authors to reply to my comments or submit a revised ID [since 2008-08-28] - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] --end-- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 08:05:46 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8583A6A59; Tue, 30 Dec 2008 08:05:46 -0800 (PST) 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 64C973A6A59 for ; Tue, 30 Dec 2008 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.322 X-Spam-Level: X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_40=-0.185, USER_IN_WHITELIST=-100] 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 PYSt3OJKPnNz for ; Tue, 30 Dec 2008 08:05:44 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id C75BD3A69AA for ; Tue, 30 Dec 2008 08:05:43 -0800 (PST) Received: (qmail 4826 invoked by uid 0); 30 Dec 2008 16:05:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 16:05:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 11:05:28 -0500 To: ietf-pkix@imc.org,ietf-smime@imc.org,saag@ietf.org,cfrg@irtf.org From: Russ Housley Mime-Version: 1.0 Message-Id: <20081230160543.C75BD3A69AA@core3.amsl.com> Subject: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org http://www.win.tue.nl/hashclash/rogue-ca/ MD5 considered harmful today Creating a rogue CA certificate December 30, 2008 Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol. Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 10:34:03 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EFC3A6994; Tue, 30 Dec 2008 10:34:03 -0800 (PST) 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 7BC083A6805 for ; Tue, 30 Dec 2008 10:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.727, 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 djIlK0N44qCD for ; Tue, 30 Dec 2008 10:34:01 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 647383A6994 for ; Tue, 30 Dec 2008 10:34:01 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUIXkTS014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:33:47 -0500 (EST) Date: Tue, 30 Dec 2008 13:33:46 -0500 From: Jeffrey Hutzelman To: Russ Housley , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Message-ID: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley wrote: > http://www.win.tue.nl/hashclash/rogue-ca/ > > MD5 considered harmful today > Creating a rogue CA certificate > > December 30, 2008 > > Alexander Sotirov, Marc Stevens, > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > Weger > > We have identified a vulnerability in the Internet Public Key > Infrastructure (PKI) used to issue digital certificates for secure > websites. As a proof of concept we executed a practical attack scenario > and successfully created a rogue Certification Authority (CA) certificate > trusted by all common web browsers. This certificate allows us to > impersonate any website on the Internet, including banking and e-commerce > sites secured using the HTTPS protocol. > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > function that allows the construction of different messages with the same > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > collisions between 2004 and 2007 showed that the use of this hash > function in digital signatures can lead to theoretical attack scenarios. > Our current work proves that at least one attack scenario can be > exploited in practice, thus exposing the security infrastructure of the > web to realistic threats. This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 12:07:05 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBF93A6998; Tue, 30 Dec 2008 12:07:05 -0800 (PST) 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 579E43A6821 for ; Tue, 30 Dec 2008 12:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 O-VmbG0aoPM4 for ; Tue, 30 Dec 2008 12:07:04 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 58D8B3A6816 for ; Tue, 30 Dec 2008 12:07:04 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DFF4550822; Tue, 30 Dec 2008 12:23:11 -0800 (PST) Date: Tue, 30 Dec 2008 12:23:11 -0800 From: Eric Rescorla To: Jeffrey Hutzelman In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081230202311.DFF4550822@romeo.rtfm.com> Cc: ietf-pkix@imc.org, cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At Tue, 30 Dec 2008 13:33:46 -0500, Jeffrey Hutzelman wrote: > > --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley > wrote: > > > http://www.win.tue.nl/hashclash/rogue-ca/ > > > > MD5 considered harmful today > > Creating a rogue CA certificate > > > > December 30, 2008 > > > > Alexander Sotirov, Marc Stevens, > > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > > Weger > > > > We have identified a vulnerability in the Internet Public Key > > Infrastructure (PKI) used to issue digital certificates for secure > > websites. As a proof of concept we executed a practical attack scenario > > and successfully created a rogue Certification Authority (CA) certificate > > trusted by all common web browsers. This certificate allows us to > > impersonate any website on the Internet, including banking and e-commerce > > sites secured using the HTTPS protocol. > > > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > > function that allows the construction of different messages with the same > > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > > collisions between 2004 and 2007 showed that the use of this hash > > function in digital signatures can lead to theoretical attack scenarios. > > Our current work proves that at least one attack scenario can be > > exploited in practice, thus exposing the security infrastructure of the > > web to realistic threats. > > > This is a practical application of an approach that I remember being > brought up during discussions about MD5 at a saag meeting some time ago. I > also recall someone mentioning at the time that many/most CA's were already > issuing certificates with random rather than sequential serial numbers, > which would have thwarted this particular attack. Yep. Would that they all were. FWIW, here is my writeup of this issue, targeted towards a broader community: http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 12:23:35 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4F528C0D9; Tue, 30 Dec 2008 12:23:35 -0800 (PST) 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 BAC4E28C0D9 for ; Tue, 30 Dec 2008 12:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 s71qzrnXxb8m for ; Tue, 30 Dec 2008 12:23:34 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 6D9833A691D for ; Tue, 30 Dec 2008 12:23:34 -0800 (PST) Received: (qmail 14731 invoked by uid 0); 30 Dec 2008 20:16:37 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 20:16:37 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 15:10:45 -0500 To: Jeffrey Hutzelman From: Russ Housley In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Message-Id: <20081230202334.6D9833A691D@core3.amsl.com> Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Jeff: >>http://www.win.tue.nl/hashclash/rogue-ca/ >> >>MD5 considered harmful today >>Creating a rogue CA certificate >> >>December 30, 2008 >> >>Alexander Sotirov, Marc Stevens, >>Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de >>Weger >> >>We have identified a vulnerability in the Internet Public Key >>Infrastructure (PKI) used to issue digital certificates for secure >>websites. As a proof of concept we executed a practical attack scenario >>and successfully created a rogue Certification Authority (CA) certificate >>trusted by all common web browsers. This certificate allows us to >>impersonate any website on the Internet, including banking and e-commerce >>sites secured using the HTTPS protocol. >> >>Our attack takes advantage of a weakness in the MD5 cryptographic hash >>function that allows the construction of different messages with the same >>MD5 hash. This is known as an MD5 "collision". Previous work on MD5 >>collisions between 2004 and 2007 showed that the use of this hash >>function in digital signatures can lead to theoretical attack scenarios. >>Our current work proves that at least one attack scenario can be >>exploited in practice, thus exposing the security infrastructure of the >>web to realistic threats. > > >This is a practical application of an approach that I remember being >brought up during discussions about MD5 at a saag meeting some time >ago. I also recall someone mentioning at the time that many/most >CA's were already issuing certificates with random rather than >sequential serial numbers, which would have thwarted this particular attack. RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Russ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 12:53:50 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEDC28C230; Tue, 30 Dec 2008 12:53:49 -0800 (PST) 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 0098E28C225; Tue, 30 Dec 2008 12:53:48 -0800 (PST) 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 4wBXnpF1Spx1; Tue, 30 Dec 2008 12:53:47 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9410428C0D9; Tue, 30 Dec 2008 12:53:46 -0800 (PST) Received: from [10.20.30.158] ([207.62.247.66]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrXOU036766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Date: Tue, 30 Dec 2008 12:53:06 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org From: Paul Hoffman Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 13:28:32 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8C328C1F1; Tue, 30 Dec 2008 13:28:32 -0800 (PST) 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 CF3B428C1F1 for ; Tue, 30 Dec 2008 13:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 b7MIeYGrjEdR for ; Tue, 30 Dec 2008 13:28:30 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B54083A69BC for ; Tue, 30 Dec 2008 13:28:30 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C219450822; Tue, 30 Dec 2008 13:39:34 -0800 (PST) Date: Tue, 30 Dec 2008 13:39:34 -0800 From: Eric Rescorla To: Paul Hoffman In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081230213934.C219450822@romeo.rtfm.com> Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At Tue, 30 Dec 2008 12:53:06 -0800, Paul Hoffman wrote: > > At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: > >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. > > Your recollection may be off. I believe I was the person who brought > up the serial number hack at the mic, and I'm pretty sure I said > "some", not "many" (and certainly not "most"!). When I looked at a > handful of popular CAs earlier this week, I only found a few who are > using randomization in their serial numbers. So it's in my deck from SAAG at IETF 62. http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf I don't know whether many or most do it. IMO everyone should. > >RFC 5280 does not include this advice. It is sound advice that was > >discussed in PKIX and other venues. Perhaps a BCP is in order. > > Man, that is really stretching the definition of "best". > > For one, it is only needed in signatures that use known-attackable > hash functions. A "best practice" in that case is to use a better > hash function in the signature. Also, it relies on the ability of > the software using the random number to be sure that the result is a > positive integer in ASN.1, which seems overly optimistic. > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. I certainly agree we should be encouraging the use of non-broken hash functions. However, randomizing the SN seems like very cheap backward compatible insurance against the fact that that's going to take a long time. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:01:32 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D104F28C27A; Tue, 30 Dec 2008 14:01:32 -0800 (PST) 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 2152928C271 for ; Tue, 30 Dec 2008 14:01:31 -0800 (PST) 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 R-ml92N1OqHT for ; Tue, 30 Dec 2008 14:01:30 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 262703A6403 for ; Tue, 30 Dec 2008 14:01:30 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (173-101-98-177.pools.spcsdns.net [173.101.98.177]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUM1Cht017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:01:14 -0500 (EST) Date: Tue, 30 Dec 2008 17:01:12 -0500 From: Jeffrey Hutzelman To: Eric Rescorla , Paul Hoffman Message-ID: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Tuesday, December 30, 2008 01:39:34 PM -0800 Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> >> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >> > This is a practical application of an approach that I remember being >> > brought up during discussions about MD5 at a saag meeting some time >> > ago. I also recall someone mentioning at the time that many/most CA's >> > were already issuing certificates with random rather than sequential >> > serial numbers, which would have thwarted this particular attack. >> >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > > So it's in my deck from SAAG at IETF 62. > > http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf > > I don't know whether many or most do it. IMO everyone should. I just checked my records, and shortly after that IETF, our internal CA started issuing certificates with SHA-1 signatures and randomized serial numbers, as a direct result of that discussion. > >> > RFC 5280 does not include this advice. It is sound advice that was >> > discussed in PKIX and other venues. Perhaps a BCP is in order. >> >> Man, that is really stretching the definition of "best". >> >> For one, it is only needed in signatures that use known-attackable >> hash functions. A "best practice" in that case is to use a better >> hash function in the signature. Also, it relies on the ability of >> the software using the random number to be sure that the result is a >> positive integer in ASN.1, which seems overly optimistic. On the contrary, IMHO best practice is to take every reasonable measure to reduce the likelyhood of an attack. In my book, that means both using a better hash function _and_ using randomized serial numbers, since the latter clearly helps when the hash is broken, and hash functions may become broken over time, and before you realize it. >> If the IETF feels that adding randomization to signatures is >> important, we should define randomized signature functions. I think that's a very good idea. However... > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long > time. "what he said". Incidentally, the recently reported problems with CBC mode ciphers in SSH have gotten me to thinking that in some situations, a single REQUIRED algorithm isn't enough, because if something goes wrong and you have to abandon that algorithm in a hurry, operators may be in a position of having to choose between seriously compromising either security or interoperability. In the case of usages like certificates where no live negotiation is possible and implementations may have to interoperate over a long period of time, I believe additional care is necessary. For example, I think it would be a good idea to define a composite signature function which uses more than one hash computed independently. This would likely make some attacks harder, but more importantly, it means that as long as at least one of the underlying hashes is strong enough, the signature is still usable. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:02:33 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240F628C287; Tue, 30 Dec 2008 14:02:33 -0800 (PST) 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 201943A6403 for ; Tue, 30 Dec 2008 14:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AeRGiOgblXR4 for ; Tue, 30 Dec 2008 14:02:30 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 0CB2C3A69A0 for ; Tue, 30 Dec 2008 14:02:29 -0800 (PST) Received: (qmail 12655 invoked by uid 0); 30 Dec 2008 22:02:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:02:12 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 16:33:19 -0500 To: Paul Hoffman From: Russ Housley In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Message-Id: <20081230220230.0CB2C3A69A0@core3.amsl.com> Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Paul: >If the IETF feels that adding randomization to signatures is >important, we should define randomized signature functions. We could >start with NIST Draft SP 800-106 >(). >However, I think that doing so is sending the wrong message: we >should instead be encouraging the use of non-broken hash functions. This is a very different thing than a BCP that the recommends that the certificate serial number include some random bits. Russ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:02:42 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA2A28C2E6; Tue, 30 Dec 2008 14:02:42 -0800 (PST) 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 1280028C2DF for ; Tue, 30 Dec 2008 14:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 p6RTzHqq0fhP for ; Tue, 30 Dec 2008 14:02:41 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E60D728C2E6 for ; Tue, 30 Dec 2008 14:02:40 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E614A29C002; Wed, 31 Dec 2008 00:02:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F09C29C001; Wed, 31 Dec 2008 00:02:08 +0200 (IST) X-CheckPoint: {495A98AD-10000-88241DC2-7B6} Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBUM27fE029359; Wed, 31 Dec 2008 00:02:08 +0200 (IST) Message-Id: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: Yoav Nir To: "RL 'Bob' Morgan" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 31 Dec 2008 00:02:07 +0200 References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> X-Mailer: Apple Mail (2.930.3) Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >> Regardless of that, the authors of the MD5 paper are correct: trust >> anchors signed with MD5 are highly questionable as of today (well, >> actually, since they published their last paper). Hopefully, the >> maintainers of the popular trust anchor repositories (Microsoft, >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with > MD5 signatures", which is what I as an amateur take away from a > quick scan of the material. Obviously MD5 is suspect in various > ways, but does this new work lead to the conclusion that MD5-signed > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat as invalid any certificate chain that contains an MD5 (or MD2, MD4) signature" Since in the HTTPS context the relying parties are the browsers, it falls to the vendors (if Microsoft leads, everyone will follow) to, as Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not enough. You really should change the relying party to not recognize this algorithm. Otherwise, it's perfectly valid for a CA whose certificate is signed with SHA1 to sign an intermediate CA certificate with MD5 (although they usually don't do that, I hope) Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:17:19 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956C128C2E6; Tue, 30 Dec 2008 14:17:19 -0800 (PST) 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 84FD828C2E6 for ; Tue, 30 Dec 2008 14:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 flN1z0s4lOGb for ; Tue, 30 Dec 2008 14:17:17 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id A30B328C1F1 for ; Tue, 30 Dec 2008 14:17:17 -0800 (PST) Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:12:02 -0500 To: "RL 'Bob' Morgan" , Paul Hoffman From: Russ Housley In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Message-Id: <20081230221717.A30B328C1F1@core3.amsl.com> Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >>Regardless of that, the authors of the MD5 paper are correct: trust >>anchors signed with MD5 are highly questionable as of today (well, >>actually, since they published their last paper). Hopefully, the >>maintainers of the popular trust anchor repositories (Microsoft, >>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>MD2!) as soon as possible. > >This is a different claim than "CAs should stop issuing certs with >MD5 signatures", which is what I as an amateur take away from a >quick scan of the material. Obviously MD5 is suspect in various >ways, but does this new work lead to the conclusion that MD5-signed >roots are untrustworthy today? We recommended a migration (walk, don't run) away from MD2, MD4, and SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit hash values; even without the attacks, these are getting to be too small. SHA-1 has been shown to be weaker than its design goal, and the 160 bit hash value will be getting too short in a couple of years. We recommended SHA-256 while fully recognizing that NIST was starting a hash competition, and that we might recommend the winner of that competition as the successor to SHA-256. I still strongly encourage the migration to SHA-256. The use of the random bits in the serial number are insurance against similar problems being found in other hash functions. This insurance will hopefully provide time to migrate to another hash function when cryptanalysis begins to show flaws in any future hash function. Russ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:18:54 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C4128C2F3; Tue, 30 Dec 2008 14:18:53 -0800 (PST) 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 33FBB28C2F3 for ; Tue, 30 Dec 2008 14:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 3HKDN8+FW6sP for ; Tue, 30 Dec 2008 14:18:52 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3DABF28C2DF for ; Tue, 30 Dec 2008 14:18:52 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 48BD350822; Tue, 30 Dec 2008 14:35:00 -0800 (PST) Date: Tue, 30 Dec 2008 14:34:59 -0800 From: Eric Rescorla To: "Timothy J. Miller" In-Reply-To: <495A9B44.1010201@mitre.org> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081230223500.48BD350822@romeo.rtfm.com> Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At Tue, 30 Dec 2008 16:05:56 -0600, Timothy J. Miller wrote: > > [1 ] > Eric Rescorla wrote: > > At Tue, 30 Dec 2008 12:53:06 -0800, > > Paul Hoffman wrote: > > >> Your recollection may be off. I believe I was the person who brought > >> up the serial number hack at the mic, and I'm pretty sure I said > >> "some", not "many" (and certainly not "most"!). When I looked at a > >> handful of popular CAs earlier this week, I only found a few who are > >> using randomization in their serial numbers. > > > I don't know whether many or most do it. IMO everyone should. > > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. > > Why presign? Because for a large network with varying levels of > support, it may be easier to move around sets of pre-produced responses > to distributed keyless OCSP responders than to guarantee connectivity to > a keyed OCSP service. > > Why presign batches rather than individual responses? Because for a > large PKI the response pre-production time can exceed the CRL update > frequency. I'm not sure I understand the issue here, but they don't actually have to be totally randomized. You could use a PRF so they were predictable to the CA. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:30:45 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A89328C2F8; Tue, 30 Dec 2008 14:30:45 -0800 (PST) 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 AAE3F28C2F8 for ; Tue, 30 Dec 2008 14:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QOx1LX+kUeqh for ; Tue, 30 Dec 2008 14:30:43 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 38A2028C2F6 for ; Tue, 30 Dec 2008 14:30:43 -0800 (PST) Received: (qmail 24294 invoked by uid 0); 30 Dec 2008 22:23:45 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:23:45 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:23:33 -0500 To: Eric Rescorla From: Russ Housley In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> Mime-Version: 1.0 Message-Id: <20081230223043.38A2028C2F6@core3.amsl.com> Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org >I'm not sure I understand the issue here, but >they don't actually have to be totally randomized. You could use a >PRF so they were predictable to the CA. That works. This works too: the serial number could be composed of two parts, where the most significant bits are a counter and the least significant bits are randomly generated. Russ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:38:48 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8411C3A67F0; Tue, 30 Dec 2008 14:38:48 -0800 (PST) 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 043033A67F0 for ; Tue, 30 Dec 2008 14:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 8gB9b7iljC1t for ; Tue, 30 Dec 2008 14:38:46 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 25C7B3A6403 for ; Tue, 30 Dec 2008 14:38:46 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0E36550822; Tue, 30 Dec 2008 14:54:54 -0800 (PST) Date: Tue, 30 Dec 2008 14:54:53 -0800 From: Eric Rescorla To: "Timothy J. Miller" In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081230225454.0E36550822@romeo.rtfm.com> Cc: "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Here's Tim Callan from VEriSign posting about this: https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php -Ekr y _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 14:53:17 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCA428C2F6; Tue, 30 Dec 2008 14:53:17 -0800 (PST) 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 DF16628C2F6 for ; Tue, 30 Dec 2008 14:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 rKfMKXUX61xm for ; Tue, 30 Dec 2008 14:53:16 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D63253A67F0 for ; Tue, 30 Dec 2008 14:53:15 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUMr5gj000178 for ; Tue, 30 Dec 2008 22:53:05 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mBUMr5o7041411 for ; Tue, 30 Dec 2008 15:53:05 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 30 Dec 2008 16:36:12 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote: > Incidentally, the recently reported problems with CBC mode ciphers in SSH > have gotten me to thinking that in some situations, a single REQUIRED > algorithm isn't enough, because if something goes wrong and you have to > abandon that algorithm in a hurry, operators may be in a position of having > to choose between seriously compromising either security or > interoperability. +1 But note that in the case of the SSH CBC mode ciphers the vulnerable ciphers had only the cipher mode in common. The SSH vulnerability, in any case, doesn't stem from the use of CBC, but is more general, and well could have been worse, but let's ignore that for this argument. So in the SSH case one would have liked to have seen two or more REQUIRED to implement ciphers with very distinct properties. Say 3DES in CBC mode, AES in counter mode, and arcfour. Applying a principle of redundancy in RTI algorithms to symmetric key protocols is fairly simple. Applying such a principle to PKI seems rather more difficult -- it's not just hash algorithms, but pk algorithms too. Your example was to require not just the implementation of multiple hash (but not pk) algorithms, but to require the *use* of those. That makes sense to me, but it's not quite the same principle being applied to PKI as to SSH. Nico -- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 15:15:13 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464E628C305; Tue, 30 Dec 2008 15:15:13 -0800 (PST) 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 1709E28C304 for ; Tue, 30 Dec 2008 15:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.686, 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 Jq2ShH7a-UDv for ; Tue, 30 Dec 2008 15:15:11 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id EE47328C303 for ; Tue, 30 Dec 2008 15:15:10 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST) Date: Tue, 30 Dec 2008 18:14:55 -0500 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <8A695EE544FEFDB0EDE3DD1A@atlantis.pc.cs.cmu.edu> In-Reply-To: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> <20081230223612.GN1872@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams wrote: > Applying a principle of redundancy in RTI algorithms to symmetric key > protocols is fairly simple. Applying such a principle to PKI seems > rather more difficult -- it's not just hash algorithms, but pk > algorithms too. Your example was to require not just the implementation > of multiple hash (but not pk) algorithms, but to require the *use* of > those. That makes sense to me, but it's not quite the same principle > being applied to PKI as to SSH. Correct. I'm suggesting that in the case of PKI, merely having two RTI algorithms wouldn't be sufficient; at least for long-term certificates you need to actually sign using two algorithms in order to get the interoperability benefit. Validating using both isn't necessary, though it does have a benefit, in that no code or configuration changes are required to continue to be safe as long as at least one is good enough. IMHO, one of the biggest problems in the current PKI standards is that there is no ability to future-proof certificates by generating signatures with multiple algorithms. The result is that you can't start signing with a new algorithm until everyone understands it, and you can't stop accepting an old algorithm without either reissuing lots of certificates with a new one or waiting for them to expire. This means movement is very slow and we are unable to abandon a broken algorithm in a hurry. The former is poor; the latter is a disaster waiting to happen. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 15:23:28 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918AA28C304; Tue, 30 Dec 2008 15:23:28 -0800 (PST) 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 4084228C304 for ; Tue, 30 Dec 2008 15:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 c0IEgbNUC8NH for ; Tue, 30 Dec 2008 15:23:27 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 2FB3E28C20A for ; Tue, 30 Dec 2008 15:23:27 -0800 (PST) Received: (qmail 29788 invoked from network); 30 Dec 2008 23:23:40 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 30 Dec 2008 23:23:40 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:23:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Dec 2008 18:23:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclqwLMO5Ztz1GDZSjWorp7026VgfQAFJdBA References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "Paul Hoffman" , , , , Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Paul, I disagree in the matter of trust anchors, assuming you mean self-signed ones. Signatures on Trust anchors are inherently useless from security viewpoint. Thus, they could be signed using even MD4. Their security relies on protecting them from unauthorized modification. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Tuesday, December 30, 2008 3:53 PM To: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 15:26:17 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDC428C309; Tue, 30 Dec 2008 15:26:17 -0800 (PST) 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 68ED428C309 for ; Tue, 30 Dec 2008 15:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 aBSynyiUy6gb for ; Tue, 30 Dec 2008 15:26:15 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 8411A28C20A for ; Tue, 30 Dec 2008 15:26:15 -0800 (PST) Received: (qmail 29815 invoked from network); 30 Dec 2008 23:26:29 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 30 Dec 2008 23:26:29 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:26:29 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Dec 2008 18:26:04 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxZr3n+guWOOLTkmzRrRAnrk5JgAEETnQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "RL 'Bob' Morgan" , "Paul Hoffman" Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org As mentioned, self-signed roots have their own problems and hash is not one of them. They need other means to protect since signatures on them are useless. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 15:28:21 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A8628C30D; Tue, 30 Dec 2008 15:28:21 -0800 (PST) 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 D6D9D28C309 for ; Tue, 30 Dec 2008 15:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 olGTcuf4ylDs for ; Tue, 30 Dec 2008 15:28:18 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 9A7B528C30D for ; Tue, 30 Dec 2008 15:28:18 -0800 (PST) Received: (qmail 29840 invoked from network); 30 Dec 2008 23:28:32 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 30 Dec 2008 23:28:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:28:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Dec 2008 18:28:07 -0500 Message-ID: In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtAAAQJILA= References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: "Peter Hesse" , "RL 'Bob' Morgan" , "Paul Hoffman" Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Peter, Roots need not be replaced since they need protected migration and storage. Since the attack is computing pre-image, I suspect that past MD5 certificates are safe until the attack was devised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Hesse Sent: Tuesday, December 30, 2008 4:40 PM To: 'RL 'Bob' Morgan'; 'Paul Hoffman' Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 15:30:27 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B5528C312; Tue, 30 Dec 2008 15:30:27 -0800 (PST) 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 E040F28C312 for ; Tue, 30 Dec 2008 15:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 EbeRUJgFPuqQ for ; Tue, 30 Dec 2008 15:30:25 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id E95E028C20A for ; Tue, 30 Dec 2008 15:30:24 -0800 (PST) Received: (qmail 29881 invoked from network); 30 Dec 2008 23:30:38 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 30 Dec 2008 23:30:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:30:38 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Dec 2008 18:30:13 -0500 Message-ID: In-Reply-To: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqylLTk2EWxsuuQ1C7rI9Jvd/JmAADAnAQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: "Santosh Chokhani" To: "Yoav Nir" , "RL 'Bob' Morgan" Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Let us leave the trust anchors alone. Your challenge of protecting trust anchors does not change even if you use SHA 512 or next generation hash function yet to be determined. -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, December 30, 2008 5:02 PM To: RL 'Bob' Morgan Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate >> Regardless of that, the authors of the MD5 paper are correct: trust >> anchors signed with MD5 are highly questionable as of today (well, >> actually, since they published their last paper). Hopefully, the >> maintainers of the popular trust anchor repositories (Microsoft, >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with > MD5 signatures", which is what I as an amateur take away from a > quick scan of the material. Obviously MD5 is suspect in various > ways, but does this new work lead to the conclusion that MD5-signed > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat as invalid any certificate chain that contains an MD5 (or MD2, MD4) signature" Since in the HTTPS context the relying parties are the browsers, it falls to the vendors (if Microsoft leads, everyone will follow) to, as Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not enough. You really should change the relying party to not recognize this algorithm. Otherwise, it's perfectly valid for a CA whose certificate is signed with SHA1 to sign an intermediate CA certificate with MD5 (although they usually don't do that, I hope) Email secured by Check Point _______________________________________________ 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 saag-bounces@ietf.org Tue Dec 30 15:40:51 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7005A28C31B; Tue, 30 Dec 2008 15:40:51 -0800 (PST) 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 3359D28C31A for ; Tue, 30 Dec 2008 15:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 klESOfBIOsva for ; Tue, 30 Dec 2008 15:40:48 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 0829028C2F6 for ; Tue, 30 Dec 2008 15:40:47 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 13so351051fge.41 for ; Tue, 30 Dec 2008 15:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8= Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 18:40:36 -0500 From: "Hugo Krawczyk" To: "Eric Rescorla" In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> MIME-Version: 1.0 References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> X-Google-Sender-Auth: 51d21de5a352475d Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: multipart/mixed; boundary="===============0993061957==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============0993061957== Content-Type: multipart/alternative; boundary="----=_Part_143378_5086089.1230680436411" ------=_Part_143378_5086089.1230680436411 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else, Paul said > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (< http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. and Eric responded > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long time. I believe that the best answer to the above arguments regarding the use of randomized hashing vs. the "patch" of using random SNs is given by Sotirov et al, the cryptanalysts that carried out the remarkable MD5-certificate attack (see their website). They say: *We do note however that this use of randomness in the serial number is a workaround, made possible by lucky choices in the X.509 standard. It is not a bad idea in general to add randomness to a hash input when a possible attacker is able to choose the input. A much more reliable, since designed, solution is to use randomized hashing, see [HK]. Such a solution introduces randomization as a "mode of operation" for hash functions, which is a much more fundamental approach to the problem than relying on features that happen to be present in existing standards for non-security reasons, or for no reason at all.* In this light, I disagree with Paul's statement: > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. The two things are not exclusive. We should do BOTH: Adopt a randomized hashing technique (as a mode of operation for hash functions) and continue our quest for better hash functions. We must aim at the best possible hash function, but we cannot guarantee its security in the long term. As stated in the above text by Sotirov et al, randomized hashing is a more fundamental (I would call it "infrastructural") approach. It strengthens digital signatures with any hash function and for any digital signature application, not just certificates. Let's take the example of HMAC: Its development in mid-90's was motivated to a large extent by the weaknesses found in MD5 by Dobbertin and others. If we took the approach of "let's use a better hash function" we should have adopted the key-append method MAC(K,X) = SHA1(X||K) which used SHA1 for which there was ample belief that it was a very good collision resistant hash function. However, had we done that, we would now have a broken MAC since the above design breaks with collisions on the underlying hash function. I believe that the responsible course of action for the IETF and particularly SAAG is to adopt the standardization process started by NIST with http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf and create a deployment path that could accommodate a randomized hashing approach as a mode of operation. This includes the consideration of randomized hashing in protocol changes and new protocol design that support algorithm agility. No one in the world will think that by doing that we should keep using MD5, or not pay attention to NIST's hash competition, or should stop from moving to SHA2. The just-published attack indicates that it is time that we take seriously our digital signatures, and randomized hashing is the best long-term insurance we know against future collision vulnerabilities. You can find more details on the specific randomized hashing approach behind NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/ In particular, some of the documents in that site provide some guidance regarding implementation and deployment issues (it also includes a now-expired internet draft). Hugo ------=_Part_143378_5086089.1230680436411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else,

Paul said

    >
    > If the IETF feels that adding randomization to signatures is
    > important, we should define randomized signature functions. We could
    > start with NIST Draft SP 800-106
    > (<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However,
    > I think that doing so is sending the wrong message: we should
    > instead be encouraging the use of non-broken hash functions.

and Eric responded

   >  I certainly agree we should be encouraging the use of non-broken hash
   >  functions. However, randomizing the SN seems like very cheap backward
   >  compatible insurance against the fact that that's going to take a long time.


I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov et
al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

  We do note however that this use of randomness in the serial number is a
  workaround, made possible by lucky choices in the X.509 standard. It is not a
  bad idea in general to add randomness to a hash input when a possible attacker
  is able to choose the input. A much more reliable, since designed, solution is
  to use randomized hashing, see [HK]. Such a solution introduces randomization
  as a "mode of operation" for hash functions, which is a much more fundamental
  approach to the problem than relying on features that happen to be present in
  existing standards for non-security reasons, or for no reason at all.

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:
Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,
randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have
adopted the key-append method
  MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function.  However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the
underlying hash function.

I believe that the responsible course of action for the IETF and particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf
and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of randomized
hashing in protocol changes and new protocol design that support algorithm
agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving to
SHA2.

The just-published attack indicates that it is time that we take seriously our
digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/
In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411-- --===============0993061957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============0993061957==-- From saag-bounces@ietf.org Tue Dec 30 15:46:41 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D073A68D1; Tue, 30 Dec 2008 15:46:41 -0800 (PST) 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 D51563A68C9 for ; Tue, 30 Dec 2008 15:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 KIr11T9RbY1B for ; Tue, 30 Dec 2008 15:46:39 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 0564328C321 for ; Tue, 30 Dec 2008 15:46:02 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNjjIx018330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:45:46 -0500 (EST) Date: Tue, 30 Dec 2008 18:45:45 -0500 From: Jeffrey Hutzelman To: Santosh Chokhani , Peter Hesse , "RL 'Bob' Morgan" , Paul Hoffman Message-ID: <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani wrote: > Since the attack is computing pre-image, I suspect that past MD5 > certificates are safe until the attack was devised. The attack does _not_ involve computing a preimage; it involves computing a colliding pair one of which has a prefix which is predictable but not controllable, followed by a controllable component consisting of some minimum number of bits followed by at least three aligned message blocks. What makes existing certificates safe is that there are no known preimage attacks against MD5, couple with limitations of the technique used to construct the colliding pair. However, there is a limit to how "safe" existing certificates are, because the attack does not require anything that was not known 3-4 years ago. The only change is that with the latest techniques for computing collisions, it is possible to do so in a short enough time to be able to predict the validity and serial number that will be used by the issuer with fairly high probability. -- Jeff _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Dec 30 17:50:09 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547DC3A69B7; Tue, 30 Dec 2008 17:50:09 -0800 (PST) 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 AB4C83A69B7 for ; Tue, 30 Dec 2008 17:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, 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 ajx457X6i17H for ; Tue, 30 Dec 2008 17:50:08 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id B598A3A693D for ; Tue, 30 Dec 2008 17:50:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C6E079D3C9; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ47zQCpU9p7; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF5B69D3C8; Wed, 31 Dec 2008 14:20:44 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EEEE1BE4002; Wed, 31 Dec 2008 14:20:40 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LHplH-0006Xw-V6; Wed, 31 Dec 2008 14:20:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: paul.hoffman@vpnc.org, pmhesse@geminisecurity.com, rlmorgan@washington.edu In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> Message-Id: Date: Wed, 31 Dec 2008 14:20:39 +1300 Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 01:54:24 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767333A6923; Wed, 31 Dec 2008 01:54:24 -0800 (PST) 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 0F77D3A6923 for ; Wed, 31 Dec 2008 01:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 a9TXF4AF83oF for ; Wed, 31 Dec 2008 01:54:22 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id F42073A6880 for ; Wed, 31 Dec 2008 01:54:21 -0800 (PST) Received: (qmail 936 invoked from network); 31 Dec 2008 08:07:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 08:07:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 08:07:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 03:07:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: Aclq5ghrPG8EOOIcREilhQIvujxQYwAOEaVA References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: , , , Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org One would think we want to start using SHA-1 or even SHA256 (assuming client vendors implement SHA256 ASAP) and ask the CAs emanating from commercial roots to perform responsible I&A before issuing certificates. It will also help if the client side certificate policy processing became more of a norm. But, all of this is probably expecting too much. My fear is that expecting any of this is also too much. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Peter Gutmann Sent: Tuesday, December 30, 2008 8:21 PM To: paul.hoffman@vpnc.org; pmhesse@geminisecurity.com; rlmorgan@washington.edu Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 06:49:00 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A103A69AC; Wed, 31 Dec 2008 06:49:00 -0800 (PST) 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 AC4513A69AC for ; Wed, 31 Dec 2008 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 DJFK0M--xKlH for ; Wed, 31 Dec 2008 06:48:58 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id E09F53A685E for ; Wed, 31 Dec 2008 06:48:58 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BFE4650822; Wed, 31 Dec 2008 07:05:05 -0800 (PST) Date: Wed, 31 Dec 2008 07:05:05 -0800 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) In-Reply-To: References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081231150505.BFE4650822@romeo.rtfm.com> Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, pmhesse@geminisecurity.com, ietf-pkix@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At Wed, 31 Dec 2008 14:20:39 +1300, Peter Gutmann wrote: > > "Peter Hesse" writes: > > >Ceasing the issuance of certificates with MD5 used in the signature doesn't > >solve the problem of the certificates that have already been issued and are > >still out there, any number of which may be rogue. > > > >Replacing, or marking as untrusted all root certificates which have any > >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in > >the signature could have tremendous undesirable impact and be an untenable > >solution. > > I hate to be the one to point to the elephant in the room (well OK, I don't > hate it, it's rather fun actually) but you need to keep this in perspective: > one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks > have no problems at all obtaining certs from commercial CAs using stolen > identities and credentials for pretty much any use they want. The current MD5 > attack is very cool but there's no need to worry about bad guys doing much > with it because it's much, much easier to get legitimate CA-issued certs the > normal way, you buy them just like everyone else does (except that you use > someone else's credit card and identity, obviously). > > In other words, if this problem is fixed, would anyone other than security > geeks even notice? I doubt the crooks will. Well, if we're going to be pointing ot the obvious, then code signing actually seems kind of off-point as well. > 50% of IE users are not running up-to-date copies of their browser.[0] In many cases this means that the browsers have remote exploits. Why worry about AuthentiCode? -Ekr [0] http://www.techzoom.net/publications/insecurity-iceberg/index.en _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 07:48:08 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B40228C0FE; Wed, 31 Dec 2008 07:48:08 -0800 (PST) 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 818853A68E5 for ; Wed, 31 Dec 2008 07:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 LAf-fxWLPYMY for ; Wed, 31 Dec 2008 07:48:06 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 2D4883A69D7 for ; Wed, 31 Dec 2008 07:48:06 -0800 (PST) Received: (qmail 3243 invoked from network); 31 Dec 2008 15:21:36 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 15:21:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:21:36 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 10:21:12 -0500 Message-ID: In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrWwxnY5KUcnr6RkKSgCgRHyNxcgAADcag References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org We are simply not vigilant enough. This issue has been on our plate since 2004. SHA-1 is next and neither the client side vendors nor the big Enterprises have pushed to move to SHA-256. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org] Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser forum guidelines for EV certs allows (but recommends against) MD5 until 2010. The spot check of EV issuers I did yesterday didn't turn up anyone actually using MD5, but I didn't have all of 'em available. -- Tim _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 07:49:19 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB08028C101; Wed, 31 Dec 2008 07:49:19 -0800 (PST) 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 B78B228C101 for ; Wed, 31 Dec 2008 07:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 ztSUxFBdWJaQ for ; Wed, 31 Dec 2008 07:49:18 -0800 (PST) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id 96D1428C0F9 for ; Wed, 31 Dec 2008 07:49:18 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KCQ006QSZXIGSE5@vms173001.mailsrvcs.net> for saag@ietf.org; Wed, 31 Dec 2008 09:48:59 -0600 (CST) Date: Wed, 31 Dec 2008 10:48:54 -0500 From: RJ Atkinson In-reply-to: To: saag@ietf.org Message-id: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: Cc: cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org [Distribution trimmed slightly to reduce cross-posting and improve SNR.] On 30 Dec 2008, at 20:20, Peter Gutmann wrote: > The current MD5 attack is very cool but there's no need to worry about > bad guys doing much with it because it's much, much easier to get > legitimate CA-issued certs the normal way, you buy them just like > everyone else does (except that you use someone else's credit card > and identity, obviously). Two thoughts: 1) Protocol Issues The IETF ought to be thinking about a wide range of IETF protools in the same way that Peter thinks about CA security issues above. For some IETF protocols, for example all of the IGP authentication extensions (excepting RFC-2154, AFAICT), active non-cryptographic attacks are feasible (if not yet seen in the deployed world, AFAICT) that are much easier than *any* cryptographic attack. Again, and only by way of example, RFC-4822 discusses some of these that are specific to RIPv2 authentication. For protocols where non-cryptographic attacks are feasible AND are lower cost than a cryptographic attack, really it does not make much difference what cryptographic algorithm gets deployed by a user -- and the IETF's focus should be on improving the underlying authentication mechanism BEFORE worrying about which cryptographic algorithms are being deployed. Attackers are generally both smart and lazy, so they won't waste time on an expensive cryptographic attack when a lower effort non-cryptographic attack exists. 2) Hash algorithm analysis It would be very helpful if a *set* of mathematicians/cryptographers could jointly put together a summary of the known attacks on all the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, SHA-2, others), *including references to the published literature*. Ideally, this analysis would also include discussion of whether those attacks apply for those same algorithms when used in the modes employed by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5 or RIPv2 MD5, HMAC-Hash, and so forth). This would be most useful to have as an Informational RFC, and SOON, so that IETF WGs could have some "consensus" document to refer to -- and to cite explicitly -- if any IETF WGs decide to make hash algorithm recommendations or decisions. I don't understand IRTF process details perfectly, but perhaps the CFRG chairs might undertake creating such a document as a near-term official CFRG group project. Yours, Ran rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 08:04:55 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9514728C0F7; Wed, 31 Dec 2008 08:04:55 -0800 (PST) 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 A116328C0F7 for ; Wed, 31 Dec 2008 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 aehK6YOniXPG for ; Wed, 31 Dec 2008 08:04:54 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id C034E3A68E5 for ; Wed, 31 Dec 2008 08:04:53 -0800 (PST) Received: (qmail 3140 invoked from network); 31 Dec 2008 15:05:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 15:05:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:05:04 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 10:04:40 -0500 Message-ID: In-Reply-To: <495B84F0.3030506@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclrWAfbgnf2g3ujTbSdpg9MXzs4IAAANDWw References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> <495B84F0.3030506@mitre.org> From: "Santosh Chokhani" To: , , , Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Mini CRL are not a standard. That said, using implementators agreement (based on whether high order to low order bits are true serial number) one bit per certificate can be assigned and the random prefix or appendage to the serial number ignored. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 9:43 AM To: Russ Housley Cc: Eric Rescorla; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Russ Housley wrote: > >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. > > That works. This works too: the serial number could be composed of > two parts, where the most significant bits are a counter and the > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 08:26:38 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988E43A6830; Wed, 31 Dec 2008 08:26:38 -0800 (PST) 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 DD08028C0FD for ; Wed, 31 Dec 2008 08:26:37 -0800 (PST) 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=[AWL=0.000, 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 lbeDyGUNuF4T for ; Wed, 31 Dec 2008 08:26:37 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 98BE03A6767 for ; Wed, 31 Dec 2008 08:26:36 -0800 (PST) Received: by bwz14 with SMTP id 14so18608072bwz.13 for ; Wed, 31 Dec 2008 08:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xfVGLu8JyEH7CorwhDmx3dldAusuRq0jJy3tNJ5JfS4=; b=mTwSjbc270BNFsdislvPFF++lQJiG3JgN/u++ioxeWyk4l8muE5OSNtjkooc9D4rjk Qbj2zbgXTIBQUP9AI+qbNHpQMH/mXTnFTxMbbjU4rpNc8FbFb9XiVrqxgipSLrHQqAqb Awtxb2rSupBFQ81h6fz3Z/Ew/ATDeHWSjBxIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hLNlJ4g7pldQo6xcQ+xz9I1zF1hv6z/CQ5KAf1N4fSXeiSFAL1Ka96yywYprX+Yl3S 1Mvw1znc15MVc3oslDbUYb6xoVBW+TR7jOy9LV9cqirQqjnd+gPczY8cGNbvgs1w8LTP w6MkzLUpycEQmJzzjcmBDflitMkcJ2i7PR3bs= Received: by 10.181.219.15 with SMTP id w15mr6096199bkq.90.1230740783820; Wed, 31 Dec 2008 08:26:23 -0800 (PST) Received: by 10.180.209.3 with HTTP; Wed, 31 Dec 2008 08:26:23 -0800 (PST) Message-ID: <77ead0ec0812310826t54a69797ie9f9e5d05503fdad@mail.gmail.com> Date: Wed, 31 Dec 2008 08:26:23 -0800 From: "Vishwas Manral" To: "RJ Atkinson" In-Reply-To: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> MIME-Version: 1.0 Content-Disposition: inline References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi, I agree with Ran on the need for some document which states the requirements/ restrictions for each cryptographic algorithms for different functions. These can then be mapped appropriately into the respective protocols by the WG's. Thanks, Vishwas > On 30 Dec 2008, at 20:20, Peter Gutmann wrote: >> >> The current MD5 attack is very cool but there's no need to worry about >> bad guys doing much with it because it's much, much easier to get >> legitimate CA-issued certs the normal way, you buy them just like >> everyone else does (except that you use someone else's credit card >> and identity, obviously). > > > Two thoughts: > > 1) Protocol Issues > > The IETF ought to be thinking about a wide range of IETF protools > in the same way that Peter thinks about CA security issues above. > > For some IETF protocols, for example all of the IGP authentication > extensions (excepting RFC-2154, AFAICT), active non-cryptographic > attacks are feasible (if not yet seen in the deployed world, AFAICT) > that are much easier than *any* cryptographic attack. Again, and > only by way of example, RFC-4822 discusses some of these that are > specific to RIPv2 authentication. > > For protocols where non-cryptographic attacks are feasible AND > are lower cost than a cryptographic attack, really it does not make > much difference what cryptographic algorithm gets deployed by a user > -- and the IETF's focus should be on improving the underlying authentication > mechanism BEFORE worrying about which cryptographic > algorithms are being deployed. > > Attackers are generally both smart and lazy, so they won't waste > time on an expensive cryptographic attack when a lower effort > non-cryptographic attack exists. > > > 2) Hash algorithm analysis > > It would be very helpful if a *set* of mathematicians/cryptographers > could jointly put together a summary of the known attacks on all > the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, > SHA-2, others), *including references to the published literature*. > > Ideally, this analysis would also include discussion of whether those > attacks apply for those same algorithms when used in the modes employed > by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5 > or RIPv2 MD5, HMAC-Hash, and so forth). > > This would be most useful to have as an Informational RFC, > and SOON, so that IETF WGs could have some "consensus" document > to refer to -- and to cite explicitly -- if any IETF WGs decide > to make hash algorithm recommendations or decisions. > > I don't understand IRTF process details perfectly, but perhaps > the CFRG chairs might undertake creating such a document as a > near-term official CFRG group project. > > Yours, > > Ran > rja@extremenetworks.com > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 09:49:32 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2573A6A8F; Wed, 31 Dec 2008 09:49:32 -0800 (PST) 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 CA6C83A6A88 for ; Wed, 31 Dec 2008 09:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Pr1-GcUt3umZ for ; Wed, 31 Dec 2008 09:49:31 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id C2F533A69D2 for ; Wed, 31 Dec 2008 09:49:30 -0800 (PST) Received: (qmail 4143 invoked from network); 31 Dec 2008 17:49:43 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 17:49:43 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 17:49:42 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 12:49:19 -0500 Message-ID: In-Reply-To: <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrbxGYQEV5PuJJS2Ozj2K2iPFeGAAANo4w References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> From: "Santosh Chokhani" To: "Richard Graveman" Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Rich, The order in which you put things below, do you mean that hash used to sign a root certificate is a big problem, little problem, or no problem? -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Richard Graveman Sent: Wednesday, December 31, 2008 12:42 PM To: RJ Atkinson Cc: cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Ran, > It would be very helpful if a *set* of mathematicians/cryptographers > could jointly put together a summary of the known attacks on all > the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, > SHA-2, others), *including references to the published literature*. For an expert, authoritative, and incredibly up-to-date tutorial on the state of hash functions, go to http://www.inscrypt.cn/, get the invited talks, and see the one by Preneel. If the intro material is boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not quite in the same boat. For full papers, see IACR eprints 2008/391 for MD5, 2008/469 for SHA-1, and 2006/187 for HMAC with these. Follow the references therein. I avoided sources that cost money to get to, etc. Unfortunately, the ways cryptologists look at these things and the ways the IETF uses them are not always the same, so there is more work to do. Suffice it to say, for a start, there is a big difference between, say: 1. An HMAC based on a fresh key used by IPsec of TLS for a few minutes. 2. An HMAC based on a key stuck in a router and keft there for months or years. 3. A hash used to sign an email. 4. A hash use to sign a root certificate. Rich Graveman _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 10:03:27 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482763A68FD; Wed, 31 Dec 2008 10:03:27 -0800 (PST) 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 08FF83A68FD for ; Wed, 31 Dec 2008 10:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 51EUOeN6nSUc for ; Wed, 31 Dec 2008 10:03:25 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 0EB9E3A68DC for ; Wed, 31 Dec 2008 10:03:24 -0800 (PST) Received: (qmail 4249 invoked from network); 31 Dec 2008 18:03:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 18:03:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:03:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 13:03:13 -0500 Message-ID: In-Reply-To: <495BB0B9.9000807@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrcaZvjthE5F+NRLKwI78nj+9Z5AAACsDQ References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> From: "Santosh Chokhani" To: "Mike" , Cc: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Private EKU could cause problems if EKU is not otherwise present in the certificate. The certificate may not be usable for intended purpose. Not all clients may recognize "any key purpose" as intended by 5280. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Mike Sent: Wednesday, December 31, 2008 12:50 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. > > Mike _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 10:24:02 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D393A6A01; Wed, 31 Dec 2008 10:24:02 -0800 (PST) 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 6AE383A6A01 for ; Wed, 31 Dec 2008 10:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 R1OFgVMw-Rl5 for ; Wed, 31 Dec 2008 10:24:00 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 8A39A3A69F1 for ; Wed, 31 Dec 2008 10:24:00 -0800 (PST) Received: (qmail 4386 invoked from network); 31 Dec 2008 18:24:12 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 18:24:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:24:12 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 13:23:49 -0500 Message-ID: In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdI9/sOJPqIrSRxWmhrDCQYi/6wAADprw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> From: "Santosh Chokhani" To: "Dr Stephen Henson" , Cc: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org I am a bit concerned about random goo when random goo is one of the things the attacker uses to cause collision. This may limit human or machine's ability to discern mischief. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dr Stephen Henson Sent: Wednesday, December 31, 2008 1:12 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > Or add a non-critical extension with some randomness in it... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 10:50:27 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657A628C10B; Wed, 31 Dec 2008 10:50:27 -0800 (PST) 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 4C3AF3A6A00 for ; Wed, 31 Dec 2008 10:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 2MLM7r4SfqOf for ; Wed, 31 Dec 2008 10:50:25 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 577233A68DC for ; Wed, 31 Dec 2008 10:50:25 -0800 (PST) Received: (qmail 4597 invoked from network); 31 Dec 2008 18:50:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 18:50:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:50:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 13:50:13 -0500 Message-ID: In-Reply-To: <495BBB5D.40507@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdpWRZ2DsZT93SYeylkbr3Wg+mAAAUebw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: ietf-pkix@imc.org, Dr Stephen Henson , cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org These things need to be thought through. If all the CAs did this, it might work. But, what if the client side was looking for junk in the certificate as evidence of collision? Also, client will not enforce this. So, if you are relying on CAs, why not ask them to switch to SHA-1 as opposed to adding more software to the CA. SHA-1 is purely a configuration item for the CA deployments. I just find that all three mail lists are getting work out and real message and analysis is getting lost. For example, folks are still posting misinformation that self-signed roots have a hash problem. Signatures on self-signed roots are gratuitous from security viewpoint. So, we do not want to cry wolf and undertaken replacing roots which will be a humongous waste to time and money. Signatures and hence hash used to sign these do not matter. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org] Sent: Wednesday, December 31, 2008 1:35 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats chosen prefix attacks as a class. -- Tim _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 11:03:22 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679443A6A8C; Wed, 31 Dec 2008 11:03:22 -0800 (PST) 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 E0CDE28C10F for ; Wed, 31 Dec 2008 11:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 JaUj5FUiEivE for ; Wed, 31 Dec 2008 11:03:20 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 885B728C110 for ; Wed, 31 Dec 2008 11:03:20 -0800 (PST) Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 18:56:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:56:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 13:56:27 -0500 Message-ID: In-Reply-To: <495BBFC7.4070405@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclreTiLOa9qi39USCibRTE4UToJHQAABQ1A References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> <495BBFC7.4070405@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: ietf-pkix@imc.org, Dr Stephen Henson , cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org You have some time there and work with client vendors to implement SHA-256 and next generation SHA. I would support a random value extension if clients checked for it. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org] Sent: Wednesday, December 31, 2008 1:54 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject to a similar collision generation attack, and the presence of unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 11:14:49 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DE73A69AC; Wed, 31 Dec 2008 11:14:49 -0800 (PST) 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 3A9413A69AC for ; Wed, 31 Dec 2008 11:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 GcztY-TAdIZU for ; Wed, 31 Dec 2008 11:14:47 -0800 (PST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 154903A696F for ; Wed, 31 Dec 2008 11:14:46 -0800 (PST) Received: (qmail 4789 invoked from network); 31 Dec 2008 19:14:59 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 31 Dec 2008 19:14:59 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 19:14:59 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Dec 2008 14:14:35 -0500 Message-ID: In-Reply-To: <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrbxGYQEV5PuJJS2Ozj2K2iPFeGAADBZ0w References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> From: "Santosh Chokhani" To: "Richard Graveman" Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Rich, As your private e-mail states that item 4 below you see as most dangerous. That is not so. The self-signed root and hash used to sign that root is not relevant to security since the signature on self-signed certificates is gratuitous. We do not want the community to undertake a major effort that is not required at all and does nothing for security. That said, one of the techniques (which is not a standardized one, but a commercial practice) is to provide hash of the root certificate in a secure out of band (e.g., manually) to verify the roots. This mechanism to compute the hash on the entire signed root certificate for out of band trust establishment should be at least SHA-1 today and changed when SHA-256 or new hash are widely deployed on the clients. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Richard Graveman Sent: Wednesday, December 31, 2008 12:42 PM To: RJ Atkinson Cc: cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Ran, > It would be very helpful if a *set* of mathematicians/cryptographers > could jointly put together a summary of the known attacks on all > the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1, > SHA-2, others), *including references to the published literature*. For an expert, authoritative, and incredibly up-to-date tutorial on the state of hash functions, go to http://www.inscrypt.cn/, get the invited talks, and see the one by Preneel. If the intro material is boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not quite in the same boat. For full papers, see IACR eprints 2008/391 for MD5, 2008/469 for SHA-1, and 2006/187 for HMAC with these. Follow the references therein. I avoided sources that cost money to get to, etc. Unfortunately, the ways cryptologists look at these things and the ways the IETF uses them are not always the same, so there is more work to do. Suffice it to say, for a start, there is a big difference between, say: 1. An HMAC based on a fresh key used by IPsec of TLS for a few minutes. 2. An HMAC based on a key stuck in a router and keft there for months or years. 3. A hash used to sign an email. 4. A hash use to sign a root certificate. Rich Graveman _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Dec 31 11:50:14 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4749D3A6A1D; Wed, 31 Dec 2008 11:50:14 -0800 (PST) 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 16AA43A6A00 for ; Wed, 31 Dec 2008 11:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 CFEjGZok6wlx for ; Wed, 31 Dec 2008 11:50:13 -0800 (PST) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id E1B4C3A6808 for ; Wed, 31 Dec 2008 11:50:12 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms173005.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KCR00A7HB2UXPN5@vms173005.mailsrvcs.net> for saag@ietf.org; Wed, 31 Dec 2008 13:49:46 -0600 (CST) Date: Wed, 31 Dec 2008 14:49:41 -0500 From: RJ Atkinson In-reply-to: To: saag@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v930.3) X-Mailer: Apple Mail (2.930.3) References: <7E552E3F-C85A-4F0E-AC3E-879720A1E55F@extremenetworks.com> <45c8c21a0812310941v4469114ctdbe284ea0cbc6d35@mail.gmail.com> Cc: cfrg@irtf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org On 31 Dec 2008, at 14:14, Rich Graveman wrote: > For an expert, authoritative, and incredibly up-to-date tutorial on > the state of hash functions, go to http://www.inscrypt.cn/, get the > invited talks, and see the one by Preneel. If the intro material is > boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not > quite in the same boat. Those talk about the hash functions generally, but they do not really address the question specifically *as such functions are actually employed by some number of IETF protocols*. (And just to be clear, I'm thinking quite broadly -- well beyond the narrow realm of hashes as used by certificates.) A collision attack on some hash function f() might or might not be an issue if f() is used in any of several different modes, for example. > Unfortunately, the ways cryptologists look at these things and the > ways the IETF uses them are not always the same, so there is more work > to do. Right. What I was asking for, specifically, was analysis that considered the various ways that various IETF protocols actually use them -- not abstract concerns that might or might not relate to the way they are actually used by various IETF protocols. ("ways" means not just deployment model, but also the mode of operation). One could easily imagine, for example, that some uses of these algorithms might be viewed as entirely fine, with other uses being clearly unsuitable, with a wide range of possibilities in between those two extremes. It is this specific analysis that is missing, needed, and would be most valuable to various IETF WGs -- if available in a public document (ideally an Informational RFC, developed jointly as a public group effort, such as by the IRTF CFRG, and including full references to the public literature). My apologies for somehow being unclear in my earlier note. Thanks, Ran rja@extremenetworks.com _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag