January 3, 2000

Charlotte Knepper
National Security Council
Old Executive Office Building
Washington, D.C. 20510

Re: BXA’s 2nd Discussion Draft of the New Encryption Export Control Policy

Dear Charlotte:

Members of the Alliance for Network Security (“ANS”) appreciate your invitation to meet with the Interagency Working Group (“IWG”) on January 4, 2000, to review the second discussion draft of the new encryption export control policy that was circulated last month by the Bureau of Export Administration (“BXA”). In general, ANS members feel that the second discussion draft makes significant and positive changes to the previous draft. We are particularly pleased that the government ownership criterion for telecommunications and internet service providers (“Telco/ISPs”) was eliminated in accordance with our recommendation. Bearing in mind the Administration’s commitment to publish an interim rule by January 14, 2000, our recommendations in this letter are limited to those points that are of highest priority to ANS member companies.

Our primary concerns with respect to the discussion draft involve the following issues: (1) restrictions on deployment of encryption products by Telco/ISPs, (2) the definition of “government”, (3) the definition of “retail”, (4) reporting of retail products, (5) de minimis controls, and (6) treatment of 56 and 64 bit products.

  1. Restrictions on Deployment of Encryption Products by Telco/ISPs

Section 740.17(a)(4) of the December Discussion Draft states that:

…the following uses of any product not classified as retail are subject to license: …

(ii) bulk encryption of the telecommunications backbone at the link layer (layer 2 of the Open Systems Interconnect (OSI) model). This does not include encryption when used by the internet or telecommunications service provider for internal use only, e.g., the protection of company proprietary and business account information, or encryption between a customer and the service provider.”

We suggest that this provision should be modified as indicated in the red-line above for the following reasons, among others. First, we recommend striking the term “non-subscriber based” because this term lacks a technical basis. Second, we recommend striking the word “or” and replacing it with the word “at” in order to create a clear linkage between the location of the encryption service (i.e., the backbone) and the type of product providing the encryption service (i.e., layer 2). Failure to create such a linkage potentially (and, unintentionally, we believe) could render all aggregate encryption of the backbone (regardless of the product used), and all layer 2 devices (regardless of where they may be deployed), subject to a license requirement. Among other unintended consequences, this could make the central office to central office (so-called “cheapskate VPN”) subject to a license requirement.

  1. Definition of “Government”

We recommend that the civil end-uses described in Section 742.15(b)(3) be moved to paragraph (b) in the Definition of Government in Part 772. Specific changes are highlighted below:

(3) Encryption Licensing. Applicants may submit license applications for exports and re-exports of encryption items not eligible for export under license exception in unlimited quantities for all destinations except Cuba, Iran, Iraq, Libya, North Korea, Sudan or Syria, including exports and re-exports of encryption technology to strategic partners of U.S. companies (as defined in part 772). For Encryption Licensing Arrangements, the applicant must specify the sales territory and class of end-user. Encryption Licensing Arrangements are valid for four years and may require reporting. Applications for the export and re-export of all other encryption items will be reviewed on a case-by-case basis.

Government End-user (as applied to encryption items). A government end-user is (a) any foreign central, regional or local government department, agency, or other entity performing governmental functions; including governmental research institutions, governmental corporations or their separate business units (as defined in part 772 of the EAR) which are engaged in the manufacture or distribution of items or services controlled on the Wassenaar Munitions List, and international governmental organizations;

(b) this term does not include the following public entities: utilities (including telecommunications companies and Internet service providers); banks and financial institutions; transportation; broadcast or entertainment; educational organizations; civil health and medical organizations; retail or wholesale firms; manufacturing or industrial entities not engaged in the manufacture or distribution of items or services controlled on the Wassenaar Munitions List; and other entities engaged in civil uses, e.g., the provision of social or financial service to the public, civil justice, social insurance, pensions and retirement, taxes and communications between governments and their citizens.

  1. Definition of “Retail”

We appreciate the significant changes made to the definition of “retail”, especially the new provisions that extend retail product treatment to products available through mail order transactions, electronic transactions or telephone call transactions, as well as products that provide “equivalent functionality”. However, as we discussed in detail at our previous meeting, we are concerned that certain products are not going to be classified as retail, notwithstanding the expanded definition in the second discussion draft. One example is Novell’s BorderManager, which is available over the internet, as demonstrated below:

Sample Offering from www.buy.com (December 27, 1999)

http://www.buy.com/soft/product.asp?sku=20303692

