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.
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
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
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 
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, Steven M. Bellovin
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.
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...