RFC 1984

IAB and IESG Statement on Cryptographic Technology and the Internet

πŸ“… published August 1996, from ietf

IAB and IESG Statement on Cryptographic Technology and the Internet πŸ”βœ¨

Okay bestie, this is RFC 1984 πŸ’–, and it's giving Informational vibes πŸŽ€. It's dated August 1996 and comes from the IAB and IESG 🌸. The header says Network Working Group, and the authors are Brian E. Carpenter (Chair of the IAB, at CERN) and Fred Baker (Chair of the IETF, at cisco Systems) πŸ‘‘. Its title block doesn't list anything it obsoletes or updates, so it's a standalone moment πŸ¦‹.


Status of This Memo πŸ“œ

So this memo is just here to provide information for the Internet community 🧚. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.

The copyright line is (C) Internet Society 1996 πŸ”–. You're free to reproduce or translate the complete document, notice included, but only the whole thing. Extracts are not covered by that permission 🫢.

July 24, 1996 is the date on the statement itself πŸ“….

The IAB and IESG are the bodies that oversee Internet architecture and standards, and honestly they're worried about two things 😭. First, the Internet needs more protection for international commercial transactions. Second, every Internet user deserves an adequate degree of privacy πŸ”.

The security mechanisms the IETF is building for these needs require, and depend on, the international use of adequate cryptographic technology πŸ’œ. Ready access to that tech is a huge factor in whether the Internet keeps growing as a motor for international commerce and communication πŸš€.

