From rpsec-bounces@ietf.org Sat Aug 06 11:01:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1QB3-0003o6-VL; Sat, 06 Aug 2005 11:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Pr9-0007zm-S9 for rpsec@megatron.ietf.org; Sat, 06 Aug 2005 10:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26523 for ; Sat, 6 Aug 2005 10:40:57 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1QOS-0008Vt-Hj for rpsec@ietf.org; Sat, 06 Aug 2005 11:15:25 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2005 07:40:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,172,1120460400"; d="scan'208"; a="4952429:sNHT19057724" Received: from russpc (rtp-vpn3-569.cisco.com [10.82.218.60]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j76EehQm002931 for ; Sat, 6 Aug 2005 10:40:48 -0400 (EDT) Received: from [10.82.218.60] by russpc (PGP Universal service); Sat, 06 Aug 2005 10:40:48 -0500 X-PGP-Universal: processed; by russpc on Sat, 06 Aug 2005 10:40:48 -0500 Message-ID: <42F4CBE5.7020109@cisco.com> Date: Sat, 06 Aug 2005 10:40:37 -0400 From: Russ White User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Sat, 06 Aug 2005 11:01:30 -0400 Subject: [RPSEC] Minutes and Presentations from Paris are now Posted... X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here: http://www.rpsec.org Comments welcome. Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvTL8BEdu7FIVPTkEQKc7ACg1twy9dzsWbmIZ8aufnagKbLgziUAoKRW CYfj8f8lRFen96kk5zfVbut3 =eDj8 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Aug 10 01:45:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jPI-00024u-9t; Wed, 10 Aug 2005 01:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jPH-00024p-Fd for rpsec@megatron.ietf.org; Wed, 10 Aug 2005 01:45:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08492 for ; Wed, 10 Aug 2005 01:45:38 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2jxH-0002be-0H for rpsec@ietf.org; Wed, 10 Aug 2005 02:20:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Minutes and Presentations from Paris are now Posted... X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 9 Aug 2005 22:46:38 -0700 Message-ID: Thread-Topic: [RPSEC] Minutes and Presentations from Paris are now Posted... Thread-Index: AcWal/bIxUA9s/EtTaWJ/NbfSyDD4AC1ciGA From: "Vishwas Manral" To: "Russ White" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi, As I got in late for the meeting I could not take the questions myself. I had a few doubts.=20 In the sentence: - "Steve Kent: MD5 and HMAC constructs in current use not planned or valid. Current attacks not a problem for HMAC." I think it is "MD5 and SHA-1" and not "MD5 and HMAC" is that right? I agree with Richard's comment that we do not currently talk about the use of confidentiality, we could do that. Regarding Sandy's and Acee's comment, I think we need to decide what issues need we need to solve and which ones we do not need to solve. The resolution of issues will be part of another document. This is only an issues document. Thanks, Vishwas -----Original Message----- From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On Behalf Of Russ White Sent: Saturday, August 06, 2005 8:11 PM To: rpsec@ietf.org Subject: [RPSEC] Minutes and Presentations from Paris are now Posted... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here: http://www.rpsec.org Comments welcome. Russ - --=20 riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvTL8BEdu7FIVPTkEQKc7ACg1twy9dzsWbmIZ8aufnagKbLgziUAoKRW CYfj8f8lRFen96kk5zfVbut3 =3DeDj8 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Aug 10 17:12:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xsI-0006fE-3Y; Wed, 10 Aug 2005 17:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xsF-0006f4-LF for rpsec@megatron.ietf.org; Wed, 10 Aug 2005 17:12:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03957 for ; Wed, 10 Aug 2005 17:12:28 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2yQP-00066x-9T for rpsec@ietf.org; Wed, 10 Aug 2005 17:47:50 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j7ALCCDd005672; Wed, 10 Aug 2005 17:12:12 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 10 Aug 2005 16:11:59 -0400 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [RPSEC] Minutes and Presentations from Paris are now Posted... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org The minutes should say something along the lines of: Efficient BGP security ... Steve Kent: S-BGP does not call for issuing CRL or using OCSP to deal with revocation for RAs. RAs are assumed to have limited lifetimes, e.g., 1 day, and thus need not be revoked explicitly. Issues with RP Security Mechanisms ... Steve Kent: The keyed MD5 and HMAC constructs in current use are not vulnerable to the sort of hash function attacks that Russ cited in his presentation. These attacks allow someone to construct distinct bit strings that yield the same hash value, but do not allow someone to create a distinct bit string that maps to a has value chosen by someone else, much less a hash value that is chosen by someone else and that is a function of a secret key. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Aug 16 00:59:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tYI-0002Bj-Gd; Tue, 16 Aug 2005 00:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tYH-0002BY-6G for rpsec@megatron.ietf.org; Tue, 16 Aug 2005 00:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06787 for ; Tue, 16 Aug 2005 00:59:50 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4u7W-0006Bm-Sy for rpsec@ietf.org; Tue, 16 Aug 2005 01:36:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Minutes and Presentations from Paris are now Posted... X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 15 Aug 2005 22:01:05 -0700 Message-ID: Thread-Topic: [RPSEC] Minutes and Presentations from Paris are now Posted... Thread-Index: AcWd8DiV7zcqBenVQRS6y0KnITIAkAELYdtA From: "Vishwas Manral" To: "Stephen Kent" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi Steve, > Steve Kent: The keyed MD5 and HMAC constructs in current use are=20 > not vulnerable to the sort of hash function attacks that Russ cited > in his presentation. These attacks allow someone to construct distinct > bit strings that yield the same hash value, but do not allow someone=20 > to create a distinct bit string that maps to a has value chosen by=20 > someone else, much less a hash value that is chosen by someone else=20 > and that is a function of a secret key. What you are saying is that although "Birthday attacks" are possible, they may not be such a problem in the case described in the draft? I guess your concern is regarding: - "While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function",=20 which we have taken from the http://www.ietf.org/internet-drafts/draft-rja-ripv2-auth-01.txt draft. Thanks, Vishwas -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, August 11, 2005 1:42 AM To: Vishwas Manral Cc: rpsec@ietf.org Subject: RE: [RPSEC] Minutes and Presentations from Paris are now Posted... The minutes should say something along the lines of: Efficient BGP security ... Steve Kent: S-BGP does not call for issuing CRL or using OCSP to deal=20 with revocation for RAs. RAs are assumed to have limited lifetimes,=20 e.g., 1 day, and thus need not be revoked explicitly. Issues with RP Security Mechanisms ... Steve Kent: The keyed MD5 and HMAC constructs in current use are not=20 vulnerable to the sort of hash function attacks that Russ cited in=20 his presentation. These attacks allow someone to construct distinct=20 bit strings that yield the same hash value, but do not allow someone=20 to create a distinct bit string that maps to a has value chosen by=20 someone else, much less a hash value that is chosen by someone else=20 and that is a function of a secret key. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Aug 16 11:11:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5363-0007xW-4i; Tue, 16 Aug 2005 11:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5360-0007xM-If for rpsec@megatron.ietf.org; Tue, 16 Aug 2005 11:11:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17286 for ; Tue, 16 Aug 2005 11:11:18 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53fM-0003l5-0O for rpsec@ietf.org; Tue, 16 Aug 2005 11:47:53 -0400 Received: by machshav.com (Postfix, from userid 512) id E04F0FB266; Tue, 16 Aug 2005 11:11:13 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E6325FB23E; Tue, 16 Aug 2005 11:11:12 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id AA9383BFDE3; Tue, 16 Aug 2005 11:11:11 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Vishwas Manral" Subject: Re: [RPSEC] Minutes and Presentations from Paris are now Posted... In-Reply-To: Your message of "Mon, 15 Aug 2005 22:01:05 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Aug 2005 11:11:11 -0400 Message-Id: <20050816151111.AA9383BFDE3@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org In message , "Vis hwas Manral" writes: >Hi Steve, > >> Steve Kent: The keyed MD5 and HMAC constructs in current use are >> not vulnerable to the sort of hash function attacks that Russ cited >> in his presentation. These attacks allow someone to construct distinct >> bit strings that yield the same hash value, but do not allow someone >> to create a distinct bit string that maps to a has value chosen by >> someone else, much less a hash value that is chosen by someone else >> and that is a function of a secret key. >What you are saying is that although "Birthday attacks" are possible, >they may not be such a problem in the case described in the draft? > >I guess your concern is regarding: - > >"While there are no openly published attacks on that mechanism, some >reports [Dobb96a, Dobb96b] create concern about the ultimate strength of >the MD5 cryptographic hash function", >which we have taken from the >http://www.ietf.org/internet-drafts/draft-rja-ripv2-auth-01.txt draft. He's referring to Wang's attacks -- she has found collisions in MD5 and shown how to do so for SHA1. See http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ for an explanation. *But* -- the attacks don't apply to these hash functions when used as part of HMAC. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Aug 17 00:07:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5FCe-00086i-5d; Wed, 17 Aug 2005 00:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5FCc-00086d-HT for rpsec@megatron.ietf.org; Wed, 17 Aug 2005 00:06:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05434 for ; Wed, 17 Aug 2005 00:06:55 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Fm5-0000d5-I3 for rpsec@ietf.org; Wed, 17 Aug 2005 00:43:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [RPSEC] Minutes and Presentations from Paris are now Posted... Date: Tue, 16 Aug 2005 21:08:13 -0700 Message-ID: Thread-Topic: [RPSEC] Minutes and Presentations from Paris are now Posted... Thread-Index: AcWidL8Hxz2/uQsPTxqJLqF6JTj9NgAaP5xg From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi Steve B., Thanks for the link. I agree. Regarding the HMAC part, when applying the HMAC construct to MD5 or SHA-1, I agree the collision attacks can be mitigated. This is exactly what we have put in our draft.=20 However the packets are not just arbitrary bit streams. We actually check for the packet fields for validity and we also have the checksum field, so probabilities of the packet being used after collisions are even lesser. I think the collision attacks that you talk about are the same as "Birthday Attacks" where we use brute force to actually find another stream with the same message digest, right? http://mathworld.wolfram.com/BirthdayAttack.html Thanks, Vishwas -----Original Message----- From: smb@cs.columbia.edu [mailto:smb@cs.columbia.edu]=20 Sent: Tuesday, August 16, 2005 8:41 PM To: Vishwas Manral Cc: Stephen Kent; rpsec@ietf.org Subject: Re: [RPSEC] Minutes and Presentations from Paris are now Posted...=20 In message , "Vis hwas Manral" writes: >Hi Steve, > >> Steve Kent: The keyed MD5 and HMAC constructs in current use are=20 >> not vulnerable to the sort of hash function attacks that Russ cited >> in his presentation. These attacks allow someone to construct distinct >> bit strings that yield the same hash value, but do not allow someone=20 >> to create a distinct bit string that maps to a has value chosen by=20 >> someone else, much less a hash value that is chosen by someone else=20 >> and that is a function of a secret key. >What you are saying is that although "Birthday attacks" are possible, >they may not be such a problem in the case described in the draft? > >I guess your concern is regarding: - > >"While there are no openly published attacks on that mechanism, some >reports [Dobb96a, Dobb96b] create concern about the ultimate strength of >the MD5 cryptographic hash function",=20 >which we have taken from the >http://www.ietf.org/internet-drafts/draft-rja-ripv2-auth-01.txt draft. He's referring to Wang's attacks -- she has found=20 collisions in MD5 and shown how to do so for SHA1. See http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ for an explanation. *But* -- the attacks don't apply to these hash=20 functions when used as part of HMAC. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Aug 17 00:19:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5FP5-0001UG-21; Wed, 17 Aug 2005 00:19:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5FP3-0001U8-Jm for rpsec@megatron.ietf.org; Wed, 17 Aug 2005 00:19:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05979 for ; Wed, 17 Aug 2005 00:19:46 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5FyV-0000tf-TG for rpsec@ietf.org; Wed, 17 Aug 2005 00:56:29 -0400 Received: by machshav.com (Postfix, from userid 512) id 78603FB27F; Wed, 17 Aug 2005 00:19:40 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 78DD3FB266; Wed, 17 Aug 2005 00:19:39 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 0BE933BFDC5; Wed, 17 Aug 2005 00:19:38 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Vishwas Manral" Subject: Re: [RPSEC] Minutes and Presentations from Paris are now Posted... In-Reply-To: Your message of "Tue, 16 Aug 2005 21:08:13 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Aug 2005 00:19:38 -0400 Message-Id: <20050817041938.0BE933BFDC5@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org In message , "Vis hwas Manral" writes: > >However the packets are not just arbitrary bit streams. We actually >check for the packet fields for validity and we also have the checksum >field, so probabilities of the packet being used after collisions are >even lesser. > >I think the collision attacks that you talk about are the same as >"Birthday Attacks" where we use brute force to actually find another >stream with the same message digest, right? >http://mathworld.wolfram.com/BirthdayAttack.html > A collision attack is where you produce two messages, A!=B, such that H(A) = H(B). For an n-bit hash function, that should require work factor 2^(n/2). The attacks on current hash functions -- MD5 is dead from that perspective; the latest word, from CRYPTO, is that there is now a 2^63 attack on SHA-1, as compared to its design strength of 2^80 -- are quite serious. These are much better than brute force. I would not take comfort from the structure of the packets. There was a lovely talk at CRYPTO on how to find useful collisions in quite a variety of file formats. There's even been a demonstration of how to produce a certificate with two different public keys that have a collision. The bottom line is simple: if your use of a hash function is vulnerable if a collision is found, you need to replace it. If you're using MD5, you need to replace it *soon*. You *probably* have a few years for SHA1, but I have no confidence in that number. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Aug 17 01:21:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5GMo-0004pu-Iv; Wed, 17 Aug 2005 01:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5GMm-0004oU-UU for rpsec@megatron.ietf.org; Wed, 17 Aug 2005 01:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08767 for ; Wed, 17 Aug 2005 01:21:32 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5GwF-0002QX-TR for rpsec@ietf.org; Wed, 17 Aug 2005 01:58:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 16 Aug 2005 22:22:12 -0700 Message-ID: Thread-Topic: Multicast Security Thread-Index: AcWi65+mLGga/DsCTwWtWCVgOOBIgA== From: "Vishwas Manral" To: "Routing Protocol Security" X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [RPSEC] Multicast Security X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132895429==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0132895429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A2EB.6A74FA74" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A2EB.6A74FA74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Now that we are discussing issues in protocols, I had another doubt. =20 Should we consider a case where all the members of a multicast group do not trust one another? I mean when using manual keying, the way it is done right now is that any member on a multicast (broadcast) domain (for IS-IS the flooding domain is much bigger) could pose as someone else and there is no way to know the identity of the sender. =20 Do you think such attacks need to be documented too? The decision to solve or not solve such a problem is a different matter altogether (certificates etc.). =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5A2EB.6A74FA74 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Now that we are discussing issues in protocols, I had another doubt.

 

