Subject: Re: [dnsext] WGLC: Gost algorithms for DNSSEC

From: Basil Dolmatov <[email-masked]>
Date: Fri, 06 Nov 2009 14:57:35 +0300

Basil Dolmatov пишет:

>>
>> Document note: The document uses in examples an unallocated DNSKEY 
>> algorithm
>> code 249, when this document is issued as an RFC a different code WILL be
>> allocated, the only use of this code is for early interoperabilty 
>> testing.
> The example of signature in the current text of the draft will NOT check 
> with this protocol code.
> 
> If necessary, working examples for protocol code 249 can be supplied.
> 
Attached are working examples for temporary protocol code 249.

These examples has been cross-checked between two independent 
implementations of GOST in DNSSec (by Cryptocom and by NLNetLabs)

> dol@
--- draft-ietf-dnsext-dnssec-gost-01.txt.orig	2009-10-18 19:51:39.000000000 +0400
+++ draft-ietf-dnsext-dnssec-gost-01.txt	2009-10-30 18:59:19.000000000 +0300
@@ -155,23 +155,24 @@
   
 2.2.  GOST DNSKEY RR Example
 
-   Given a private key with the following value:
+   Given a private key with the following value (the value of GostAsn1
+   field is split here into two lines to simplify reading; in the private key
+   file it must be in one line):
 
    Private-key-format: v1.2
    Algorithm: {TBA1} (GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEE
-             IgQgAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-
-   (corresponding to private key value 1)
+   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S2FXdM
+             tzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
 
 V.Dolmatov              Expires April 18, 2010                [Page 3]
 
    The following DNSKEY RR stores a DNS zone key for example.net
  
-  example.net. 86400 IN DNSKEY 256 3 {TBA1} ( AAABAAAAAAAAAAAAAAAAAAAA
-                                              AAAAAAAAAAAAAAAAAAAAABQe
-                                              n56cyawiseMj3y1PKTV2Kz9F
-                                              WlDfJ9qcmOBx5JGN )
+   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
+                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
+				tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
+				yB7i836EfzmJo5LP
+				) ; key id = 15820
 
 3.  RRSIG Resource Records
 
@@ -209,13 +210,14 @@
 
    Setting the inception date to 2000-01-01 00:00:00 UTC and the 
    expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   should be created (assuming {TBA1}==249 until proped code is 
+   should be created (assuming {TBA1}==249 until proper code is 
    assigned by IANA)
 
-   www.example.net. 3600 IN RRSIG ( A {TBA1} 3 3600
-                    20300101000000 20000101000000 9033 example.net.
-                    96ObOt5gR6Xln8g42w70OZvi6BZoQvLIhrN9F+VBc29mp+ap
-                    DQov1re0hApGenYDd2zLaHecw4H2vnPj0NhhxA== )
+   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
+                                  20000101000000 15820 example.net.
+                                  K4sw+TOJz47xqP6685ItDfPhkktyvgxXrLdX
+                                  aQLX01mMZbJUp6tzetBYGpdHciAW5RLvHLVB
+                                  P8RtFK8Qv5DRsA== )
 
 4.  DS Resource Records
 
@@ -234,8 +236,20 @@
 
 4.1. DS RR Example
 
-   example.net. 3600 IN DS 9033 {TBA1} {TBA2} ( Su0ToNow7Lwex+wqac+cTQ
-                                                djJ733qubhan+KqUrselc= )
+   For key signing key (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   example.net. 86400   DNSKEY  257 3 {TBA1} (
+                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
+                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
+                                9tCz5oSsZl0cL0R2
+                                ) ; key id = 21649
+
+   DS RR will be
+
+   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
+             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
+	     A44649C6 )
  
 5.  Deployment Considerations

---

From: John Schnizlein <[email-masked]>
Date: Tue, 10 Nov 2009 02:49:59 +0900

I support advancing this draft.

On 2009Oct30, at 8:13 AM, Olafur Gudmundsson/DNSEXT chair wrote:

> ... WGLC for draft "Use of GOST signature
> algorithms in DNSKEY and RRSIG Resource Records for DNSSEC"
> URL for the document and its history:
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-gost
> The document is on the standards track.

