[Cryptography] Other obvious issues being ignored?

[John Denker]

On 10/19/2015 06:10 AM, Thierry Moreau asked:
> 
> What other "obvious" questions are we ignoring?

That is an excellent question!  Contrary to what others have suggested,
it is not at all a rhetorical question.  Generally speaking, rhetorical
questions don't need to be answered, but this question needs serious
thought and serious answers.

On 10/19/2015 08:00 PM, Peter Gutmann wrote:

>> You can't even come up with a checklist for this, because you'd have to ask so
>> many questions, and of such boneheaded obviousness, that you couldn't get
>> anyone to come up with them all.

I assume that means you can't come up with a /perfect/ checklist.
In any case, we should not let the perfect be the enemy of the good.
An incomplete checklist is better than no checklist.

===========

Here is something to add to what others have said:

*) There is a fundamental principle that says
     "If you can't encrypt properly, don't encrypt at all.
      If you send in the clear, you endanger only yourself,
      in obvious ways, whereas if you misuse the cryptosystem
      you endanger everybody, in less-obvious ways."

 I forget who is credited with that idea.  It's discussed in
 Kahn somewhere.

 This stands in contrast to traditional internet policy,
 namely Postel's robustness principle:
     "be conservative in what you do, be liberal in what 
      you accept from others."

 In a friendly environment that leads to robustness, but in an
 adversarial environment it leads to catastrophe.  Basic security
 demands that clients must become much *less tolerant* of broken
 servers than they presently are.  Similarly, servers must become 
 much less tolerant of broken clients.

 This problem is not easy to fix, but it needs to be fixed anyway.
 Reasons why it is hard to fix include:

 1) There is the longstanding practice of shooting the messenger.
  Anecdote:
    One of the first business deals I ever did involved selling
    some software to JPL.  I wrote the software to be defensive.
    It detected deadlocks and printed warnings.  The customer
    complained about the deluge of warnings and threatened not 
    to pay me.  I had to explain, "Your code is broken, not mine.
    It's broken in mission-critical ways, and it's been broken for 
    years.  You should pay me extra for detecting and pinpointing
    the problem."  By way of compromise I offered to print less-
    verbose warnings.

  2) In typical client/server situations, the messenger is knocking
   on the wrong door.  For example, if a client app notices that the
   server is insecure, it does no good to print a warning, because
   the client (in all probability) is powerless to fix the problem.
   In fact, the warning is worse than nothing, because it just
   trains the user to habitually ignore warnings.  Even if the app 
   throws a fatal error, it does no good, because the user will just
   switch to a different app that "works better".

  3) People are really good at ignoring problems that they don't
   know how to fix, even if the problems are super-obvious.

 Possibly partially constructive suggestion:  there should be more
 in the way of white-hat scanner tools to check for known weaknesses 
 ... and people should get into the habit of using them.  Here's a
 small example of the sort of thing I'm talking about:
     https://weakdh.org/sysadmin.html

 It will tell you that  duats.com  is offering "export grade"
 ciphers, which is a Bad Thing, since the site is supposed to
 be providing life-and-death critical information.  Also, the
 following sites don't offer Forward Secrecy at all:
     citibank.com
     mastercard.com
     va.gov
     cisco.com
     microsoft.com
     icann.org


 Bottom line:  There is a *lot* of broken crypto out there, some
 of it affecting critical infrastructure.  Overall, this is a terrible
 problem.  The fact that I don't know how to fix it doesn't make it 
 any less obvious or any less terrible.  Theoretically the "boneheaded 
 obvious" stuff should be the easiest to fix.