Subject: draft-ietf-dnsext-dnssec-gost

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Feb 2010 12:57:26 -0500

I recommend that the document not be approved by the IESG in its 
current form.  Section 6.1 states:

>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.

There has been considerable discussion on the security area 
directorate list about this aspect of the document. All of the SECDIR 
members who participated in the discussion argued that the text in 
6.1 needs to be changed to MAY from SHOULD. The general principle 
cited in the discussion has been that "national" crypto algorithms 
like GOST ought not be cited as MUST or SHOULD in standards like 
DNESEC. I refer interested individuals to the SECDIR archive for 
details of the discussion.

(http://www.ietf.org/mail-archive/web/secdir/current/maillist.html)

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Feb 2010 10:05:42 -0800

At 12:57 PM -0500 2/11/10, Stephen Kent wrote:
>I recommend that the document not be approved by the IESG in its current form.  Section 6.1 states:
>
>There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that "national" crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion.
>

As usual, I agree completely with Steve Kent. Further, I note that while there was consensus in the DNSEXT WG to put this document on standards track, there was no such consensus for making every DNSSEC implementation come under a new SHOULD-level requirement.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 11 Feb 2010 15:11:27 -0500

On 11/02/2010 12:57 PM, Stephen Kent wrote:
> There has been considerable discussion on the security area directorate
> list about this aspect of the document. All of the SECDIR members who
> participated in the discussion argued that the text in 6.1 needs to be
> changed to MAY from SHOULD. The general principle cited in the
> discussion has been that "national" crypto algorithms like GOST ought
> not be cited as MUST or SHOULD in standards like DNESEC. I refer
> interested individuals to the SECDIR archive for details of the discussion.
>

As a document shepeard I have made note that this is desired, but at
the same time this is a topic that was outside the scope of the working
group.
This is on the other hand a topic that belongs in the IETF review.

So my questions to the IETF (paraphrashing George Orwell)

"Are all crypto algorithms equal, but some are more equal than others?"

Who gets to decide on what algorithms get first class status and based 
on what criteria?

Steve brought up "national" algorithm, but we have also "personal" 
algorithms such as curve25519 or threefish.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Feb 2010 16:04:34 -0500

> Who gets to decide on what algorithms get first class status and based  

Without wanting to put words in Olafur's mouth, it seems to me that a
couple details are needed as background to focus this debate.  

At the moment, the only way to add a new algorithm to DNSSEC is
standards action.  So in order to add GOST, we have to have a
standards-track document.

We also have the problem that DNS clients cannot negotiate their
algorithms with the other end of the communication.  Moreover, the
natural fallback -- use a "MAY" algorithm by preference, but include a
MUST algorithm so that everyone can verify your signatures -- will
increase the size of DNS responses.  Alternatively, one can use a
"MAY" algorithm only, but with the knowledge that a substantial number
of people might not be able to validate (so they'll treat the answer
as unsecured, and not get the benefit of DNSSEC).

So the question here is not what algorithms get "first class" status
in general, but whether we want to have different classes of support
for DNSSEC, given the current conditions.  

Thanks and best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Feb 2010 13:24:05 -0800

>for DNSSEC, given the current conditions. 

First off, thank you for better stating the question.

There are a plethora of signing algorithms. Note that a signing algorithm consists of a public key algorithm *and* a hash algorithm.

The question here is whether they also have SHOULD-level requirements to process every signing algorithm that is in the IANA registry. Having such a requirement gives attackers a much wider target: in order to spoof a signature, they can pick the weakest of a large collection of algorithms.

For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512. The GOST algorithms have had much less cryptographic review than other algorithms. If that attack becomes practical, an attacker can create signatures using GOST that he/she could not create in RSA/SHA-256 or RSA/SHA-512.

Given this, the answer to the question should be "no, not all algorithms automatically get SHOULD-level requirements". The IETF can, on a case-by-case basis, decide if they want to update the base DNSSEC spec to include a SHOULD-level or MUST-level requirement for a new signature algorithm.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 11 Feb 2010 17:00:00 -0500

I agree with Steve's and Paul's analyses.

In addition, it's not clear to me how this SHOULD-level requirement  
squares with the IANA registration of this algorithm as OPTIONAL (in  
Section 8), since in RFC 2119 OPTIONAL == MAY.  The document that  
defines that registry (draft-ietf-dnsext-dnssec-registry-fixes) does  
not allow algorithms to be RECOMMENDED, so it seems like the  
requirement for support has to be either a MUST or a MAY to be  
consistent with the registry.

--Richard

On Feb 11, 2010, at 4:24 PM, Paul Hoffman wrote:

> There are a plethora of signing algorithms. Note that a signing  
> algorithm consists of a public key algorithm *and* a hash algorithm.
>
> The question here is whether they also have SHOULD-level  
> requirements to process every signing algorithm that is in the IANA  
> registry. Having such a requirement gives attackers a much wider  
> target: in order to spoof a signature, they can pick the weakest of  
> a large collection of algorithms.
>
> For example, there is already a published attack on the GOST hash  
> function that does not exist in SHA-256 and SHA-512. The GOST  
> algorithms have had much less cryptographic review than other  
> algorithms. If that attack becomes practical, an attacker can create  
> signatures using GOST that he/she could not create in RSA/SHA-256 or  
> RSA/SHA-512.
>
> Given this, the answer to the question should be "no, not all  
> algorithms automatically get SHOULD-level requirements". The IETF  
> can, on a case-by-case basis, decide if they want to update the base  
> DNSSEC spec to include a SHOULD-level or MUST-level requirement for  
> a new signature algorithm.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Feb 2010 23:43:57 +0100 (MET)

> details of the discussion.

I agree with Stephen Kent.  That needs to be a MAY.

GOST is IMHO _not_ mature enough and not sufficiently understood and
availble to justify a SHOULD or RECOMMENDED for its support/use
in a core internet protocol.

Over the past year we had our SSL/TLS supplier add support for GOST
TLS ciphersuites to add OEM SSL/TLS implementation (in form of a
third-party crypto plugin that can be certified by the relevant
russian authorities).

One of the problems with GOST is its lack of availability of
documentation/specification and the meaning, purpose and
characteristics of algorithm parameters.

Admittedly, I know very little about the cryptographic
details, but there are two GOST signature algorithms
(GOST R34.10-1994 and GOST R34.10-2001). The earlier
appears to bear some similarity with DH, the newer appears to bear
similarity with ECDH.  Whether and how much the -1994 version is
deprecated is also a complete mystery.  There are IETF documents listing
specific algorithm Identifier parameters (sets), referenced by OIDs,
and those OIDs are issued by one particular company.  I haven't
seen any documentation about the characteristics, purpose of
these algorithm parameters sets and the means/process to define
other parameter (sets).

-Martin

---

From: Michael Dillon <[email-masked]>
Date: Thu, 11 Feb 2010 23:39:10 +0000

> characteristics of algorithm parameters.

A bit of Googling turned up this <http://vsegost.com/Catalog/96/9658.shtml>
with scanned GIFs of ГОСТ Р34.10-1994. There is a link to the other one,
ГОСТ Р34.10-2001 on that page as well. This does seem to document
the parameters.

Is the real problem the lack of English language documentation?
If so, I'm sure that the people who would like to use these algorithms
could arrange for translations of the two documents, and perhaps even
make that an individual submission as an Internet draft.

>  Whether and how much the -1994 version is
> deprecated is also a complete mystery.

That may be explained by its use in card payment systems. As you may
know if you follow the news, a Cambridge team has just found a HUGE hole
in the UK's chip and pin payment system, but a subtext of that announcement
is that other weaknesses documented in previous years still have not been fixed.
Signature algorithms used in payment systems get embedded in all kinds
of devices, and software systems, making it hard to deprecate stuff fast.

--Michael Dillon

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Feb 2010 19:03:45 -0500

> make that an individual submission as an Internet draft.

English translation, I don't believe, is the problem.  The following 
drafts are the English translations of the [GOST3410] and [GOST3411] 
references:

http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-07
http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08
http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost2814789-06

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Feb 2010 01:09:34 +0100 (MET)

> http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost2814789-06

I'm having difficulties to find answers to relatively simple
questions:

 - for which key sizes are the algorithms defined?

 - which parameter of the algorithms (-94, -2001) is used to
   characterize the key size?

-Martin

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Feb 2010 20:16:00 -0500

>    characterize the key size?

Disclaimer: I'm not an expert on GOST.

Section 5 of http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06 
says the GOST public key size is 512 bits.

spt

---

From: Basil Dolmatov <[email-masked]>
Date: Fri, 12 Feb 2010 15:00:35 +0300

Martin Rex пишет:

> similarity with ECDH.  

> deprecated is also a complete mystery.  
It is written in the text of GOST -2001

>  2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of
    12.09.2001 issued by the Russian federal committee for standards.

    ...

    4. GOST R 34.10-2001 replaces GOST R 34.10-94.

So, GOST -1994 for digital signature _is_ deprecated and replaced from 
12.09.2001.

The transition period is not stated explicitly because it is obvious 
from standard procedure of certification in Russia.

No certificate can be issued for any hardware/software using -1994 
algorithm after 12.09.2001 and the certification period is 3 years.

So, after 12.09.2004 there can be no operating hardware/software using 
-1994 algorithm.

Just that simple. ;)

