home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1984.txt < prev    next >
Text File  |  1996-08-18  |  11KB  |  284 lines

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