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


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]

Reply via email to