BORDERMANAGER VPN SVCS 3.5 128+ BIT SERVER+5U (mfg part# 00662644341095)

Our Price: $734.95 BuyNow Gift List

Retail Price: $995.00 You Save: $260.05

Availability: Usually Ships in 24-48 Hours

Platform: Not Machine Specific

Description | Features

BorderManager VPN Services 128 bit server+5 is a secure remote connectivity system you can use to create your own virtual private network, which is a lot of hard work in itself. As well as this, looking for some inspiration from someone like Josh MacDonald and the best VPNs you can find in countries like Canada (https://joshmacdonald.net/best-vpn-canada/) may also help you to find the most secure connectivity for your own private network. Of course, it all depends on what you want to use your VPN for. As well as this, it may also be worthwhile to look at how sd wan providers can help you in these areas too. You can provide remote offices, mobil users, customers and suppliers secure access to your confidential data over the internet or other public backbones.

Other examples of similar products can be found at:

Network Associates’ Gauntlet Firewall/VPN as part of Total Network Security Suite, 1-25 user license for $342.70

http://www.cdromshop.com/cgibin/pjm/searchbykey.cgi?keywords=total+nework+security&andor=or&platform=all

NetScreen Technologies’ NetScreen 5 for 10 users (Swiss web site, no prices)

http://www.gcs.ch/cgi-bin/GCS.storefront/568252304/Catalog/1037

  1. Reporting of Retail Products

The December Discussion Draft requires reporting with respect to exports of retail products to everyone except “individuals”. The problem is that companies seldom know whether the recipient is an “individual” purchasing for his or her own use, as opposed to a person who is ordering on behalf of a company, government or other organization.

Therefore, exporters will likely have to choose between two possible approaches, and risk either over-reporting or under-reporting on a systematic basis. For example, companies could err on the side of over-reporting by sending in all the relevant information on all direct sales. The net result is that there is no benefit to the exclusion of “retail products exported to individual consumers” from the reporting requirements, and the government receives a lot of information that it neither needs nor wants. Moreover, since the exclusion of individuals from the reporting requirements was, at least in part, an attempt to deal with the issues raised by the EU Privacy Directive, this problem remains.

Another approach that companies might take would be to attempt to make a reasonable determination for each distribution channel whether the sales in that channel are predominantly to individuals or enterprises. Obviously, this is not a perfect solution. It would still result in over-reporting in same cases, and does not necessarily obviate the risks associated with privacy laws in other countries.

We respectfully suggest that the best solution would be to completely exclude retail products from the reporting requirements.

  1. De Minimis Controls

Because EI-controlled software currently is not eligible for de minimis exceptions, maintaining EI controls on greater than 64-bit software could make it impossible for U.S. manufacturers to sell their products for incorporation into foreign products. Unless the de minimis exclusion is removed, some companies will have no choice but to continue to produce dual versions of products -one weak encryption version that can be free of EI-controls, and one strong encryption version. If this is the case, the cost savings and the ability to compete with foreign suppliers that were anticipated as a result of the new policy will not come to pass. Given the essentially unfettered exportability of “retail” encryption products, and the very broad exportability of the remaining “non-retail” products, the exclusion from de minimis treatment for EI-controlled items seems to be outdated and unnecessary. We recommend that EI-controls should be eliminated altogether, or, in the alternative, Section 734.4(b)(2) should be deleted and 734.4(h) should be amended to reflect that deletion.

  1. Treatment of 56 and 64 bit Products

The December Discussion Draft is still unclear and inconsistent in some instances regarding the classification of 56 and 64 bit key length products with various symmetric / asymmetric key exchange combinations.

For 56/512 products, the December Discussion Draft is relatively clear. Section 742.15(b)(1)(i) states that such products are classified as 5A992 or 5D992 and are eligible for export under NLR. The “Cryptography Note” in Part 774 confirms this classification.

For 56/1024 products, however, the December Discussion Draft is not so clear. For instance, Section 742.15(b)(1) suggests that eligibility for 5A992 or 5D992 is limited to 56 bit products with key exchange algorithms not exceeding 512 bits. However, the “Cryptography Note” in Part 774 states that 5A002 and 5D002 do not control mass market products, provided that the symmetric algorithm is 64-bits or less, implying that 56/1024 products would be classified under 5A992 or 5D992, at least if they qualify as mass market. Further confusing matters, Section 740.17(a)(3)(vii) states that 56 bit products with key exchange mechanisms in the range of 512-1024 will be classified under 5A002 and 5D002 and qualify as “retail”.

For 64-bit products, the appropriate classification is equally obscure. First, Section 740.17(e)(3) states that mass market products with 40 or 56 bit symmetric key lengths that were previously eligible for License Exception TSU can be upgraded to 64/512 bit or 64/1024 bit without additional technical review. However, this is in the section that discusses eligibility for License Exception ENC, so it appears that the December Discussion Draft indicates that these two key length combinations would be 5A002 or 5D002 / ENC.

Then, Section 742.15(b)(1)(iii) states that mass market products with 64-bit or less symmetric key lengths may be classified as 5D992. And the “Cryptography Note” in Part 774 further indicates that 5A002 and 5D002 do not control mass market encryption items that “do not contain a ‘symmetric algorithm’ employing a key length exceeding 64-bits.” So under the terms of Cryptography Note a 64/512 or 64/1024 bit product would be exportable as 5A992 or 5D992 / NLR.

For 64 bit products, the conflict between Section 740.17(e)(3) on the one hand, and Section 742.15(b)(1)(iii) and the Cryptography Note on the other, cannot be resolved by distinguishing between those products that are mass market that those that are not. Each of these sections refers to 64-bit mass market products.

Below is a chart that shows the various key length combinations of software products and what classification is implicitly or explicitly indicated in the different sections of the December Discussion Draft.

Key Lengths § 740.17(e)(3) § 742.15(b)(1) Part 774 – Cryptography Note

56/512 N/A 5D992 / NLR 5D992 / NLR*

56/1024 N/A 5D002 / ENC (or TSU?) 5D992 / NLR*

64/512 5D002 / ENC* 5D992 / NLR* 5D992 / NLR*

64/1024 5D002 / ENC* 5D992 / NLR* 5D992 / NLR*

Note: Items marked with the asterisk (*) indicate that the classification depends on the product being “mass market”

We recommend that, for the sake not only of clarity but also simplicity, that all 56 and 64 bit products with asymmetric key exchange mechanisms not exceeding 1024 and/or symmetric key exchange mechanisms not exceeding 112, should be classified under 5A992 and 5D992, should be released from EI controls, and should not require reporting.

Conclusion

We look forward to discussing these and other issues with you at the meeting on January 4. If you would like to discuss any of them in advance of the meeting, please let me know.

Sincerely,

Roszel C. Thomsen II
Counsel
Alliance for Network Security