Subject: [dnsext] GOST algorithms in DNSSEC

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Dec 2009 12:57:19 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Folks,

I am opposed to assigning algorithm identifier values to the GOST 
algorithms, until the WG has solved the alg ID space problem. I 
believe Paul Hoffman suggested this in Hiroshima.

My reasoning is that we need to provide a clear distinction between:

	- algorithms that are MUSTs, i.e.,  mandatory to implement in 
all DNS resolvers and zone signers

	- algorithms that are MAYs

Because we have limited space for algorithm IDs under the current 
design, I think it appropriate to agree upon a scheme that enables 
expansion of the ID space first, and then to assign IDs for these 
these two categories of algorithms.  One might choose to assign the 
two classes of algorithms to two different ID spaces, to reinforce 
this notion, although that may not be necessary.

If alg ID space were not in short supply, this would not be an issue. 
In other security protocol contexts with which I am familiar, we have 
usually avoided this thorny issue. This is because we have adopted 
alg ID schemes that have offer very large (essentially unlimited) 
space, e.g., OIDs. Unfortunately, this is not the case for DNSSEC, 
and thus I believe that it is prudent to proceed with caution.

Steve

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Dec 2009 10:23:04 +1100

> and thus I believe that it is prudent to proceed with caution.

The numeric id space really isn't limited to 256 values.  We just
havn't formalised how to encode those other values yet as there has
not been the need.  If/when we get to the point where we will need
to use those other values it will be straight forward to provide
them.  253 and 254 are examples of how this can be done.

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

---

From: [email-masked]
Date: Fri, 4 Dec 2009 12:33:19 +0100

> believe Paul Hoffman suggested this in Hiroshima.

It is my understanding that there is no Algorithm ID space problem.

> all DNS resolvers and zone signers

There isn't such a requirement at all. The "mandatory to implement" applies
solely to validators. The resolver just resolves. The server just serves.
To those entities, its garbage in, garbage out. It is definitely not
required to implement for zone signers.

>    - algorithms that are MAYs

The sole reason to have a MANDATORY for validators is to gracefully
consider a zone as unsigned if the parent indicates (by the algorithm field
in the DS record) that the child is using an algorithm that might not be
implemented everywhere. The alternative is that all algorithms have to be
implemented in order to prevent BOGUS state.

> these two categories of algorithms.

There is a near unlimited space that allows for assigning algorithms by
allocating part of the signature field. That is standardized for Private
Algorithms (see RFC4034 A.1.1). That is trivially adoptable for any other
algorithm. This is not subtyping.

> One might choose to assign the

I think you may have been misinformed. I hope that this helped you to get
on the right track.

I suggest we allocate an arbitrary (yet unallocated) Algorithm ID to
indicate Extended Algorithm ID, and adopt the Private Algorithms scheme for
that, and have IANA open a registry. No rocket surgery here. This will take
a fraction of the time needed to exhaust the current space.

I'm dismayed that you seriously consider halting current work (GOST) in
order to solve a non-prudent problem. Why wasn't this a problem for recent
work (RSASHA2)?

Regards,

Roy Arends
Sr. Researcher
Nominet UK

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 4 Dec 2009 08:36:25 -0500

> It is my understanding that there is no Algorithm ID space problem.

There could be in the future, but that would depend on a growth of newly
developed algorithms.  It may be easy to come up with 257 unique algorithms,
but I'd like to think the crypto and DNS communities could boil that down to
a handful that are used during any given decade.

> required to implement for zone signers.
insert plug for draft-ietf-dnsext-dnssec-registry-fixes-01 here :)

> a fraction of the time needed to exhaust the current space.
Speaking of OID, has anyone ever used the PRIVATE(OID) space for any
experimentation?  I've heard some other groups wanting to use the DNS for
OID lookups, and was curious about previous DNS-OID collaborations.

I'd support working to have an expansion clause to the algo code in place
now.  I don't know if we'd actually need it, but better safe than sorry?

Scott
 
> order to solve a non-prudent problem. Why wasn't this a problem for recent

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Dec 2009 08:51:26 -0500

> a fraction of the time needed to exhaust the current space.

With my Official Nagger for Work Item Progress hat on, does the above
suggest that we can expect a draft from you outlining this plan?