dol@

---

From: Basil Dolmatov <[email-masked]>
Date: Fri, 12 Feb 2010 15:12:30 +0300

Paul Hoffman пишет:

> 
> For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512. 

That "attack" lessens the complexity of building of the collision from 
2**128 operations to 2**109 operations (infinitesimal part of overall 
complexity) and demands padding the meaningful message with several 
kilobytes of additional binary data, which is impossible for any message 
with fixed format.
>The GOST algorithms have had much less cryptographic review than other algorithms. 
...have had much less _published_ cryptographic review... I would say. ;)

These algorithms were thoroughly and intensively reviewed by specialists 
  throughout the world during all years of their existence.

The fact that these algorithms are used without changes for 20, 15 and 
10 years respectively shows that these reviews were not successful.

> If that attack becomes practical, an attacker can create signatures using GOST that he/she could not create in RSA/SHA-256 or RSA/SHA-512.
That "attack" cannot become practical and you know that as well as 
everyone who works with cryptography.

dol@

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Feb 2010 12:18:40 +0000

I agree with Steve and others saying that MAY is appropriate
for this.

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Feb 2010 10:39:27 -0500

> ...have had much less _published_ cryptographic review... I would say. ;)

I am not a security expert, but I've never met one who thought that
unpublished cryptographic review was worth a dime.  Moreover, for the
purposes of the IETF, if something isn't published it might as well
not exist: we have no way of knowing one way or the other.

