Skip to main content

Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
draft-ietf-dnsext-dnssec-gost-07

Yes

(Ralph Droms)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

No Record

(Cullen Jennings)

Note: This ballot was opened for revision 07 and is now closed.

Ralph Droms Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2010-03-18) Unknown
As per Olafur, there is WG consensus not to register the new hashing function in the IANA registry established by RFC 5155. So I am downgrading this to a COMMENT.


6.1.  Support for GOST signatures

   DNSSEC aware implementations SHOULD be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as
   defined in this document.

Use of this SHOULD was debated in details on SecDir mailing list. People has suggested that this should be a MAY. I don't think a choice of SHOULD versa MAY actually matters in this case, because this document doesn't say that it "Updates" RFC 4034 (And I think it a good case should be made that it shouldn't include "Updates: RFC 4034".) and because the document clearly states that the newly registered algorithms are OPTIONAL to support.

Note that I also generally agree with concerns about introducing additional signature/hashing algorithms for use in DNSSEC, however I think that any DNSSEC policy on this is out of scope for the document. And the document is currently silent on this anyway.
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2010-03-17) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2010-03-02) Unknown
  Please consider the comments from the Gen-ART Review by Vijay Gurbani
  on 19-Feb-2010:

  1) In the Abstract, the draft has references of the form
     "[DRAFT1, DRAFT2, DRAFT3]".  I would humbly suggest that
     these be removed from the Abstract and placed in the body
     of the document.  In their current form, these references
     appear, well ... temporary, given their names (DRAFT1, etc.)

     I have come across services that index IETF RFCs and also
     include the abstract in the index.  In that context, having an
     Abstract include references to seemingly impermanent
     placeholders appears disconcerting.  Note that references
     to RFC numbers themselves -- as the Abstract also shows -- is
     okay since RFC numbers denote some sort of permanence.

  2) The references "DRAFT1" etc. seem to best fit in
     Section 1, paragraph 4.
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
(was Discuss) No Record
No Record () Unknown