freeswan/doc/iab-iesg.stmt

   1 From: major@linus.isoc.org
   2 To: members.5@linus.isoc.org
   3 Subject: Press Release
   4 Date: Thu, 25 Jul 96 12:26:56 EDT
   5 Message-ID:  <9607251226.aa12814@linus.isoc.org>
   6
   7 IAB and IESG statement on cryptographic technology and the Internet
   8 -------------------------------------------------------------------
   9
  10 July 24, 1996
  11
  12 The Internet Architecture Board (IAB) and the Internet Engineering
  13 Steering Group (IESG), the bodies which oversee architecture and
  14 standards for the Internet, are concerned by the need for increased
  15 protection of international commercial transactions on the Internet,
  16 and by the need to offer all Internet users an adequate degree of
  17 privacy.
  18
  19 Security mechanisms being developed in the Internet Engineering
  20 Task Force to meet these needs require and depend on the international
  21 use of adequate cryptographic technology.  Ready access to such
  22 technology is therefore a key factor in the future growth of the
  23 Internet as a motor for international commerce and communication.
  24
  25 The IAB and IESG are therefore disturbed to note that various
  26 governments have actual or proposed policies on access to cryptographic
  27 technology that either:
  28 (a) impose restrictions by implementing export controls; and/or
  29 (b) restrict commercial and private users to weak and inadequate
  30 mechanisms such as short cryptographic keys; and/or
  31 (c) mandate that private decryption keys should be in the hands of
  32 the government or of some other third party; and/or
  33 (d) prohibit the use of cryptology entirely, or permit it only
  34 to specially authorized organizations.
  35
  36 We believe that such policies are against the interests of consumers
  37 and the business community, are largely irrelevant to issues of
  38 military security, and provide only a marginal or illusory benefit
  39 to law enforcement agencies, as discussed below.
  40
  41 The IAB and IESG would like to  encourage policies that allow ready
  42 access to uniform strong cryptographic technology for all Internet
  43 users in all countries.
  44
  45 The IAB and IESG claim:
  46
  47 The Internet is becoming the predominant vehicle for electronic
  48 commerce and information exchange. It is essential that the support
  49 structure for these activities can be trusted.
  50
  51 Encryption is not a secret technology monopolized by any one country,
  52 such that export controls can hope to contain its deployment. Any
  53 hobbyist can program a PC to do powerful encryption. Many algorithms
  54 are well documented, some with source code available in textbooks.
  55
  56 Export controls on encryption place companies in that country at
  57 a competitive disadvantage. Their competitors from countries without
  58 export restrictions can sell systems whose only design constraint
  59 is being secure, and easy to use.
  60
  61 Usage controls on encryption will also place companies in that
  62 country at a competitive disadvantage because these companies cannot
  63 securely and easily engage in electronic commerce.
  64
  65 Escrow mechanisms inevitably weaken the security of the overall
  66 cryptographic system, by creating new points of vulnerability that
  67 can and will be attacked.
  68
  69 Export controls and usage controls are slowing the deployment of
  70 security at the same time as the Internet is exponentially increasing
  71 in size and attackers are increasing in sophistication. This puts
  72 users in a dangerous position as they are forced to rely on insecure
  73 electronic communication.
  74
  75
  76 TECHNICAL ANALYSIS
  77 --------------------------
  78
  79 KEY SIZE
  80
  81 It is not acceptable to restrict the use or export of cryptosystems
  82 based on their key size.  Systems that are breakable by one country
  83 will be breakable  by others, possibly unfriendly ones.  Large
  84 corporations and even criminal enterprises have the resources to
  85 break many cryptosystems.  Furthermore, conversations often need
  86 to be protected for years to come; as computers increase in speed,
  87 key sizes that were once out of reach of cryptanalysis will become
  88 insecure.
  89
  90
  91 PUBLIC KEY INFRASTRUCTURE
  92
  93 Use of public key cryptography often requires the existence of a
  94 "certification authority".  That is, some third party must sign a
  95 string containing the user's identity and public key.  In turn,
  96 the third party's key is often signed by a higher-level certification
  97 authority.
  98
  99 Such a structure is legitimate and necessary.  Indeed, many
 100 governments will and should run their own CAs, if only to protect
 101 citizens' transactions with their governments.  But certification
 102 authorities should not be confused with escrow centers.  Escrow
 103 centers are repositories for private keys, while certification
 104 authorities deal with public keys. Indeed, sound cryptographic
 105 practice dictates that users never reveal their private keys to
 106 anyone, even the certification authority.
 107
 108
 109 KEYS SHOULD NOT BE REVEALABLE
 110
 111 The security of a modern cryptosystem rests entirely on the secrecy
 112 of the keys.  Accordingly, it is a major principle of system design
 113 that to the extent possible, secret keys should never leave their
 114 user's secure environment.  Key escrow implies that keys must be
 115 disclosed in some fashion, a flat-out contradiction of this principle.
 116 Any such disclosure weakens the total security of the system.
 117
 118 DATA RECOVERY
 119
 120 Sometimes escrow systems are touted as being good for the customer
 121 because they allow data recovery in the case of lost keys. However,
 122 it should be up to the customer to decide whether they would prefer
 123 the more secure system in which lost keys mean lost data, or one
 124 in which keys are escrowed to be recovered when necessary.  Similarly,
 125 keys used only for conversations (as opposed to file storage) need
 126 never be escrowed.  And a system in which the secret key is stored
 127 by a government and not by the data owner is certainly not practical
 128 for data recovery.
 129
 130 SIGNATURE KEYS
 131
 132 Keys used for signatures and authentication must never be escrowed.
 133 Any third party with access to such keys could impersonate the
 134 legitimate owner, creating new opportunities for fraud and deceit.
 135 Indeed, a user who wished to repudiate a transaction could claim
 136 that his or her escrowed key was used, putting the onus on that
 137 party.  If a government escrowed the keys, a defendant could claim
 138 that the evidence had been forged by the government, thereby making
 139 prosecution much more difficult.  For electronic commerce,
 140 non-repudiation is one of the most important uses for cryptography;
 141 and non-repudiation depends on the assumption that only the user
 142 has access to the private key.
 143
 144 PROTECTION OF THE EXISTING INFRASTRUCTURE
 145
 146 In some cases, it is technically feasible to use cryptographic operations
 147 that do not involve secrecy.  While this may suffice in some cases, much
 148 of the existing technical and commercial infrastructure cannot be
 149 protected in this way.  For example, conventional passwords, credit
 150 card numbers, and the like must be protected by strong encryption,
 151 even though some day more sophisticated techniques may replace them.
 152 Encryption can be added on quite easily; wholesale changes to diverse
 153 systems cannot.
 154
 155 CONFLICTING INTERNATIONAL POLICIES
 156
 157 Conflicting restrictions on encryption often force an international
 158 company to use a weak encryption system, in order to satisfy legal
 159 requirements in two or more different countries.  Ironically, in
 160 such cases either nation might consider the other an adversary
 161 against whom commercial enterprises should use strong cryptography.
 162 Clearly, key escrow is not a suitable compromise, since neither
 163 country would want to disclose keys to the other.
 164
 165 MULTIPLE ENCRYPTION
 166
 167 Even if escrowed encryption schemes are used, there is nothing to
 168 prevent someone from using another encryption scheme first.  Certainly,
 169 any serious malefactors would do this; the outer encryption layer,
 170 which would use an escrowed scheme, would be used to divert suspicion.
 171
 172
 173 ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION
 174
 175 A major threat to users of cryptographic systems is the theft of
 176 long-term keys (perhaps by a hacker), either before or after a
 177 sensitive conversation.  To counter this threat, schemes with
 178 "perfect forward secrecy" are often employed.  If PFS is used, the
 179 attacker must be in control of the machine during the actual
 180 conversation.  But PFS is generally incompatible with schemes
 181 involving escrow of private keys.  (This is an oversimplification,
 182 but a full analysis would be too lengthy for this document.)
 183
 184
 185
 186 CONCLUSIONS
 187 --------------------------
 188
 189 As more and more companies connect to the Internet, and as more and
 190 more commerce takes place there, security is becoming more and more
 191 critical.  Cryptography is the most powerful single tool that users
 192 can use to secure the Internet. Knowingly making that tool weaker
 193 threatens their ability to do so, and has no proven benefit.
 194
 195 ----
 196 The Internet Architecture Board is described at http://www.iab.org/iab
 197
 198 The Internet Engineering Task Force and the Internet Engineering
 199 Steering Group are described at http://www.ietf.org
 200
 201 ----
 202 (C) Internet Society 1996. Reproduction or translation of the
 203 complete document, but not of extracts, including this notice,
 204 is freely permitted.
 205
 206 For further information, please contact:
 207
 208 Fred Baker, Chair - Internet Engineering Steering Group
 209 Voice:          +1 408 526 4257
 210 Fax:            +1 805 681-0115
 211 Email:  fred@cisco.com
 212
 213 Brian Carpenter, Chair - Internet Architecture Board
 214 Voice:          +41 22 767 4967
 215 Fax:            +41 22 767 7155
 216 Email:          brian@dxcoms.cern.ch
 217
 218 Donald M. Heath, President/CEO - The Internet Society
 219 Voice:          +1 703 648 9888
 220 Fax:            +1 703 648 9887
 221 Email:          heath@isoc.org