So the IAB and IESG are disturbed, not gonna lie πŸ’€. Various governments have actual or proposed policies on access to cryptographic technology that do one or more of the following:

  • (a) impose restrictions by implementing export controls; and/or
  • (b) restrict commercial and private users to weak and inadequate mechanisms such as short cryptographic keys; and/or
  • (c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or
  • (d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations.

We believe these policies are against the interests of consumers and the business community 😀. They're largely irrelevant to issues of military security, and they give law enforcement agencies only a marginal or illusory benefit, as discussed below πŸ™„.

The IAB and IESG would love to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries πŸŒπŸ’–.

The IAB and IESG claim:

The Internet is becoming the predominant vehicle for electronic commerce and information exchange πŸ“ˆ. It is essential that the support structure for these activities can be trusted 🫢.

Encryption is not a secret technology monopolized by any one country, so export controls can't really hope to contain its deployment πŸ™…β€β™€οΈ. Any hobbyist can program a PC to do powerful encryption πŸ’». Many algorithms are well documented, and some come with source code available in textbooks πŸ“š.

Export controls on encryption put companies in that country at a competitive disadvantage πŸ“‰. Their competitors from countries without export restrictions can sell systems whose only design constraint is being secure and easy to use ✨.

Usage controls on encryption also put companies in that country at a competitive disadvantage, because those companies can't securely and easily engage in electronic commerce πŸ›’.

Escrow mechanisms inevitably weaken the security of the overall cryptographic system πŸ’”. They create new points of vulnerability that can and will be attacked πŸ—‘οΈ.

Export controls and usage controls are slowing the deployment of security, and that is happening at the same time the Internet is exponentially increasing in size and attackers are getting more sophisticated 😱. That puts users in a dangerous position, because they're forced to rely on insecure electronic communication 🚨.


TECHNICAL ANALYSIS πŸ”¬

KEY SIZE πŸ”‘

It's not acceptable to restrict the use or export of cryptosystems based on their key size πŸ™…β€β™€οΈ. Systems breakable by one country will be breakable by others, possibly unfriendly ones πŸ‘€. Large corporations and even criminal enterprises have the resources to break many cryptosystems πŸ’Έ. Conversations also often need protecting for years to come, and as computers get faster, key sizes that were once out of reach of cryptanalysis become insecure ⏳.

PUBLIC KEY INFRASTRUCTURE πŸ—οΈ

Public key cryptography often needs a "certification authority" πŸ›οΈ. Some third party has to sign a string containing the user's identity and public key, and that third party's key is often signed by a higher-level certification authority in turn πŸ”—.

This structure is legitimate and necessary πŸ’…. Many governments will and should run their own CAs, if only to protect citizens' transactions with their governments 🫢. But certification authorities should not be confused with escrow centers πŸ™…β€β™€οΈ. Escrow centers are repositories for private keys, while certification authorities deal with public keys πŸ”‘. Sound cryptographic practice says users should never reveal their private keys to anyone, not even the certification authority 🀫.

KEYS SHOULD NOT BE REVEALABLE πŸ™…β€β™€οΈπŸ”

The security of a modern cryptosystem rests entirely on the secrecy of the keys 🀯. So it's a major principle of system design that, to the extent possible, secret keys should never leave their user's secure environment 🏰. Key escrow means keys have to be disclosed in some fashion, which is a flat-out contradiction of that principle πŸ’€. Any disclosure weakens the total security of the system πŸ“‰.

DATA RECOVERY πŸ’Ύ

Escrow systems get touted as good for the customer, since they allow data recovery when keys are lost πŸ™ƒ. But it should be up to the customer to decide whether they'd prefer the more secure system, where lost keys mean lost data, or one where keys are escrowed to be recovered when necessary πŸ€·β€β™€οΈ. Keys used only for conversations (as opposed to file storage) need never be escrowed πŸ’¬. And a system where the secret key is stored by a government, and not by the data owner, is certainly not practical for data recovery πŸ™…β€β™€οΈ.

SIGNATURE KEYS ✍️

Keys used for signatures and authentication must never be escrowed 🚫. Any third party with access to those keys could impersonate the legitimate owner, which opens the door to new fraud and deceit 😀.

It gets worse, bestie 😭. A user who wanted to repudiate a transaction could claim their escrowed key was used, which puts the onus on that party. And if a government escrowed the keys, a defendant could claim the evidence was forged by the government, making prosecution way harder βš–οΈ. For electronic commerce, non-repudiation is one of the most important uses of cryptography πŸ’Ό. It depends on the assumption that only the user has access to the private key πŸ”’.

PROTECTION OF THE EXISTING INFRASTRUCTURE πŸ—οΈ

Sometimes it's technically feasible to use cryptographic operations that don't involve secrecy πŸ€“. That may suffice in some cases, but a lot of the existing technical and commercial infrastructure can't be protected that way 😬. For example, conventional passwords, credit card numbers, and the like must be protected by strong encryption, even though someday more sophisticated techniques may replace them πŸ’³. Encryption can be added on quite easily, but wholesale changes to diverse systems cannot πŸ”§.

CONFLICTING INTERNATIONAL POLICIES 🌏

Conflicting restrictions on encryption often force an international company to use a weak encryption system, just to satisfy legal requirements in two or more countries πŸ™ƒ. The irony is that either nation might consider the other an adversary against whom commercial enterprises should use strong cryptography πŸ€¦β€β™€οΈ. Clearly, key escrow isn't a suitable compromise, since neither country would want to disclose keys to the other 🚫.

MULTIPLE ENCRYPTION πŸ§…

Even if escrowed encryption schemes are used, nothing stops someone from using another encryption scheme first πŸ‘€. Serious malefactors would definitely do this, since the outer encryption layer, which would use an escrowed scheme, would be used to divert suspicion πŸ•΅οΈβ€β™€οΈ.

ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION πŸ™…β€β™€οΈπŸ”“

A major threat to users of cryptographic systems is the theft of long-term keys, perhaps by a hacker, either before or after a sensitive conversation 😰. To counter this, schemes with "perfect forward secrecy" are often employed πŸ›‘οΈ. If PFS is used, the attacker must be in control of the machine during the actual conversation πŸ–₯️. But PFS is generally incompatible with schemes involving escrow of private keys πŸ’”. (This is an oversimplification, but a full analysis would be too lengthy for this document πŸ™ˆ.)

CONCLUSIONS πŸŽ€

As more and more companies connect to the Internet, and more and more commerce happens there, security becomes more and more critical πŸ“ˆ. Cryptography is the most powerful single tool users have to secure the Internet πŸ’ͺ. Knowingly making that tool weaker threatens their ability to do so, and it has no proven benefit πŸ’….


Security Considerations πŸ”’πŸ˜­

Security is the whole vibe of this memo, so security issues are discussed throughout it πŸ›‘οΈβœ¨.


Authors' Addresses πŸ’Œ

Brian E. Carpenter is Chair of the IAB and is based at CERN, the European Laboratory for Particle Physics πŸ‡¨πŸ‡­. His contact details:

Brian E. Carpenter
Chair of the IAB
CERN
European Laboratory for Particle Physics
1211 Geneva 23
Switzerland

Phone: +41 22 767-4967
EMail: brian@dxcoms.cern.ch

Fred Baker is Chair of the IETF and works at cisco Systems, Inc. πŸŒ‰ His contact details:

Fred Baker
Chair of the IETF
cisco Systems, Inc.
519 Lado Drive
Santa Barbara, CA 93111

Phone: +1-805-681-0115
EMail: fred@cisco.com

You can read about the Internet Society at http://www.isoc.org/ 🌐.

The Internet Architecture Board is described at http://www.iab.org/iab 🧭.

The Internet Engineering Task Force and the Internet Engineering Steering Group are described at http://www.ietf.org πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from