A

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

---

From: [email-masked]
Date: Fri, 4 Dec 2009 15:49:27 +0100

> suggest that we can expect a draft from you outlining this plan?

Yes,

Regards,

Roy Arends
Sr. Researcher
Nominet UK

---

From: Chris Thompson <[email-masked]>
Date: 04 Dec 2009 15:42:16 +0000

>Stephen Kent wrote on 12/03/2009 06:57:19 PM:
[...]
>algorithm. This is not subtyping.

And in the absence of such information in DS records, how is this part
of RFC 4305 to be interpreted?

| There MUST be an RRSIG for each RRset using at least one DNSKEY of
| each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
| itself MUST be signed by each algorithm appearing in the DS RRset
| located at the delegating parent (if any).

I seem to recall some discussion of this in the context of algorithm 
IDs 253 and 254, and I have expressed concern about the legal values
for the "parameter octets" in draft-ietf-dnsext-dnssec-gost-* for
similar reasons.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: David Blacka <[email-masked]>
Date: Fri, 4 Dec 2009 11:11:56 -0500

On Dec 4, 2009, at 10:42 AM, Chris Thompson wrote:

> I seem to recall some discussion of this in the context of algorithm IDs 253 and 254, and I have expressed concern about the legal values

This is covered in dnssec-bis-updates-09 (http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-09#section-4.3) in section 4.3.

--
David Blacka                          <[email-masked]> 
Sr. Engineer          VeriSign Platform Product Development

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Dec 2009 09:58:14 -0800

This discussion has conflated a bunch of topics and, unfortunately, multiple WG documents.

The WG LC on the GOST algorithms is to advance what is now draft-ietf-dnsext-dnssec-gost-05 as a standards track document.

The WG work item draft-ietf-dnsext-dnssec-alg-allocation-00, on which there has been almost no comment, allows non-standards-track RFCs to have IANA code points allocated to them without having to resort to the private code points.

The WG work item draft-ietf-dnsext-dnssec-registry-fixes-01, also thinly discussed, would add a column to the IANA registry to describe the status for use of the various algorithms.

As I said in Hiroshima, I think that draft-ietf-dnsext-dnssec-gost-05 should not progress on standards track for many reasons, but I do think it should be published as an Informational RFC. At least one of the people who responded in favor of moving the GOST document forward admitted to me that they did not notice that it was for standards track (even though that was made clear in the WG LC message).

If draft-ietf-dnsext-dnssec-gost-05 progresses as an Informational RFC concurrent with or after draft-ietf-dnsext-dnssec-alg-allocation-00 becomes an RFC, the GOST algorithms can be assigned regular code points. If it happens concurrent with or after draft-ietf-dnsext-dnssec-registry-fixes-01 becomes an RFC, the GOST registration will be clear in the IANA registry.

Therefore, I propose that either the WG chairs stop the current GOST WG LC so that the WG can be sure that a non-standards-track algorithm will be given a code point (as many people want), or should re-issue the WG LC to specifically ask what standards level respondents want for this document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Fri, 4 Dec 2009 13:48:53 -0500

> Therefore, I propose that either the WG chairs stop the current GOST WG LC so that the WG can be sure that a non-standards-track algorithm will be given a code point (as many people want), or shoul…

I'm not sure I understand the merit of stopping the WGLC on whether to promote the draft on the standards track. If the WGLC concludes that standards track is fine, then surely it can just proceed as-is.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Dec 2009 14:09:58 -0500

On Fri, Dec 04, 2009 at 09:58:14AM -0800, Paul Hoffman wrote:
> Therefore, I propose that either the WG chairs stop the current GOST
> WG LC so that the WG can be sure that a non-standards-track
> algorithm will be given a code point (as many people want), or
> should re-issue the WG LC to specifically ask what standards level
> respondents want for this document.

The Chairs put the question according to the procedures available to
us at the time the question was put.

In the event there is some future state of affairs in which we might
put a different question to the WG participants, then perhaps we would
do so.  But as things stand, the participants have been invited to
express their views with respect to the document, assuming that it
must be on the standards track.  The question is not withdrawn.

Best regards,

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Dec 2009 12:08:05 -0800

>I'm not sure I understand the merit of stopping the WGLC on whether to promote the draft on the standards track. If the WGLC concludes that standards track is fine, then surely it can just proceed a…

Quite right. Note, however, that the main motivation for the other two documents was people who had no-so-positive feelings for the GOST suite (the very limited implementation experience, the known weakness in the hash algorithm, and so on).

--Paul Hoffman, Director
--VPN Consortium

---

From: John Schnizlein <[email-masked]>
Date: Fri, 4 Dec 2009 15:47:01 -0500

On 2009Dec4, at 3:08 PM, Paul Hoffman wrote:

>>> The WG LC on the GOST algorithms is to advance what is now draft- 
>>> ietf-dnsext-dnssec-gost-05 as a standards track document.
>>>
>>> [...]
>>>
>>> Therefore, I propose that either the WG chairs stop the current  
>>> GOST WG LC so that the WG can be sure that a non-standards-track  
>> I'm not sure I understand the merit of stopping the WGLC on whether  
>> to promote the draft on the standards track. If the WGLC concludes  
>> that standards track is fine, then surely it can just proceed as-is.
>
> Quite right. Note, however, that the main motivation for the other  
> two documents was people who had no-so-positive feelings for the  
> GOST suite (the very limited implementation experience, the known  
> weakness in the hash algorithm, and so on).

Those concerns, and the risk that there could be a run on locally- 
mandated algorithms that would use up the code-space, justify  
progressing the other two documents.  However, there is not too much  
risk to proceed with the standards-track GOST rather than delaying it  
with dependencies on those other two documents.  In other words, let  
this one go through while putting procedures in place to protect  
against the potential risk of a run of similar ones.

John

---

From: Joe Abley <[email-masked]>
Date: Fri, 4 Dec 2009 21:19:36 -0500

> Quite right. Note, however, that the main motivation for the other two documents was people who had no-so-positive feelings for the GOST suite (the very limited implementation experience, the known…

I think if people have concerns about GOST as a cryptosystem, they should feel very free not to use it. However, that seems like no kind of reason to object to it being standardised in the interests of interop between those who do not have such concerns.

This is not a last call on whether GOST is good. It's a last-call on a proposal to standardise GOST's use with DNSSEC.

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 5 Dec 2009 16:29:52 +0000

On Fri, Dec 04, 2009 at 09:19:36PM -0500, Joe Abley wrote:
>
> This is not a last call on whether GOST is good. It's a last-call on
> a proposal to standardise GOST's use with DNSSEC.

+1

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 05 Dec 2009 13:26:50 -0500

Joe Abley wrote:

> ... that seems like no kind of reason to object to it being standardised in the interests of interop between those who do not have such concerns. ...

+1

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 13:13:59 -0500

>a handful that are used during any given decade.

The crypto community does tend to have manageable number of 
candidates. My concern is about accommodating nationally-based 
algorithm like GOST.  Russia, Japan, and South Korea all have 
published such algorithms in the IETF in the past, as informational 
RFCs. When we have essentially unbounded alg ID spaces this is fine. 
DNSSEC does not seem to have that luxury (unless one relegates 
national algorithms to the two private IDs (253 & 254). Also, when we 
talk about elliptic curve algorithms the need to specify curves, and 
that can consume IDs very quickly.

>OID lookups, and was curious about previous DNS-OID collaborations.

Good question. if the two forms of private IDs (DNS and OIDs) are 
well supported, then I see a simple way to accommodate national 
algorithm requests, but I didn't think that the request for an ID for 
GOST was contemplating that approach.

>now.  I don't know if we'd actually need it, but better safe than sorry?

Thah's my view as well.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 17:12:37 -0500

>them.  253 and 254 are examples of how this can be done.

Mark,

I think it is prudent to formalize this first.  We already have 
proposals for GOST and a slew of ECDSA and SHA-xxx requests. In the 
elliptic curve signature arena (e.g., ECDSA) one can get substantial 
proliferation of algs because the specific cure, as well as key 
length and hash function all need to be identified. So, as a 
precaution, I think it wise to nail down the details of how to expand 
the space first, so that we don't have to say no to folks who come a 
bit later in the process.

If the right answer is to push national algs to the private alg 
spaces, then that's fine, but I'd like to see this stated explicitly. 
If the answer is to create a new, extended alg ID space (as Roy 
indicated) then that sounds OK too, for national algs. I'd recommend 
using the OID-style extension facility, because these algs often will 
have OIDs anyway, reducing teh proliferation of IDs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 17:11:02 -0500

At 12:33 PM +0100 12/4/09, [email-masked] wrote:
>...

Sorry my language was imprecise. I meant to suggest that validators 
of SIG records are the ones that would be required to implement a 
MUST algorithm. I also would argue that zone signer code support MUST 
algorithms as well, to maximize potential interoperability.

>implemented in order to prevent BOGUS state.

I agree that this convention allows for a fallback in case a zone is 
signed using an algorithm that is not a MUST. But, for maximum 
utility on the public Internet, one presumably wants zones to be 
signed using MUST algorithms, whenever possible.

>algorithm. This is not subtyping.

Whoops. I was not aware of the two private alg facilities in 4304. 
If the intent is to allocation IDs in these two spaces (which do not 
suffer from the ID space size limits that concern me) to national 
algorithms, I think that would be OK. Is that the plan?

>...

the pointer to the appendix in 4304 was very helpful.

>a fraction of the time needed to exhaust the current space.

So you think that the private algorithm space ought not be used for 
national algorithms like GOST? Do you recommend allocating the 
current space to everyone who requests an alg ID, and then flow into 
the extended ID space? I thought it might be preferable to reserve 
the current space for algs that are agreed upon as suitable for 
Internet-wide implementation, and move national algs to the some form 
of extended space.

>order to solve a non-prudent problem. Why wasn't this a problem for recent

I think RSA-SHA2 is qualitatively different, if one views the two IDs 
(8 & 10) as Internet-wdide (vs. national) alg IDs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 17:12:37 -0500

Mark,

Steve

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Dec 2009 15:06:29 -0500

At 17:11 -0500 12/7/09, Stephen Kent wrote:

>Whoops. I was not aware of the two private alg facilities in 4304. If the
>intent is to allocation IDs in these two spaces (which do not suffer from
>the ID space size limits that concern me) to national algorithms, I think
>that would be OK. Is that the plan?

To date, the term "national algorithm" has not been defined in the 
context of DNSSEC, nor how that is different from "internet-wide." 
That comment should underscore the remainder of my reply.

>national algorithms like GOST?

Yes, it ought not be used.

>Do you recommend allocating the current
>space to everyone who requests an alg ID, and then flow into the extended
>ID space?

Yes, so long as they have a detailed specification that allows for 
interoperability.

>I thought it might be preferable to reserve the current space
>for algs that are agreed upon as suitable for Internet-wide implementation,
>and move national algs to the some form of extended space.

DNS has never seen a serious run on numbers for any field, despite 
constant paranoia that a run "will happen."  (Okay, the 2-bit label 
type is tight but then again, it only had 4 possible values.)

I don't know how to word my response to differentiating between 
"Internet-wide" and "national algorithms" other than to say "what?" 
Other than resorting to examining laws of countries, how can one tell 
one from the other?  Math is math.

(In the 80's I was asked to define Unix in a standards-based way. 
What made an operating system a Unix system.  Turns out the answer 
wasn't in the code or any technology, it was in the trademark.)

>(8 & 10) as Internet-wide (vs. national) alg IDs.

I don't view the case of RSA-SHAx and GOST as different.  Crypto is crypto.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Basil Dolmatov <[email-masked]>
Date: Wed, 09 Dec 2009 10:02:50 +0300

> I think if people have concerns about GOST as a cryptosystem, they should feel very free not to use it. However, that seems like no kind of reason to object to it being standardised in the interest…
Moreover, it is in the interests of those who do not have any other 
legal options except using these algorithms in DNSSec.

dol@

---

From: Dmitry Burkov <[email-masked]>
Date: Wed, 09 Dec 2009 11:35:38 +0300

Basil Dolmatov wrote:
>> I think if people have concerns about GOST as a cryptosystem, they 
>> should feel very free not to use it. However, that seems like no kind 
>> of reason to object to it being standardised in the interests of 
>> interop between those who do not have such concerns.
>>
Also it will be  in interest of all to validate GOST-signed zones. It 
was discussed at the beginning of this process.
Seems some explanations were missed.

Dima