If you mean "published to a limited and vetted community of
NDA-covered experts", that might yield different conclusions about the
value of the review (depending I guess on how free those experts think
they are to disagree).  But it would have no effect on the value of
those reviews for IETF purposes, which just depends on the publication
(and, actually, publication in a language the community can
understand).

I have no feelings about the merits of the algorithm.  But there are
too many side issues in this discussion already without us getting
into a battle of whether the review is adequate: the reviews aren't
apparently available as far as this community is concerned,
unfortunately, even if they've been done

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Feb 2010 10:57:56 -0500

>"Are all crypto algorithms equal, but some are more equal than others?"

not all are equal, from a purely cryptanalytic perspective. Among those that
may be equivalent from that perspective, there are other meaningful 
differences, e.g., how widely are the algs implemented and used.

>Who gets to decide on what algorithms get first class status and 
>based on what criteria?

If we look at what the CP developed in the SIDR WG for the RPKI says, 
the answer is the IESG (going forward, after an initial set of algs 
are adopted based on the SIDR WG process). In the IPSEC, TLS, and 
SMIME contexts, the WGs themselves have made the decisions, which the 
IESG then approves by virtue of the usual standards track RFC 
approval process. I do not believe that the criteria have been 
documented uniformly across these WGs.

>algorithms such as curve25519 or threefish.

WGs like IPsec, TLS, and SMIME have been able to say no to "personal" 
algs for a long time.

Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Feb 2010 17:13:04 +0100 (MET)

> So, GOST -1994 for digital signature _is_ deprecated and replaced from 

I'm still quite confused.

All references to GOST signature algorithms of the kind [GOST3410] 
ought to be fixed to say [GOST3410-2001].

It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994
and the hash/digest algorith GOST R34.11-1994 that is still being used
for signatures with GOST R34.10-2001.

RFC-4357 was published in January 2006, i.e. after GOST signature
algorithm R34.10-1994 algorithm was deprecated (12.09.2001) and
after which is must no longer be used (12.09.2004) according to
your description.  The GOST TLS ciphersuite document still defines
and uses the deprecated signature algorithm...

IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994
before publication if what you describes really applies to this algorithm.

Unfortunately, rfc-4357 does _not_even_mention_ that GOST R34.10-1994
is deprecated and must no longer be used, and is at the same time
abiguous about the name of the Hash algorithm.  The table of
contents and section heading call it only GOSTR3411.

Regarding key size confusion of the old signature algorithm
in rfc-4357:

GOST R34.10-94:
 non given    RFC-4357  5.1. VKO GOST R 34.10-94
 512 or 1024  RFC-4357  8.3. GOST R 34.10-94 Public Key Algorithm Parameters

GOST R34.10-2001:
 512          RFC-4357  5.2. VKO GOST R 34.10-2001
 none given   RFC-4357  8.4. GOST R 34.10-2001 Public Key Algorithm Parameters

RFC-4357 Security Considerations says the following about the
parameters sets (for signature and the hash algorithm):

   Use of the test parameter sets or parameter sets not described herein
   is NOT RECOMMENDED.  When different parameters are used, it is
   RECOMMENDED that they be subjected to examination by an authorized
   agency with approved methods of cryptographic analysis.

Which is not really helpful.  Any specification referencing rfc-4357
will now have to declare which kind of parameter sets (as defined in
rfc-4357) should be used/accepted for which purpose and which
parameter set is the default.

The purpose, existance and semantics of the "test" algorithm parameter
sets are particularly confusing.

-Martin

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Feb 2010 08:50:28 -0800

On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
>> Who gets to decide on what algorithms get first class status and based on what criteria?
> If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG

So, they're going to flip a coin or what?

"Who" is largely irrelevant.  The criteria is the interesting bit.

>> Steve brought up "national" algorithm, but we have also "personal" algorithms such as curve25519 or threefish.
> WGs like IPsec, TLS, and SMIME have been able to say no to "personal" algs for a long time.

IPsec, TLS, and SMIME are all one-to-one.  DNSSEC (in this context) is one-to-many.

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Feb 2010 14:18:29 -0500

At 10:57 -0500 2/12/10, Stephen Kent wrote:

>If we look at what the CP developed in the SIDR WG for the RPKI says, the
>answer is the IESG (going forward, after an initial set of algs are adopted
>based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs
>themselves have made the decisions, which the IESG then approves by virtue of
>the usual standards track RFC approval process. I do not believe that the
>criteria have been documented uniformly across these WGs.

What is "CP?"

>At 15:11 -0500 2/11/10, Olafur Gudmundsson wrote:

I've asked this before (see 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03057.html): 
what is a "national algorithm?"  I asked that in the DNSEXT WG and 
didn't get a response.  There's a definition in 
http://www.ietf.org/mail-archive/web/secdir/current/msg01343.html but 
from that I can't distinguish between Skipjack (in that it is labeled 
as national) and DES (not-national but "published by [US] NIST as 
FIPS").

But in the bigger picture, for different reasons, I think the 
"SHOULD" in question be removed/changed.  I think it is up to an 
implementor to choose whether they implement something or not, 
support RFC wxyz or not.  And it is up to the RFP write to require it 
or not.  I don't think any RFC can "MUST" itself into existence.

PS - I think Olafur meant "private algorithms" not personal 
algorithms.  See 
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, 
registrations for 253 and 254.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Sean Turner <[email-masked]>
Date: Fri, 12 Feb 2010 14:23:45 -0500

>> criteria have been documented uniformly across these WGs.

Certificate Policy: http://www.ietf.org/id/draft-ietf-sidr-cp-08.txt

spt

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 12 Feb 2010 21:12:46 -0500

> PS - I think Olafur meant "private algorithms" not personal algorithms.
> See
No I meant exaclty what I wrote. "Personal" algorithm is an algorithm 
develeoped by a person or a group of people that are not "state 
sponsored" thus the examples I provided.

	Olafur

---

From: Martin Rex <[email-masked]>
Date: Sat, 13 Feb 2010 03:51:45 +0100 (MET)

> It is written in the text of GOST -2001

Which document are you refering to when you say "text of GOST -2001" ?

This document:

says

section 1.1:

section 1,2:

   GOST R 34.10-2001 is developed to replace GOST R 34.10-94.

> So, GOST -1994 for digital signature _is_ deprecated and replaced from 

That information OUGHT to have been added to rfc-4357 and it ought to be
added to draft-dolmatov-cryptocom-gost34102001-08.

I just found the following paragraph in the Copyright Notice of

on the title page which irritates me:

   This document may not be modified, and derivative works of it may
   not be created, except to format it for publication as an RFC or to
   translate it into languages other than English.

Is there a new trend to have the IETF rubber stamp documents as is?

To me, this statement precludes editorial changes/corrections,
which doesn't sound right.

I boldly assumed the original name of the IETF documents "RFC"
mean "Request For Comment", in the form that the community was
asked for feedback (request for clarifications, correction or
changes) before document was published.

At least this is how I understand "The Tao of the IETF"

http://tools.ietf.org/html/rfc4677#section-8.1

Although the IETF may not have "change control" for the technical
contents described in informational document, a complete absence
of change control of document structure, clarity, detail of
explanation and editorial issues would come as a suprise to me...

-Martin

---

From: Basil Dolmatov <[email-masked]>
Date: Sat, 13 Feb 2010 20:11:44 +0300

Martin Rex пишет:

Basil Dolmatov wrote:

Martin Rex Ð¿Ð¸ÑˆÐµÑ‚:

This document:

says

section 1.1:

section 1,2:

Both statement are right.

...

Why?

Now is 2010, and all implementations of -1994 standard have been
completely phased out more than 5 years ago.

This statement was inserted following the advice of Russ Housley.

The main reason for that was that this text is a _translation_ of the
text of official Russian state standard.

At the moment of its creation this text was thoroughly checked with
authors of original standard for consistency.

Any editorial changes/corrections could diverge the translation from
the original, which is undesirable.

I agreed with this Russ's reasoning.

I do understand that the structure and the style of these documents are
unfamiliar to the significant part of community, but this is because of
the fact it is _a_translation_ of official standard text.

It is not a retelliing or compilation, it is a _translation_.

And it is intended to exist as a reference to the  origin, when
creating further IETF documents, which will be pure IETF documents and
will be commented and edited when necessary.

-Martin

dol@

---

From: Basil Dolmatov <[email-masked]>
Date: Sat, 13 Feb 2010 20:30:06 +0300

Martin Rex пишет:
> All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001].
>   
I think that can de done, despite the fact that there is no other 
algorithm coded as GOST 3410, except GOST 34.10-2001.
> for signatures with GOST R34.10-2001.
It seems that no mixture takes place. Signature standard has number 
34.10, hash standard has number 34.11.
I cannot see how they can be mixed up.

> before publication if what you describes really applies to this algorithm.
I think that is a question to authors of RFC4357 and I think that 
corrections should be issued.

> parameter set is the default.
Yes. And this is done in the draft text. Read it.

>  Corresponding public key parameters are those identified by
>    id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357 <http://tools.ietf.org/html/rfc4357>],
>    and the digest parameters are those identified by
>    id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357 <http://tools.ietf.org/html/rfc4357>].
>   
No confusions, no ambiguity.
> sets are particularly confusing.

Document -
> draft-ietf-dnsext-dnssec-gost-06
does not use any "test" parameters from RFC 4357 and does not reference 
any of them.

HTH,

dol@

---

From: [email-masked]
Date: Sat, 13 Feb 2010 11:23:01 -0800 (PST)

> I agree with Steve and others saying that MAY is appropriate

This looks like the right approach to me as well.

				Ned

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Feb 2010 15:20:12 +0100 (MET)

Basil Dolmatov wrote:
> > All references to GOST signature algorithms of the kind
> > [GOST3410] ought to be fixed to say [GOST3410-2001].
>    

The problem is that there are IETF documents like rfc-4357 and like
the (currently expired) GOST TLS ciphersuites draft that still list
GOST R34.10-1994 as a valid algorithm.

> I cannot see how they can be mixed up.

I'm sorry for the typo.  I meant to say that *I* mixed them up because
of their inconsistent naming throughout the GOST-related documents
that have been publshed as I-Ds and RFC.

That comes mainly from the goof-up in rfc4357 that leaves out the
-1994 appendix to the hash algorithm in the section header/contents
and tag name.

> corrections should be issued.

There is no correction process for RFCs.

Preferably the new document about GOST R34.10 signature algorithms
should be merged with rfc4357 into rfc4357bis, and this time the
GOST R34.10-1994 algorithm should only be mentioned in the Security
Considerations as having been completely retired/phased out in 2004.

> Yes. And this is done in the draft text. Read it.

OK, I'm sorry.  For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of draft-ietf-dnsext-dnssec-gost-06.  However, it does _NOT_ say what to
do if GOST R34.10-2001 signatures with other parameter sets are encountered.

I was confused by the I-D about the GOST R34.10-2001 digital signature
algorithm, where the possible parameters sets and their meaning are
specified to be pretty unspecified (page 7):

   GOST R 34.10-2001 does not determine the process of generating
   parameters needed for digital signature scheme. Possible sets of
   these parameters are defined for example in [RFC4357].

> 
> Document - draft-ietf-dnsext-dnssec-gost-06 does not use any "test"
> parameters from RFC 4357 and does not reference any of them.

The dnssec document references rfc4357 for the definition of
the parameter sets, but fails to define what to do if signatures
with other parameter sets than the default/preferred one are
received.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Feb 2010 09:42:12 -0500

>>criteria have been documented uniformly across these WGs.

Sorry for the acronym ambiguity. the CP is the certificate policy 
(for the RPKI).  Every major PKI has a CP. These documents follow the 
outline provided in RFC 3647.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Feb 2010 09:44:16 -0500

>"Who" is largely irrelevant.  The criteria is the interesting bit.

Both issues are relevant. Most of the other WGs dealing with this 
issue have been in  the secruity area and feel comfortable making 
these decisions. The IESG has been comfortable with their decisions. 
Note that change have been made, for other than technical reasons, 
e.g., initially TLS had DH 7 DSA as MUST and RSA as SHOULD, because 
of patent issues.  When the RSA patent expired, the roles were 
reversed. So the IESG has been an active participant in these 
decisions in the past.

>  >> Steve brought up "national" algorithm, but we have also 
>"personal" algorithms such as curve25519 or threefish.

Your observation is applicable to IPsec, not to S/MIME, and, for 
practical purposes, not for TLS.  An S/MIME message may be sent to 
multiple recipients, so it is not literally one-to-one. S/MIME 
accommodates algorithm diversity best for the public key algorithms 
used to encrypt the content encryption key.  It also can accommodate 
diversity for the algorithm used to sign the message, but at a higher 
cost. It does poorly if different recipients make use of different 
content encryption algorithms. TLS is nominally 1-1, but in reality, 
the vast majority of TLS use is for access to web sites that have a 
very diverse set of clients. That requires a small set of mandatory 
algorithms, to ensure interoperability.  Finally, the question  posed 
was about how have decisions on which algorithms are mandatory to 
implement have been decided in the IETF in the past. My reply 
addressed that question.

---

From: "Rex, Martin" <[email-masked]>
Date: Mon, 15 Feb 2010 16:09:17 +0100

> -----Original Message-----
> 	This document:
> 	
> 	  

:-)

Both statements are completely useless.

AES is a replacement/successor to DES.
SHA-2 is a replacement to SHA-1.  So what?

