[dnssec-deployment] [regarding crypto issues on DNSSEC]
dburk at burkov.aha.ru
Sat Apr 4 02:07:40 EDT 2009
bmanning at vacation.karoshi.com wrote:
> Michael (and others) - thisis a snippet from a thread on this topic I
> am having w/ some Russian folks. Now all of this may be moot (OBE) since
> Suzanne indicated that there is yet another pool of folks working on getting
> GOST code points assigned through the IETF. If there is -NOT- a group
> working on that, or they would like some of the inputs from the folks I've
> been talking to, I'd be glad to work w/ them.
it is still the same group (you know all)
- simply during IETF we expanded discussion as we began necessary draft
> ----- Forwarded message from Dmitry -----
> Date: Mon, 02 Mar 2009 20:23:57 +0300
> Subject: regarding crypto issues on DNSSEC
> Current export/import issues related to DNSSEC proposition:
>>> As the key method of providing integrity and authority of records RSA
>>> crypto algorithm to be used.
>>> Because crypto products including software are subject to
>>> import/export/internal usage restrictions lets review some examples.
>>> 1. Here are the thresholds for a U.S. export:
>>> Encryption commodities and software (including key management
>>> products), as follows: for symmetric algorithms with key lengths not
>>> exceeding 80 bits; for asymmetric algorithms with key lengths not
>>> exceeding 1024 bits; and for elliptic curve algorithms with key
>>> lengths not exceeding 160 bits.
>>> If a product exceeded any of these thresholds, that product would be
>>> considered to implement strong encryption functionality.
>>> RSA is an asymmetric algorithms.
>>> IT MEANS THAT PRODUCTS/TECHNOLOGIES USING RSA CRYPTO WITH KEY LENGTH
>>> MORE THEN 1023 BITS ARE SUBJECT FOR EXPORT CONTROL INCLUDING EXPORT
>>> 2. In some counties including Russia, China, France there are import
>>> restrictions for such products/technologies. For example in Russia to
>>> import such products or technologies even for development purpose
>>> there is special permission from FSB (Federal Security Bureau) and
>>> import license from the Ministry of Trade (Russian President decree
>>> 334 from 1995 year).
>>> IT MEANS - LONG DELAY IN IMPLEMENTATION AND SOURCE CODE ANALYSES CAN
>>> BE REQUIRED TO GET IMPORT PERMISSION.
>>> 3. In Russia if Internet Provider will host DNSSEC server he has to
>>> apply for service and technical support license from FSB to work with
>>> crypto (Government decree 957 from 2007 year). In practice FSB will
>>> not give service license for any service based on non-Russian crypto.
>>> IT MEANS - IN PRACTICE USING RSA BASED DNSSEC IMPLEMENTATION IN
>>> RUSSIA CAN BE IMPOSSIBLE
>>> 4. Russian crypto algorithm also published as RFC 4357
>>> IT MEANS - THERE IS NOT A BIG DEAL TO PUBLISH RFC EVEN RELATED TO
>>> CRYPTO. SUPPORT OF ALL WIDELY USED CRYPTO ALGORITHMS LOOKS IMPOSSIBLE
>>> AND USELESS FROM PRACTICAL POINT OF VIEW - A LOT OF WORK BUT DOES NOT
>>> IMPROVE SECURITY AND SCALABILITY.
>>> 5. Having only one root server can be unacceptable at government
>>> level in some countries. So before making such decision it should be
>>> very accurately verified otherwise it can lead to the future internet
>>> segmentation. Message than "no one will take root server offline
>>> because it will be highly visible" has no meaning. War in Iraq was
>>> also highly visible and the most or World was against it. So it
>>> should be several cross-trusted authorities each of them covering
>>> specific country or region and fully operational without others.
>>> IT MEANS - APPROACH TO DNSSEC OR SHOULD ALLOW IN-COUNTRY/REGION
>>> SPECIFICS OR TO BE APPROVED BY ALL COUNTRIES AND REGIONS BY
>>> GOVERNMENT AUTHORITIES.
> "We know about France, China, Brazil and some other countries having
> import restrictions. Also do not forget that there is EXPORT restriction
> almost in all EC countries controlled by Wassenaar agreement.
> If you look into information security section:
> You will see that RSA is considered as export controlled:
> 5. A. 2. a. 1. a. A "symmetric algorithm" employing a
> key length in excess of 56 bits; or
> b. An "asymmetric algorithm" where the security of the algorithm is
> based on any of the following:
> 1. Factorisation of integers in excess of 512 bits (e.g., RSA);
> So - It potential issue MUST be evaluated in advance! And hiving
> multiple equivalent "roots" trusted each other and every of them
> covering particular administrative zone (by country and by
> confederation) can solve such issues."
> ----- End forwarded message -----
> This message is sent to you because you are subscribed to
> the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/>
> and older material is at
More information about the Dnssec-deployment