Should we consider a case where all the members of a multicast group do not trust one another? I mean when using manual = keying, the way it is done right now is that any member on a multicast (broadcast) = domain (for IS-IS the flooding domain is much bigger) could pose as someone else and = there is no way to know the identity of the = sender.

 

Do you think such attacks need to be documented too? = The decision to solve or not solve such a problem is a different matter = altogether (certificates etc.).

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C5A2EB.6A74FA74-- --===============0132895429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0132895429==-- From rpsec-bounces@ietf.org Wed Aug 17 02:51:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HlY-0005Fu-6w; Wed, 17 Aug 2005 02:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HlV-0005Fm-Cq for rpsec@megatron.ietf.org; Wed, 17 Aug 2005 02:51:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10025 for ; Wed, 17 Aug 2005 02:51:08 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/SuNa6q5ox455HJkqpaQn2QG2SBeuEfk0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5IKy-0004XL-ME for rpsec@ietf.org; Wed, 17 Aug 2005 03:27:50 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7H6nrW5009716; Wed, 17 Aug 2005 07:49:57 +0100 Date: Wed, 17 Aug 2005 07:49:53 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "Steven M. Bellovin" Subject: Re: [RPSEC] Minutes and Presentations from Paris are now Posted... In-Reply-To: <20050817041938.0BE933BFDC5@berkshire.machshav.com> Message-ID: References: <20050817041938.0BE933BFDC5@berkshire.machshav.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Wed, 17 Aug 2005, Steven M. Bellovin wrote: > I would not take comfort from the structure of the packets. There > was a lovely talk at CRYPTO on how to find useful collisions in > quite a variety of file formats. There's even been a demonstration > of how to produce a certificate with two different public keys that > have a collision. These attacks are all with fully known/controllable input (TTBOMK). The attacker constructs /both/. Further, in HMAC code, you have a secret you have to guess too. In OSPF it's 32 bits but only 28bit effectively due to how some (most?) systems allow the secret to be configured (ASCII). So you have another 28 bits you need to brute-force before you can apply your MD5 collision methods (which, to date, are /not/ for arbitrary input IIRC. you must be able to 'mould' the input to make it suit). For the likes of OSPF it would be more fruitful today to examine and revise how the 'secret' is configured and used so as to make full use of those last 4 bits of the secret. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Some people can tell what time it is by looking at the sun. But I have never been able to make out the numbers. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Aug 18 14:14:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ouH-0005xz-Mh; Thu, 18 Aug 2005 14:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ouF-0005wN-59 for rpsec@megatron.ietf.org; Thu, 18 Aug 2005 14:14:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21142 for ; Thu, 18 Aug 2005 14:14:21 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pU1-0000vU-45 for rpsec@ietf.org; Thu, 18 Aug 2005 14:51:22 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j7IIDk8h031084; Thu, 18 Aug 2005 11:13:46 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j7IIDfVR031078; Thu, 18 Aug 2005 11:13:41 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 18 Aug 2005 11:13:41 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: "Steven M. Bellovin" In-Reply-To: <20050817041938.0BE933BFDC5@berkshire.machshav.com> Message-ID: References: <20050817041938.0BE933BFDC5@berkshire.machshav.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org, Stephen Kent Subject: [RPSEC] Hash functions (was: Re: Minutes and Presentations from Paris are now Posted... ) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Wed, 17 Aug 2005, Steven M. Bellovin wrote: >> I think the collision attacks that you talk about are the same as >> "Birthday Attacks" where we use brute force to actually find another >> stream with the same message digest, right? >> http://mathworld.wolfram.com/BirthdayAttack.html > > A collision attack is where you produce two messages, A!=B, such > that H(A) = H(B). For an n-bit hash function, that should require > work factor 2^(n/2). The attacks on current hash functions -- MD5 > is dead from that perspective; the latest word, from CRYPTO, is that > there is now a 2^63 attack on SHA-1, as compared to its design > strength of 2^80 -- are quite serious. These are much better than > brute force. Given that this list is composed of people with varying levels of familiarity with cryptography and its application; and because this topic appears to be a frequent source of confusion, perhaps more clarification is warranted. Steve, below you mention "useful collsions". What I take that to mean is a collsion where message B has semantics which will match the situation in a way that is useful to an attacker. In the context of a routing protocol, I'd guess this to be a packet which is semantically valid within the protocol and but changes the outcome in a way that's adventageous to the attacker. Can you comment on how that improves the profile (or not) of these functions? For instance, I'd expect that if a PDF of my credit card bill comes every month and I'm used to the format of it (e.g. layout and logo graphics) it'd be very hard to produce a file with the same format but just some of the numbers changed. (Perhaps the analogy isn't valid, but hopefully I'm being clear in what I'm asking.) Tony > I would not take comfort from the structure of the packets. There > was a lovely talk at CRYPTO on how to find useful collisions in > quite a variety of file formats. There's even been a demonstration > of how to produce a certificate with two different public keys that > have a collision. > > The bottom line is simple: if your use of a hash function is > vulnerable if a collision is found, you need to replace it. If > you're using MD5, you need to replace it *soon*. You *probably* > have a few years for SHA1, but I have no confidence in that number. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Aug 18 14:29:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5p8u-00019S-GW; Thu, 18 Aug 2005 14:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5p8t-00019N-B1 for rpsec@megatron.ietf.org; Thu, 18 Aug 2005 14:29:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22166 for ; Thu, 18 Aug 2005 14:29:30 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pif-0001Td-NM for rpsec@ietf.org; Thu, 18 Aug 2005 15:06:31 -0400 Received: by machshav.com (Postfix, from userid 512) id 2EE38FB282; Thu, 18 Aug 2005 14:29:20 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1FBD4FB27D; Thu, 18 Aug 2005 14:29:19 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id E5E263BFFE9; Thu, 18 Aug 2005 14:29:16 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tony Tauber In-Reply-To: Your message of "Thu, 18 Aug 2005 11:13:41 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Aug 2005 14:29:16 -0400 Message-Id: <20050818182916.E5E263BFFE9@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rpsec@ietf.org, Stephen Kent Subject: [RPSEC] Re: Hash functions (was: Re: Minutes and Presentations from Paris are now Posted... ) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org In message , Tony Tauber write s: >On Wed, 17 Aug 2005, Steven M. Bellovin wrote: > >>> I think the collision attacks that you talk about are the same as >>> "Birthday Attacks" where we use brute force to actually find another >>> stream with the same message digest, right? >>> http://mathworld.wolfram.com/BirthdayAttack.html >> >> A collision attack is where you produce two messages, A!=B, such >> that H(A) = H(B). For an n-bit hash function, that should require >> work factor 2^(n/2). The attacks on current hash functions -- MD5 >> is dead from that perspective; the latest word, from CRYPTO, is that >> there is now a 2^63 attack on SHA-1, as compared to its design >> strength of 2^80 -- are quite serious. These are much better than >> brute force. > >Given that this list is composed of people with varying levels of >familiarity with cryptography and its application; and because this >topic appears to be a frequent source of confusion, perhaps more >clarification is warranted. > >Steve, below you mention "useful collsions". What I take that to mean >is a collsion where message B has semantics which will match the >situation in a way that is useful to an attacker. In the context of a >routing protocol, I'd guess this to be a packet which is semantically >valid within the protocol and but changes the outcome in a way that's >adventageous to the attacker. > >Can you comment on how that improves the profile (or not) of these >functions? For instance, I'd expect that if a PDF of my credit card >bill comes every month and I'm used to the format of it (e.g. >layout and logo graphics) it'd be very hard to produce a file with the >same format but just some of the numbers changed. >(Perhaps the analogy isn't valid, but hopefully I'm being clear in >what I'm asking.) Your definition of "useful" is almost correct, but leave room for changes to other fields in a way that isn't harmful. Your example of a PDF document is a good one, because that was one of the examples used in the talk at CRYPTO. You can generate two different versions of the PDF file, where there's text that can vary -- but its font color is set to white, so it's effectively invisible. For BGP, this is easy to do: add an attribute, with the Optional bit set to 1, and the rest of the type code set to something you're pretty sure the other side doesn't understand, and hence will ignore. (Set Transitive, Partial, and Extended Length according to taste.) The value field is then an opaque field that can be changed at will to produce the desired collision. Now -- I'm not saying this is a useful thing to do. Remember that we're talking about a collision attack, not a pre-image or second pre-image attack. (See draft-hoffman-hash-attacks-04.txt for an explanation of what these mean.) What I am saying is that you can't assume there are no problems, just because of the structured nature of the data. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Aug 18 14:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pPH-0004n7-Ad; Thu, 18 Aug 2005 14:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pPF-0004n1-Mm for rpsec@megatron.ietf.org; Thu, 18 Aug 2005 14:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22998 for ; Thu, 18 Aug 2005 14:46:24 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19sNUIJMHJe3xmZlCpk8SHT9rb1d3xNv3g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pz1-0001v3-FK for rpsec@ietf.org; Thu, 18 Aug 2005 15:23:25 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7IIj7XT003178; Thu, 18 Aug 2005 19:45:13 +0100 Date: Thu, 18 Aug 2005 19:45:07 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Tauber Subject: Re: [RPSEC] Hash functions (was: Re: Minutes and Presentations from Paris are now Posted... ) In-Reply-To: Message-ID: References: <20050817041938.0BE933BFDC5@berkshire.machshav.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Stephen Kent , "Steven M. Bellovin" X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 18 Aug 2005, Tony Tauber wrote: > functions? For instance, I'd expect that if a PDF of my credit > card bill comes every month and I'm used to the format of it (e.g. > layout and logo graphics) it'd be very hard to produce a file with > the same format but just some of the numbers changed. (Perhaps the > analogy isn't valid, but hopefully I'm being clear in what I'm > asking.) http://www.cits.rub.de/MD5Collisions/ Note however that the deviant actor must prepare /both/ inputs, and further must make use of some tricks in the format of the input to hide some of the differences from cursory inspection. In this case it's in the details of the postscript, but you could theoretically exploit similarity of glyphs in UTF-8, or, in the below example, special terminal control characters (on linux console): http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0067.html MD5 does not /yet/ appear to be vulnerable to finding a collision for a /specific/ (fixed, eg cause it's someone else's packet) message.. And even if MD5 were, you still have about 28 bits of protection due to the HMAC usage mode (the secret key which is not included in the message), which is typically the case in routing protocols (OSPF). As someone pointed out in Paris, if someone guesses your key as part of trying to attack the MD5 HMAC, then you're out of luck anyway - the attacker no longer needs to find MD5 collisions ;). IANAC, i'm just rehashing information I gleaned from others. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: It appears that PL/I (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- J. Sammet _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Aug 18 23:49:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5xtG-0000Pb-KK; Thu, 18 Aug 2005 23:49:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5xtE-0000Nw-LN for rpsec@megatron.ietf.org; Thu, 18 Aug 2005 23:49:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26443 for ; Thu, 18 Aug 2005 23:49:53 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5yT5-0002Tt-Vr for rpsec@ietf.org; Fri, 19 Aug 2005 00:27:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [RPSEC] Hash functions (was: Re: Minutes and Presentations fromParis are now Posted... ) Date: Thu, 18 Aug 2005 20:51:12 -0700 Message-ID: Thread-Topic: [RPSEC] Hash functions (was: Re: Minutes and Presentations fromParis are now Posted... ) Thread-Index: AcWkJUU/wI0y+x9sSXiDDyT3i5vePAASy8xw From: "Vishwas Manral" To: "Paul Jakma" , "Tony Tauber" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Stephen Kent , "Steven M. Bellovin" X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi Paul/ Steve/ Tony, Based on the discussion and seeing the state of "Cryptographic Algorithm Implementation Requirement" in Routing Protocols, I agree, we can change the recommendations in routing protocols (OSPF/ IS-IS/ RIP) to implement HMAC-SHA1 or HMAC-MD5 to MUST and probably MD5 to MAY. Does that sound correct? Thanks, Vishwas -----Original Message----- From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On Behalf Of Paul Jakma Sent: Friday, August 19, 2005 12:15 AM To: Tony Tauber Cc: rpsec@ietf.org; Stephen Kent; Steven M. Bellovin Subject: Re: [RPSEC] Hash functions (was: Re: Minutes and Presentations fromParis are now Posted... ) On Thu, 18 Aug 2005, Tony Tauber wrote: > functions? For instance, I'd expect that if a PDF of my credit=20 > card bill comes every month and I'm used to the format of it (e.g.=20 > layout and logo graphics) it'd be very hard to produce a file with=20 > the same format but just some of the numbers changed. (Perhaps the=20 > analogy isn't valid, but hopefully I'm being clear in what I'm=20 > asking.) http://www.cits.rub.de/MD5Collisions/ Note however that the deviant actor must prepare /both/ inputs, and=20 further must make use of some tricks in the format of the input to=20 hide some of the differences from cursory inspection. In this case=20 it's in the details of the postscript, but you could theoretically=20 exploit similarity of glyphs in UTF-8, or, in the below example,=20 special terminal control characters (on linux console): =20 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/006 7.html MD5 does not /yet/ appear to be vulnerable to finding a collision for=20 a /specific/ (fixed, eg cause it's someone else's packet) message..=20 And even if MD5 were, you still have about 28 bits of protection due=20 to the HMAC usage mode (the secret key which is not included in the=20 message), which is typically the case in routing protocols (OSPF). As someone pointed out in Paris, if someone guesses your key as part=20 of trying to attack the MD5 HMAC, then you're out of luck anyway -=20 the attacker no longer needs to find MD5 collisions ;). IANAC, i'm just rehashing information I gleaned from others. regards, --=20 Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: It appears that PL/I (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- J. Sammet _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec