Hello David, On 22/04/07 00:04, David Wagner wrote: > Hagai Bar-El writes: >> What Aram wrote is "many of the attendees have very little security >> experience", not: "there are no attendees with security experience". >> There are people at the relevant OMA group who know enough about >> security, but just like in the real world -- they are outnumbered by >> plain "feature-set" people, and thus have to come up with very clear >> arguments to get their way. > > So the people who don't know anything about security are reluctant to > listen to those who do? That's not a good sign. It may be standard > operating procedure in groups like this, but that doesn't make it right. > It's still dysfunctional and dangerrous. If the committee doesn't have > a commitment to security and is reluctant to listen to the experts, > that's a risk factor.
The group is not "reluctant" to listen, but it does expect to hear firm reasoning, so the security consideration weights properly among other, as important, considerations. Security gurus A' say A, Performance gurus B' say B, which may partially conflict with A, and UI gurus C' say C. If the product is broken then it's dead, but also if the product is slow and annoys people, and also if average people can't use it for UI reasons. It's easy to make a product that is never used, even if it's secure. When we look at things, we see them as secure/insecure, but the market and the economy sees a more complex picture where security is very important, but is one important factor along with other important factors that influence the design decision. As long as security comes for no cost -- sure, why not. However, when security comes at a cost that may make the product less useful, A' need to convince (A' U B' U C') that they should have their way. > If you're sick and you go to a doctor, do you tell the doctor "you'd > better come up with some very clear arguments if you want me to follow > your advice"? Do you tell your doctor "you'd better build a strong case > before I will listen to you"? I would hope not. That would be silly. > Doctors are medical professionals with a great deal of training and > expertise in the subject. They can speak with authority when it comes > to your health. So why do people with no training in security think > that they can freely ignore the advice of security professionals without > any negative consequences? As long as what the Doctor says costs you very little (in terms of risk and/or money), you follow his advice blindly because challenging it will cost you more. When the doctor tells you that you need a heart surgery -- you do challenge it: you try to get a second opinion, you ask him to explain the case in ways you can understand and be able to gain more information on the subject. At least I hope you do. People don't ignore security professionals. However, when high costs are involved, "challengeable rationale" is called for. As long as economy is not a single-factor B/W, this is how it should be. >> AND (3) If you don't care about replacement attacks on the (1 to i) >> blocks that will result only in a (possibly-undetected) corruption when >> decrypting the i+1 block (rather than two blocks, with a varying and >> non-attacker-changeable). [...] > > Wait a minute. This reference to replacement attacks has me concerned. > Does the protocol use a message authentication code (MAC)? I hope so. > If your protocol uses a MAC, and uses it properly, then replacement > attacks are not an issue, and the only issue with using a fixed IV is > related to confidentiality. If you don't use a MAC, you've got bigger > problems, and even random IVs won't be enough. I generally agree. Some protocols try to be cheap on MAC, assuming that the strict structure of the protocol will cause a failure if something goes bad. For example, if a message has an intrinsic entropy of 2 bits (say, a return status code), and is sent as one block (you can't send less), then you don't really need a MAC, as long as the recipient knows not to crash disgracefully if it receives an invalid status code. I guess my point is meaningless for the case in question, as MACs are used... Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
