potential hazards of Protect-America act
I wonder if this is on topic? <http://www.crypto.com/papers/paa-ieee.pdf> Among other things, it discusses technical hazards of the act. --Michael Dillon
Well, it could affect the equipment required, floor space, real estate cost, log retention, bandwidth requirements, equipment addressing, procedures, training, trouble desk, employee count and, probably, more. So, I would think it would affect network operations. I would suggest that it is on topic. There are business and legal hazards along with the technical hazards. Compliance with differing data privacy and retention laws are not the least of these. On Jan 29, 2008, at 3:46 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I wonder if this is on topic?
<http://www.crypto.com/papers/paa-ieee.pdf>
Among other things, it discusses technical hazards of the act.
--Michael Dillon
James R. Cutler james.cutler@consultant.com
Pretty good in the generalities, but there are few finer technical points that could be been precisely and accurately stated. One that comes to mind was the MD5 reference, another was the "50% loss" when talking about performing an optical split. Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of michael.dillon@bt.com Sent: Tuesday, January 29, 2008 2:47 PM To: nanog@nanog.org Subject: potential hazards of Protect-America act I wonder if this is on topic? <http://www.crypto.com/papers/paa-ieee.pdf> Among other things, it discusses technical hazards of the act. --Michael Dillon
On Tue, 29 Jan 2008 20:28:05 -0600 "Frank Bulk" <frnkblk@iname.com> wrote:
Pretty good in the generalities, but there are few finer technical points that could be been precisely and accurately stated. One that comes to mind was the MD5 reference, another was the "50% loss" when talking about performing an optical split.
Speaking as one of the authors, we did our best. (But what do you mean about MD5? That was taken straight from the FOIAed FBI documents, and from conversations with people in law enforcement I'm quite certain that MD5 is still used -- inappropriately! -- in sensitive places.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
I think I need to eat crow on the MD5 comment -- I was confused with SHA, which although has been attacked, is still holding up: http://www.schneier.com/blog/archives/2007/01/sha1_cracked.html Frank -----Original Message----- From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] Sent: Tuesday, January 29, 2008 9:13 PM To: frnkblk@iname.com Cc: michael.dillon@bt.com; nanog@nanog.org Subject: Re: potential hazards of Protect-America act On Tue, 29 Jan 2008 20:28:05 -0600 "Frank Bulk" <frnkblk@iname.com> wrote:
Pretty good in the generalities, but there are few finer technical points that could be been precisely and accurately stated. One that comes to mind was the MD5 reference, another was the "50% loss" when talking about performing an optical split.
Speaking as one of the authors, we did our best. (But what do you mean about MD5? That was taken straight from the FOIAed FBI documents, and from conversations with people in law enforcement I'm quite certain that MD5 is still used -- inappropriately! -- in sensitive places.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Disclaimer: I'm sitting in a meeting that is making me grumpy and this is one of my pet-peeves... I keep hearing people making the assertion that MD5 is "broken" -- this is not completely true. Yes, there have been collisions found -- yes, I can easily (and quickly) generate 2 inputs that generate the same output... What is not trivial is for you to generate another input that will generate (eg): 0x56f39544ebca88f261f2087dab3d7e61 or, given 0x56f39544ebca88f261f2087dab3d7e61 to figure out what input I provided. There was a brief flurry of media attention around the time of Vlastimil's tiunneling work saying "MD5 Broken!!!". Many people (not necessarily anyone on the list) just read the sensationalist headlines with no understanding as to what had been accomplished... As with any tool, you need to understand the capabilities and limitations before using it. Once again, this is one of those things that just pushes my buttons, sorry if I went off on a rant... W P.S: Yes thanks, I am feeling better now :-) On Jan 29, 2008, at 7:35 PM, Frank Bulk wrote:
I think I need to eat crow on the MD5 comment -- I was confused with SHA, which although has been attacked, is still holding up: http://www.schneier.com/blog/archives/2007/01/sha1_cracked.html
Frank
-----Original Message----- From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] Sent: Tuesday, January 29, 2008 9:13 PM To: frnkblk@iname.com Cc: michael.dillon@bt.com; nanog@nanog.org Subject: Re: potential hazards of Protect-America act
On Tue, 29 Jan 2008 20:28:05 -0600 "Frank Bulk" <frnkblk@iname.com> wrote:
Pretty good in the generalities, but there are few finer technical points that could be been precisely and accurately stated. One that comes to mind was the MD5 reference, another was the "50% loss" when talking about performing an optical split.
Speaking as one of the authors, we did our best. (But what do you mean about MD5? That was taken straight from the FOIAed FBI documents, and from conversations with people in law enforcement I'm quite certain that MD5 is still used -- inappropriately! -- in sensitive places.)
--Steve Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 30 Jan 2008 17:03:04 -0800 Warren Kumari <warren@kumari.net> wrote:
Disclaimer: I'm sitting in a meeting that is making me grumpy and this is one of my pet-peeves... I keep hearing people making the assertion that MD5 is "broken" -- this is not completely true. Yes, there have been collisions found -- yes, I can easily (and quickly) generate 2 inputs that generate the same output...
What is not trivial is for you to generate another input that will generate (eg): 0x56f39544ebca88f261f2087dab3d7e61 or, given 0x56f39544ebca88f261f2087dab3d7e61 to figure out what input I provided.
There was a brief flurry of media attention around the time of Vlastimil's tiunneling work saying "MD5 Broken!!!". Many people (not necessarily anyone on the list) just read the sensationalist headlines with no understanding as to what had been accomplished...
As with any tool, you need to understand the capabilities and limitations before using it.
Yes, I know precisely what the attack on MD5 means; I've even published a paper on some aspects of it. The context in the article we're talking about is a discussion of the quality of the FBI's surveillance systems. The FBI's own documents mention the use of MD5; see, for example, http://www.eff.org/files/filenode/061708CKK/073007_dcs03.pdf . I assert that the context mentioned there does indeed run afoul of the vulnerability. Specifically, MD5 is being used to log received files in a surveillance system. So -- suppose I'm a bad guy and I think the FBI is monitoring my traffic. I create two files, one perhaps incriminating and one not, with the same MD5 hash. The FBI arrests me and uses the intercepted file as evidence. I tell the judge that the evidence was tampered with; as proof, I show my file that has the same MD5 hash. I then assert that the FBI and the NSA colluded to find a preimage -- "everyone" knows that NSA can do such things -- and complain to the judge. Or let's turn it around. The FBI prepares two documents with a collision, one of interest to me and the other incriminating. A undercover agent sends me the first one, which I save. I'm arrested -- and the FBI lab substitutes in the second file. The logs will still match, but I'm being convicted based on faked evidence. Or I just tell the judge that that's what the FBI did. Ever since Dobbertin's partial attack on MD5 in 1996, it's been very clear that one should not use it for new applications, and that one should phase it out of most older ones (HMAC-MD5 is an exception). I assert that continuing to use it in the DCS-3000 is not justifiable, especially because the FBI is operating in an adversarial environment. So -- I assert that when we complained about MD5 in our recent article, we knew exactly what we were saying and got our facts and our analysis precisely right.
Once again, this is one of those things that just pushes my buttons, sorry if I went off on a rant...
W
P.S: Yes thanks, I am feeling better now :-)
I hope I haven't ruined that. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Jan 30, 2008, at 5:28 PM, Steven M. Bellovin wrote:
On Wed, 30 Jan 2008 17:03:04 -0800 Warren Kumari <warren@kumari.net> wrote:
Disclaimer: I'm sitting in a meeting that is making me grumpy and this is one of my pet-peeves... I keep hearing people making the assertion that MD5 is "broken" -- this is not completely true. Yes, there have been collisions found -- yes, I can easily (and quickly) generate 2 inputs that generate the same output...
What is not trivial is for you to generate another input that will generate (eg): 0x56f39544ebca88f261f2087dab3d7e61 or, given 0x56f39544ebca88f261f2087dab3d7e61 to figure out what input I provided.
There was a brief flurry of media attention around the time of Vlastimil's tiunneling work saying "MD5 Broken!!!". Many people (not necessarily anyone on the list) just read the sensationalist headlines with no understanding as to what had been accomplished...
As with any tool, you need to understand the capabilities and limitations before using it.
Yes, I know precisely what the attack on MD5 means; I've even published a paper on some aspects of it.
Yes, I know that you do, and I know that most (all?) of the people on the list do. I also realize that, for this application, it isn't the correct choice... My little hissy fit was brought about by the many instances that I have encountered where people say things like "MD5 on BGP sessions is pointless because MD5 has been broken"[0] and other similar things...
The context in the article we're talking about is a discussion of the quality of the FBI's surveillance systems. The FBI's own documents mention the use of MD5; see, for example, http://www.eff.org/files/filenode/061708CKK/073007_dcs03.pdf . I assert that the context mentioned there does indeed run afoul of the vulnerability.
Yes.
Specifically, MD5 is being used to log received files in a surveillance system. So -- suppose I'm a bad guy and I think the FBI is monitoring my traffic. I create two files, one perhaps incriminating and one not, with the same MD5 hash. The FBI arrests me and uses the intercepted file as evidence. I tell the judge that the evidence was tampered with; as proof, I show my file that has the same MD5 hash. I then assert that the FBI and the NSA colluded to find a preimage -- "everyone" knows that NSA can do such things -- and complain to the judge. Or let's turn it around. The FBI prepares two documents with a collision, one of interest to me and the other incriminating. A undercover agent sends me the first one, which I save. I'm arrested -- and the FBI lab substitutes in the second file. The logs will still match, but I'm being convicted based on faked evidence. Or I just tell the judge that that's what the FBI did.
Ever since Dobbertin's partial attack on MD5 in 1996, it's been very clear that one should not use it for new applications, and that one should phase it out of most older ones (HMAC-MD5 is an exception). I assert that continuing to use it in the DCS-3000 is not justifiable, especially because the FBI is operating in an adversarial environment.
So -- I assert that when we complained about MD5 in our recent article, we knew exactly what we were saying and got our facts and our analysis precisely right.
Sure, and I'm sorry if it came across that I was saying that MD5 was the correct solution for this application, I wasn't... I was just venting about the folks that automatically rule out any protocol or system that uses MD5 without understanding what the hash is used for, what the issues are and what the threat model is... W [0]: There are a bunch of reasons to do (or not do) MD5 BGP authentication -- collisions in the hash is not one of them...
Once again, this is one of those things that just pushes my buttons, sorry if I went off on a rant...
W
P.S: Yes thanks, I am feeling better now :-)
I hope I haven't ruined that.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Although I agree with almost every part of the paper, I disagree with the paper. I think the threats, risks and recommendations in the paper apply regardless of the country or local ordinances. If you eliminate all the parts of the paper discussing the Protect America Act, it doesn't change the technical parts of the paper very much. <http://www.washingtonpost.com/wp-dyn/content/story/2008/01/27/ST2008012702568.html> Keeping public networks secure is an interesting problem for every network operator world-wide. By its nature, no public network can really be highly secure. If your vendor claims it is, grab your wallet and run. Its probably a waste of resources to attempt to build the network to protect the user against everything or even a lot of threats. Yet the public network relies on user trust in its operation. I think it would be interesting to watch a debate between a intelligence tech and a repair tech about whose tools need to be more robust and reliable. I suspect they would both be very vocal about their needs. The public network handled the Y2K rollover, you can't say the same thing about some of the intelligence systems :-) So if you are a network operator, what can you do technically (since this is not a law list)? I think the paper suffers a bit from "CSI" or "24" dazzle, everyone expects a DNA printout in the last 2 minutes of the show will find the bad guy, Intelligence Support tradeshows are filled with overpriced pieces of gear. Its usually the simple stuff that gets you. Most networks are filled with so many diagnostic features, buying a second set of gear is usually for administrative not functional reasons.
participants (6)
-
Frank Bulk -
James R. Cutler -
michael.dillon＠bt.com -
Sean Donelan -
Steven M. Bellovin -
Warren Kumari