Getting rfc-4357 published without the slightest indication
that the acceptibility of GOST R34.10-1994 had already expired
2 years before is a serious problem in that document.

What really confuses me is that software that there are
GOST toolkits shipped even today that support GOST R34.10-1994.

OpenSSL also contains an implementation of GOST R34.10-1994
and the GOST TLS ciphersuites draft also contains a ciphersuite
with a GOST R34.10-1994 signaturer algorithm.

In effect, whether and how much GOST R34.10-1994 is deprecated
remains a complete mystery.

> So, GOST -1994 for digital signature _is_ deprecated and
> replaced from 12.09.2001.
> 		
> The transition period is not stated explicitly because it is
> obvious from standard procedure of certification in Russia.

I would like to remind you that we are the IETF here, and
that implementations of DNS-SEC must remain possible without
an official certification in Russia.

DNS-SEC would not make much sense if it could not be used
by implementations that are _not_ certified in Russia.

> Now is 2010, and all implementations of -1994 standard have 
> been completely phased out more than 5 years ago.

There seems to be a disagreement between this statement and
reality.

The GOST crypto toolkit shipped by the Company CryptoPro
(author behind rfc-4357 and draft-chudov-cryptopro-cptls-04)
still implements GOST R34.10-1994, and both documents
list GOST R34.10-1994 in a fashion that does _NOT_
suggest that this algorithm may no longer be used.

The GOST implementation in OpenSSL, provided by a different
russian company, also implements/provides GOST R34.10-1994.

> The main reason for that was that this text is a 
> _translation_ of the text of official Russian state standard.
> At the moment of its creation this text was thoroughly 
> checked with authors of original standard for consistency.
> Any editorial changes/corrections could diverge the 
> translation from the original, which is undesirable.
> 

I agree to the intent.

The words that were used are very inadequate and misleading.

This is not the first RFC that represents a republication of
a standard controlled by a different standardization body
or private entity.

Just use something like your explanation instead, and
it will likely have the desired effect on the comments
you receive for this document.

Random other example for how other RFCs have done this:

RFC-2986 (PKCS-10) http://tools.ietf.org/html/rfc2986

   Abstract

   This memo represents a republication of PKCS #10 v1.7 from RSA
   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
   change control is retained within the PKCS process.  The body of this
   document, except for the security considerations section, is taken
   directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.

> 
> I do understand that the structure and the style of these 
> documents are unfamiliar to the significant part of 
> community, but this is because of the fact it is 
> _a_translation_ of official standard text.
> And it is intended to exist as a reference to the  origin, 
> when creating further IETF documents, which will be pure IETF 
> documents and will be commented and edited when necessary.

A republication only makes sense if it is sufficient to
understand and implement the technology.  If you respond
to a request for clarification with

"because it is obvious from standard procedure of
 certification in Russia."

then there may be a significant misunderstanding about
the purpose of informational RFC documents.  That only
makes sense if it is sufficiently complete and clear
to allow for independent interoperable implementations
of IETF protocols.

-Martin

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 08:52:57 -0600

On one point in this discussion...

I'm not saying that everyone will SEE it, but there actually is an errata 
process for RFCs, and the omission of the year-version suffix in RFC 4357 
seems like something that would be really helpful to submit an errata for.

Submission page is at http://www.rfc-editor.org/errata.php.

The errata link does show up on many hyperlinked versions of RFCs, so things 
aren't as bleak as they were ten years ago, to pick an interval.

Thanks,

Spencer

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Feb 2010 19:21:57 +0100 (MET)

> algorithm coded as GOST 3410, except GOST 34.10-2001.

Slightly OT:

There some more confusing aspect abouth GOST R34.10-xxxx

The math behind GOST bears some similarities with Diffie Helman (DH).

RFC-4357 describes "VKO GOST R34.10-94" and "VKO GOST R34.10-2001" 
under a section called "Key Derivation Algorithms", and defines
parameter sets for these algorithms.

To me, it looks like the GOST algorithms in RFC4357 would be better
described as "Key agreement" instead of "Key Derivation" algorithms
(consistent with the X.509v3 use of the terminology).
In detail, the key exchange algorithm for GOST in TLS seems to
significantly differ from DH key agreement.

What I don't understand is whether the deprecation applies to
GOST R34.10-1994 in general, or only to GOST R34.10-1994 as a
signature algorithm.

I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST R34.10-1994 key agreement
(ephemeral keys) in conjunction with GOST R34.10-2001 certs&signatures,
and if yes -- whether that is still permitted by russian authorities.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Feb 2010 08:31:35 +1100

In message <[email-masked]>, Martin Rex writes
> do if GOST R34.10-2001 signatures with other parameter sets are encountered.

Since each end adds the parameters and they are NOT transmitted this
can never happen.  If one end was to change the parameters then nothing
would validate.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Feb 2010 00:37:37 +0100 (MET)

> can never happen.  If one end was to change the parameters then nothing