Unlike Paul Hoffman's (comments in the WG meeting), I am not concerned  
with which track the resulting RFC is on.
I agree with Paul that whatever the track, advancement should enable  
assignment of the code points necessary for implementers to  
demonstrate interoperation.

> ...
> Please read the document carefully, and send comments to the working  
> group.

nit: section 2.1 s/prepend last 64 octets/prepend the last 64 octets/

Rationale: This specification appears to be part of a good-faith  
effort to enable seamless integration of secure entry points (SEPs) in  
the root with already required use of particular algorithms in  
particular circumstances.  The right place for SEPs to simplify  
validation chains is the root.  Accommodating pre-existing local  
requirements, with minimal intrusion on the rest of the community,  
removes an unnecessary barrier to deployment.

I have heard only two objections, which are answered as follows: (1)  
Introducing algorithms that do not have the benefit of global  
examination risks compromise through weak security - but only the  
local zones required to use this algorithm have any reason to incur  
this risk, and they deserve the compromise if they bring it on  
themselves this way. (2) Allocating protocol code-points for a  
narrowly applicable set of algorithms risks depleting the small set  
available to everyone - this specification should be treated as a  
demonstration of feasibility.  If feasibility is demonstrated in  
deployment (the Internet way), the question of what conservation  
policies should apply would be worth investigating.

John

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 10 Nov 2009 10:15:11 +0100

> I support advancing this draft.

+1

> assignment of the code points necessary for implementers to demonstrate
> interoperation.

+1

>> Please read the document carefully, and send comments to the working

The section with the example signature could be improved by adding text 
that the example signature can be verified with an implementation to 
test it.  Generating your own signature produces a different one due to 
a random step in the signature process.

I implemented an experimental signer and validator using openssl 1.0.0 
beta.  It worked with the (updated) examples.

Best regards,
    Wouter

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Nov 2009 19:07:13 -0800

+1

Regards,
-drc

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 14 Nov 2009 06:02:16 +0100

+1

	jakob

---

From: Olafur Gudmundsson/DNSEXT chair <[email-masked]>
Date: Tue, 17 Nov 2009 11:34:29 -0500

Reminder this is an ongoing WGLC that ends later this week.

         Olafur

At 18:13 29/10/2009, Olafur Gudmundsson/DNSEXT chair wrote:

>Dear colleagues,
>
>This note starts a WGLC for draft "Use of GOST signature
>The WG last call is for 3 weeks as it overlaps IETF-76.  The last call will
>end on November 19th at 23:59 UTC.
>
>This document defines the use of GOST R 34.10-2001 digital signature algorithm
>for DNSSEC. The document defines a DNSKEY format for the key, and a format
>for storing the resulting signatures in a RRSIG record.
>
>In addition the document defines a DS digest algorithm based on
>GOST R 34.11-94.
>
>Please read the document carefully, and send comments to the working group.
>
>Document note: The document uses in examples an unallocated DNSKEY algorithm
>allocated, the only use of this code is for early interoperabilty testing.
>
>The document process rules in this group require that at least
>5 members of the working to state that they have reviewed the document
>and there is consensus of support to publish as a Standards Track RFC.
>
>         Olafur & Andrew
>
>
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 17 Nov 2009 12:51:01 -0500

> Reminder this is an ongoing WGLC that ends later this week.

[...]

>> The document is on the standards track.

I have read draft-ietf-dnsext-dnssec-gost-03.

I am not a mathematician, or a cryptographer, or a developer of DNS software. I mention this so that the chairs can assess the degree of expert review the document obtained during this process, as opposed to the more general, amateur review I offer here.

The document seems clear and well-written. It has sufficient examples for me to be able to follow without scratching my head.

The document is currently on the standards track, which seems necessary for (a) code point assignment under the current rules for the DNS Security Algorithm Numbers registry and (b) to update RFC 4034 presumably with the text in 6.1. With respect to (b), I think it might be clearer to call out precisely what updates to 4034 this document provides by putting the text in a clearly-marked section. This is a relatively minor point though, I think.

More generally, I am in favour of GOST as an algorithm being implemented for DNSSEC, and correspondingly in the use of GOST in DNSSEC being specified. This document seems to do a reasonable job at that.

I support advancing this document.

Joe