Five Theses on Security Protocols

[Perry E. Metzger]

Inspired by recent discussion, these are my theses, which I hereby
nail upon the virtual church door:

1 If you can do an online check for the validity of a key, there is no
  need for a long-lived signed certificate, since you could simply ask
  a database in real time whether the holder of the key is authorized
  to perform some action. The signed certificate is completely
  superfluous.

  If you can't do an online check, you have no practical form of
  revocation, so a long-lived signed certificate is unacceptable
  anyway.

2 A third party attestation, e.g. any certificate issued by any modern
  CA, is worth exactly as much as the maximum liability of the third
  party for mistakes. If the third party has no liability for
  mistakes, the certification is worth exactly nothing. All commercial
  CAs disclaim all liability.

  An organization needs to authenticate and authorize its own users;
  it cannot ask some other organization with no actual liability to
  perform this function on its behalf. A bank has to know its own
  customers, the customers have to know their own bank. A company
  needs to know on its own that someone is allowed to reboot a machine
  or access a database.

3 Any security system that demands that users be "educated",
  i.e. which requires that users make complicated security decisions
  during the course of routine work, is doomed to fail.

  For example, any system which requires that users actively make sure
  throughout a transaction that they are giving their credentials to
  the correct counterparty and not to a thief who could reuse them
  cannot be relied on.

  A perfect system is one in which no user can perform an action that
  gives away their own credentials, and in which no user can
  authorizes an action without their participation and knowledge. No
  system can be perfect, but that is the ideal to be sought after.

4 As a partial corollary to 3, but which requires saying on its own:
  If "false alarms" are routine, all alarms, including real ones, will
  be ignored. Any security system that produces warnings that need to
  be routinely ignored during the course of everyday work, and which
  can then be ignored by simple user action, has trained its users to be
  victims.

  For example, the failure of a cryptographic authentication check
  should be rare, and should nearly always actually mean that
  something bad has happened, like an attempt to compromise security,
  and should never, ever, ever result in a user being told "oh, ignore
  that warning", and should not even provide a simple UI that permits
  the warning to be ignored should someone advise the user to do so.

  If a system produces too many false alarms to permit routine work to
  happen without an "ignore warning" button, the system is worthless
  anyway.

5 Also related to 3, but important in its own right: to quote Ian
  Grigg:

    *** There should be one mode, and it should be secure. ***

  There must not be a confusing combination of secure and insecure
  modes, requiring the user to actively pay attention to whether the
  system is secure, and to make constant active configuration choices
  to enforce security. There should be only one, secure mode.

  The more knobs a system has, the less secure it is. It is trivial to
  design a system sufficiently complicated that even experts, let
  alone naive users, cannot figure out what the configuration
  means. The best systems should have virtually no knobs at all.

  In the real world, bugs will be discovered in protocols, hash
  functions and crypto algorithms will be broken, etc., and it will be
  necessary to design protocols so that, subject to avoiding downgrade
  attacks, newer and more secure modes can and will be used as they
  are deployed to fix such problems. Even then, however, the user
  should not have to make a decision to use the newer more secure mode,
  it should simply happen.


Perry
-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com