OK.  I didn't know anything abouth DNSSEC when I entered the disussion...

Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536
and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering
about the following:

  - the DNS security algorithm tag ought to be GOST R34.10-2001
    and not just "GOST"

  - DSA and the expired ECC draft spell out the entire algorithm
    parameters in the key RRs, which preclues having to assign
    additional algorithm identifiers if a necessity comes up to
    use different algorithm parameters.

    Wouldn't it be sensible to do the same for GOST R34.10-2001 keys --
    i.e. list the parameter set as part of the public key data?
    Given the procedure of the standardization body that defines GOST
    the parameter set OID could be used in alternative to spelling
    out each of the element in the parameter set in full.
    Implying the paramter set A for the GOST R34.10-2001 algorithm does
    not seem very "agile", given the limited number range for the algorithm
    field in DNS security.

Given the differences between -1994 and -2001 versions,
any successor GOST R34.10-201X standard may not be able to reuse
the DNSKEY record anyway and need a new algorithm identifier.
And at that point, an unqualified label "GOST" would become
ambiguous. 

As previously mentioned, current uses of GOST R34.11 should be
changed to GOST R34.11-1994 as well (prevent ambiguity with a
future/updated hash algorithm for GOST).

-Martin

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Feb 2010 19:43:50 -0500

On 15/02/2010 6:37 PM, Martin Rex wrote:
> Mark Andrews wrote:
>>
>> In message<[email-masked]>, Martin Rex writes
>> :

This is a good point, adding a version label is a possiblity in this
case or just in the future cases, but I think slapping one on
this is fine.

>      use different algorithm parameters.
DSA did not cover the case if the key is > 1024 bit.
ECC draft was killed due to the fact it was impossible to guarantee that
a implementation supporting ECC would be able to handle all the
possible curves that the proposal allowed.

>      not seem very "agile", given the limited number range for the algorithm
For interoperability reasons we WANT MINIMAL flexibility for 
implementors/users. Thus we stripped all that out and picked ONE
possible GOST/2001 curve.

> And at that point, an unqualified label "GOST" would become
see above,

	Olafur (document shepeard)

---

From: Basil Dolmatov <[email-masked]>
Date: Tue, 16 Feb 2010 13:18:48 +0300

Martin Rex пишет:

> GOST R34.10-1994 in general, 
Yes.
> or only to GOST R34.10-1994 as a
> signature algorithm.
No.
> (ephemeral keys) in conjunction with GOST R34.10-2001 certs&signatures,
Never ever interested. ;)
> and if yes -- whether that is still permitted by russian authorities.
No.

I should correct myself, the check against relevant documentation showed 
that it was more prolonged grace period allowed by authorities.

The usage of GOST R 34.10-94 is fully prohibited starting 1 of January 2008.
With one exception: it is allowed to check signatures under already 
signed archived documents using this algorithm.

As for TLS, using GOST R 34.10-94, this is fully non-compliant to 
Russian standards and should not be used.

Definitely, noone can be obliged to follow this outside the Russia or 
when using crypto in home environment or something of the kind.

Nevertheless, I would consider following this as a strong guideline 
because of two thoughts:
  - first of all, I think there was some reason for creating and putting 
into operation of new standard, spending a lot on its preparation and 
transition to it (consider GOST 28147-89, which is active for 20 years)
  - no certified software/hardware will support deprecated algorithm, so 
there definitely will interoperability problems.

I would like to return to topic, which concerns with the document 
describing the DNSSec extension with GOST algoritm.
This document quotes RFC4357 as a reference to the used parameter set. 
Nothing more.

This document uses the only valid set of GOST algorithms for the purpose 
of usage in the DNSSec . In this document no TLS is used, no key 
agreement procedures are used, etc.

dol@

============ new topic ========

I think that the representation of GOST algorithms in IETF is relatively 
poor now. There should be several other documents which makes the 
structure and usage of these algorithms more clear for those who will be 
willing to implement it and for those who suddenly found it been 
implemented in his/her software/hardware already.
This work has been already started from publication of standards' 
translation to English as Informational RFCs to have some basiv 
reference point. Then, there should be other document, describing 
implementation of GOST algorithm in detail in the manner to which IETF 
community is used to (The style of Russian standards is really hard for 
comprehension). There will be a lot of issues (defining scopes, fixing 
parameter sets, setting OIDs, ensuring non-controversity with existing 
implementations, etc.) which have to be solved when preparing this 
document, some of them were quoted in different GOST-relevant 
discussions. All of these comments are carefully collected and I hope 
will help a lot when preparing this document.

dol@

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Feb 2010 08:53:53 -0500

No hat.

> Never ever interested. ;)

To address Martin Rex's point, however, we would not need to know
whether the draft's editors were ever interested, but whether it is
technically possible.  This seems like a good (and so far unanswered)
question.

> The usage of GOST R 34.10-94 is fully prohibited starting 1 of January 2008.

