DNSSEC - Government Controls (or the lack thereof)

Because DNS Security software doesn't encrypt to hide information, just to
authenticate, few government controls apply to it. Then because it is
publicly available software, it is not subject to the Export Administration
Regulations.

This is a relatively simple decision path, as export decisions go. Let's go
over it step by step.

First, this DNS Security software only authenticates information, rather
than hiding it. This happens naturally, because the DNS Security protocols
are designed to authenticate, rather than to hide, information. The result,
as far as the export controls are concerned, is that the software is exempt
from the draconian "Encryption Item" (EI) controls. It is also exempt from
the remaining "encryption software" controls that existed before the EI
controls were imposed. See note to ECCN 5A002, f. and g.

Now, one could argue that this authentication software could be modified by
someone, somewhere, to use encryption for privacy, making it subject to all
the nasty controls above. That's true. But the fundamental principle on
which this export classification is based is that the literal function of
the application -- its intended design -- determines whether it's
classified as authentication or not. Any program, whether it contained
crypto or not, could be modified by a recipient to add encryption features.
That's not the issue; the issue is whether it encrypts for privacy as
exported.

Second, because this software is not under "EI" controls, it qualifies for
exemption from the entire export control regime, because it is publicly
available. Section 732.2 of the Export Administration Regulations (EAR)
says how to determine whether your export is "subject to the EAR". It says:

Sec. 732.2  Steps regarding scope of the EAR.

    Steps 1 through 6 aid you in determining the scope of the EAR.
...
    (b) Step 2: Publicly available technology and software. This step is
relevant for both exports and reexports. Determine if your technology or
software is publicly available as defined and explained at part 734 of
the EAR. Supplement No. 1 to part 734 of the EAR contains several
practical examples describing publicly available technology and software
that is outside the scope of the EAR. The examples are illustrative, not
comprehensive. Note that encryption software controlled for EI reasons
under ECCN 5D002 on the Commerce Control List (refer to Supplement No.1
to part 774 of the EAR) shall be subject to the EAR even if publicly
available. Accordingly, the provisions of the EAR concerning the public
availability of items are not applicable to encryption items controlled
for ``EI'' reasons under ECCN 5D002.
    (1) If your technology or software is publicly available, and
therefore outside the scope of the EAR, you may proceed with the export
or reexport. You have no obligations under the EAR and need not comply
with the EAR. You may skip the remaining steps.

Our software is publicly available, and is not controlled for EI reasons;
in fact it is not controlled at all by ECCN 5D002. Therefore it is outside
the scope of the EAR, and we "have no obligations under the EAR and need
not comply with the EAR."

Government scrutiny of the "crypto-free" software

Trusted Information Systems and Hugh Daniel have been verifying this
analysis for more than a year. On June 7, 1996, TIS submitted a ``Commodity
Jurisdiction'' request to the State Department, which responded on June 26,
1996, with a determination that the State Dept. did not control the export
of their initial prototype's source code (called sec_bind494-b131.tar.gz).
This prototype included subroutine calls to the ``RSAREF'' crypto library,
but did not include the library itself.

TIS then submitted the same source-code prototype to the Commerce
Department for a Commodity Determination on August 26, 1996, to see what
controls might apply to it there. The September 17 Commerce Department
response concluded that the item was eligible for the "General Software
Note" (GSN). This Note permits free export to virtually any location of
software that is available in the mass-market or is "public domain"
(available to the public). (TIS got a second identical response a day
later, listing a different Division Director, for some administrative
reason.)

This permitted TIS to put their prototype implementation up for downloading
by anyone outside of Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria
(and also resulted in a handsome T-shirt). Here is the announcement of the
exportability of the TIS release.

Government scrutiny of the Integrated software

The "crypto-free" configuration is not the final configuration we expect to
release for production use of Secure DNS. The final configuration will be
much easier to use if it includes the cryptographic library or libraries
directly in the BIND source and/or object files.

Therefore, we integrated the RSAREF cryptography library into a new
prototype DNSSEC release. This release includes the full source code of the
TIS DNS Security version of BIND, and the full source code of the RSAREF
cryptographic library. All this source code is unmodified, except for small
changes in the Makefiles to make them build together. The result is a
single distribution which provides complete source code for authenticated
domain name services.

Hugh Daniel and his lawyer Lee Tien submitted his December 15, 1996 CJ
Request for the ``Integrated'' release, to the State Department.

At that time, the State Department had just learned that its export-control
regime was unconstitutional, so it replied with a cover letter and a
Returned Without Action note, suggesting that we re-apply to the Commerce
Department, which was in the process of picking up full responsibility for
the crypto export controls.

Hugh and Lee therefore submitted their April 25, 1997 Classification
Request to the Commerce Department (along with an 8-page explanatory
letter), again for the ``Integrated'' release. The June 4, 1997 Commerce
Dept response gives the software a classification of "EAR99". The note on
the back says, "For items classified EAR99, see part 746 of the EAR to
determine the licensing requirements." As explained in another document
from the Commerce Dept, ``...EAR99. If this item is `publicly available'
within the meaning of section 734.3 of the EAR, whether or not in
electronic media described in the Notes in paragraphs (b)(2) and (b)(3)
following section 734.3 of the EAR, then it is not subject to the EAR.''

Conclusion

You can download the exact software that the Government gave export
permission for, from this web site. While this version of the software is
not suitable for production use, it may help advanced or experimental sites
to generate their keys, and to experiment with signing their zones and
validating the signatures on the zones. Later versions of this software
will be equally exportable, as long as they only authenticate and are
publicly available. The later versions are being integrated into BIND, and
production users should get those releases when they become available.

Many people in the export-control world are shocked and amazed that the
full source code for publicly available authentication applications is
exportable. They've probably been listening to NSA. The agency is famous
for "informal" advice containing self-serving lies about just what the
export controls control. If you want to know what the export controls
really control, make a formal request to the agency that interprets the
controls (at this point the Commerce Dept), or ask a Federal court. We not
only read the regulations themselves, which say that authentication is
exportable, and that publicly available authentication is not even "subject
to the EAR"; we also formally asked those same questions of the Government,
and got the answers that match our understanding of the regulations.

------------------------------------------------------------------------
Next page: Downloading an early prototype ; Up: Domain Name System Security
home page