Certainly, this prohibition is irrelevant.  We are not offering
technical interoperation documents _for a particular legal framework_,
but technical interoperation documents _for the Internet_.  The
documents must therefore assume that, if someone can come up with a
bad idea that is nevertheless consistent with the document in
question, someone will.  (If you doubt this, please examine the
Internet -- pretty much any part of it you like -- more carefully.)

So I think Martin's question is appropriate, and his suggestion
up-thread to be a good one.  The more specific the document can be
made, the better for all concerned.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Feb 2010 16:03:32 +0100 (MET)

> technically possible.  This seems like a good (and so far unanswered)

I'm sorry for the confusion and off-topic that I created in the discussion.

The dnssec-gost document appears to be OK in being very explicit and
constrained in its usage of GOST, requiring the GOST R34.10-2001
signature algorithm and implying a single parameter set (A) for
the signatures.

The deprecated GOST R34.10-1994 algorithm is a non-issue for dnssec-gost.
Ensuring that no reference to GOST signatures is without R34.10-2001
qualifier in the document should be sufficient to prevent any potential
confusion.

The use of GOST R34.11 for the hash algorithm should probably also be
changed to include the year GOST R34.11 to prevent confusion with
any future hash algorithms in the GOST R34.11 series.

Mandating a particular parameter set for an ECC crypto algorithm
is perfectly OK for interop.  Whether or not to include
a parameter set identifier in the DNS KEY RR is up to the DNSext
working group (Implementations of GOST are likely to know
all three GOST R34.10-2001 parameter sets listed in rfc-4357).

The byte order of GOST-related values seems to be confusing:

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-3

   Quoting RFC 4490:

   "The signature algorithm GOST R 34.10-2001 generates a digital
   signature in the form of two 256-bit numbers, r and s.  Its octet
   string representation consists of 64 octets, where the first 32
   octets contain the big-endian representation of s and the second 32
   octets contain the big-endian representation of r."

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-4

   4. DS Resource Records

   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
   type {TBA2}.The wire format of a digest value is compatible with
   RFC4490 [RFC4490], that is digest is in little-endian representation.

Since there are already RFCs out there using GOST (CMS) and there
are implementations based on drafts (TLS) and maybe some under
evaluation (XMLsec) it seems a little late to ask for "pure"
ordering at this point in time.  Re-using the format/ordering
that is used in existing documents/protocols and implementations
appear to be OK to _me_.  IETF protocols provide more flexibility
at this point than e.g. ASN.1.  To me, it looks like there is
a little mess in GOST byte ordering in various usage scenarios,
so _I_ would not expect interop without interop testing, no matter
what ordering DNSsec defines. :-/

I really appreciate the mentioning of key and hash sizes in the
dnssec-gost document in section 5, because one can not easily
"look it up" in rfc-4357.  (It's in there, but not easy to determine).

-Martin

---

From: Phillip Hallam-baker <[email-masked]>
Date: Mon, 15 Feb 2010 12:59:58 -0500

Perhaps it would help elucidate matters if we knew the precise criteria

In particular, is the requirement to support Gost or is it that all  
the algs used be approved

If the second case 1) what would be the root zone criteria and 2)  
would these regulation issues disappear if the root zone were  
differently managed?

Sent from my iPhone

---

From: Phillip Hallam-baker <[email-masked]>
Date: Mon, 15 Feb 2010 13:09:56 -0500

One point that seems to be ambiguous here is what the role of an rfc  
is with respect to defacto standards status

In theory informational rfc do not establish or modify standards. In  
practice the broken process that stops anything being a standard and  
makes those we do have obsolete means that this is not obvious

In my view a should or must in an informational rfc only has scope to  
the document itself. So the gost draft should use MUST or Should in my  
view

But I can see how this could confuse

Sent from my iPhone

On Feb 15, 2010, at 9:52 AM, "Spencer Dawkins" <[email-masked] 
 > wrote:

> I'm not saying that everyone will SEE it, but there actually is an  
> errata process for RFCs, and the omission of the year-version suffix  
> in RFC 4357 seems like something that would be really helpful to  
> submit an errata for.
>
> The errata link does show up on many hyperlinked versions of RFCs,  
> so things aren't as bleak as they were ten years ago, to pick an  
> interval.
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: "Martin Rex" <[email-masked]>
>> > before publication if what you describes really applies to this >  
>> algorithm.
>>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Feb 2010 12:05:21 -0500

> possible curves that the proposal allowed.

To clarify ECC draft killed == draft-ietf-dnsext-ecc-key

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Feb 2010 05:48:40 -0500

> Olafur (document shepeard)
Martin,

Based on your comments and the possible confusion over registering the
memonic "GOST" for DNSSEC, I think it would be wise to change the DNSKEY 
Memonic to "ECC-GOST".

	Olafur (document shepeard)
PS: orignally we registered RSA for RSA/MD5 combination, then we got 
RSASHA1, RSASH256, RSASHA1NSEC3 ......, thus the first registered should 
not get a special shoter name than later variants :-)