Subject: [dnsext] GOST DNSSEC implementations?

From: Olafur Gudmundsson/DNSEXT chair <[email-masked]>
Date: Mon, 14 Sep 2009 13:18:01 -0400

Has anyone thought about/attempted to implement the algorithms proposed
in:
	http://tools.ietf.org/id/draft-dolmatov-dnsext-dnssec-gost-01.txt

As more than 5 people volunteered to review, the next version of the
draft will be an official WG document:
	 draft-ietf-dnsext-dnssec-gost-00.txt

The draft needs feedback on its quality and presentation, before we can
start WGLC. Editor has asked for feedback the draft, please take a look
at the draft and send in comments, including "looks fine".

It would be nice to have 2+ implementations of tools
inter operating by the time working group does LC this document,
scheduled for later this year.

Actions that need to be performed are:
	DS calculation
	GOST key generation
	GOST Signature generation /verification

Olafur will coordinate with implementors test algorithm numbers
(will be different from the ones that IANA will allocate).

Documents describing the GOST algorithms are available in English:
http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-01
http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-03

	Olafur & Andrew

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 15 Sep 2009 10:56:45 +0200

>     http://tools.ietf.org/id/draft-dolmatov-dnsext-dnssec-gost-01.txt

Yes, I have experimental implementations: ldns and unbound (with
- --enable-gost and ssl 1.0).

Comments on draft: fine with me, nit points:
* I would like examples of a DS record, DNSKEY record and signature with
GOST (with a long expiration date).  This can be done once algorithm
numbers exist, of course.
* The file format for the GOST private key.  I chose to put a base64
blurb of the DER encoded private key on one line into a text file after
the usual Private-Key-Format: and Algorithm: lines.  For example in the
file Kexample.com.+XXX+41891.private:

Private-key-format: v1.2
Algorithm: XXX (GOST)
MEUCAQAwHAY[[...more...]]v0QKoL3p/wOX/3kySQ3Q=

For RSASHA256 this was not an issue, since the private key for RSA does
not change if you use SHA256.

Best regards,
   Wouter

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 15 Sep 2009 11:42:08 -0400

At 04:56 15/09/2009, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
---> OG
Wouter,

Having dummy DS, DNSKEY and RRSIG records inserted into the document at
this point is a good idea. Once IANA assigns the numbers we can
use the real algorithm numbers and real values.
Dummy ==> all correct but algorithm numbers random.

>MEUCAQAwHAY[[...more...]]v0QKoL3p/wOX/3kySQ3Q=
----> OG
None of the other RFC's specifies private key format and as this
never shows up "on-the-wire" it is out-side the scope of the working
group.

>not change if you use SHA256.

---> OG

Thank you for your report

anyone else have implementations?

         Olafur

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 15 Sep 2009 18:57:22 +0200

> Dummy ==> all correct but algorithm numbers random.

this is why i want a few numbers assigned for testing purposes; the cynical me
wants to propose to just pick any number as long as it's not in the range 0-255.

but perhaps one could overload 253/254 'for now', or pick a high number and hope
that if they do get out into the wild that by the time it would matter those
implementations have been replaced.

Jelte

---

From: Basil Dolmatov <[email-masked]>
Date: Tue, 15 Sep 2009 21:28:25 +0400

Jelte Jansen пишет:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

---> OG
Wouter,

Implementators from "Garant-Park" have taken "random" protocol number -
8.

Funny enough, all lower numbers have been occupied already in the bind
code.

dol@

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 16 Sep 2009 09:51:49 +0200

Basil Dolmatov wrote:
> Implementators from "Garant-Park" have taken "random" protocol number - 8.
> 

which I also happened to have chosen for my implementation of RSA/SHA2 in ldns
(as well as 9, 10 and 11, back when the first last call was done and the draft
had 4 different algorithms). Those have 'escaped' through a nice combination of
expecting the draft to become an rfc as it was, and some communication errors,
so now there might be validators out there that expect algorithm 8 to mean
RSA/SHA256, even if the actual algorithm id turns out to be something else (or
even if the draft is completely turned down).

Which now means that if we want to be sure that nobody gets unexpected failures,
IANA should assign numbers 8 and 10 to RSA/SHA256 and RSA/SHA512, and 9 and 11
should be marked as don't-use-in-the-forseeable-future...

and we need to figure out a way to prevent people like me from making the same
mistake :)

Of course those validators are probably replaced by newer versions by now which
don't have that part of the code anymore, but one can't really be sure.

>
> Funny enough, all lower numbers have been occupied already in the bind code.

i don't understand what you're saying here, all assigned low numbers there are
straight out of rfcs afaict.

Jelte

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 16 Sep 2009 12:23:43 +0400

> straight out of rfcs afaict.
Right you are. Sorry.

dol@

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Sep 2009 07:47:27 -0700

At 6:57 PM +0200 9/15/09, Jelte Jansen wrote:
>but perhaps one could overload 253/254 'for now',

Please don't.

> or pick a high number and hope

That seems better. Maybe use 249 for the drafts, but note in the drafts that 249 will *not* be assigned by IANA when the RFC is published.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Sep 2009 10:00:22 +1000

In message <p06240812c6d6aabeaa51@[10.20.30.158]>, Paul Hoffman writes:
> That seems better. Maybe use 249 for the drafts, but note in the drafts that 
> 249 will *not* be assigned by IANA when the RFC is published.

You just don't release code to the public until the code point is
assigned.  You can perform private tests with any unused code point.

I've got code that is "#ifdef notyet" out that has been waiting a
proto-writeup for two years now.  It isn't hard to do the correct
thing.

#ifdef _GOST_TEST_
#define ALG_GOST  50 	/* Not the correct value interop testing only. */
#endif

I've seen code points change too many times to trust that the next
value will be the one allocated.

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Sep 2009 17:37:53 -0700

>assigned.  You can perform private tests with any unused code point.

Good in theory, often fails in practice. But having said that...

>value will be the one allocated.

That's a good way to remind yourself that you're doing something dangerous.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 17 Sep 2009 10:54:22 +0400

Olafur,

> 	GOST Signature generation /verification

You start your message with "it would be nice". After that your mail  
reads like a bunch of requirements for submission to the IESG.

Are you planning to have the documents submitted and published as  
draft-standard in one go? I really like the idea of having running  
code when developing protocols and love to see more (and some early  
deployment if possible). But, as far as I know there is no requirement  
in the process.

--Olaf

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Olafur Gudmundsson/DNSEXT chair <[email-masked]>
Date: Thu, 17 Sep 2009 10:21:33 -0400

Olaf,

This was my slightly underhanded way to motivate WG members to pay attention
to the draft. Nothing is better to bring out the issues with a draft than
having someone actually try to follow it.
As you remember at number of times in the past the WG has "required" that
there be "test" implementations of various drafts before advancing documents.
see for example:
http://psg.com/lists/namedroppers/namedroppers.2007/msg00157.html

Given this is brand new technology (ECC vs RSA) having people think about
implementation implications it seemed like a good idea.

So far I have received confirmation of one implementation and hints 
of two others,
plush one great review.

WG, members please read the draft, comment on it, and let me know if you are
doing/thinking-about implementing it.

As for the process question, I will answer with one statistic:
         no RFC published by dnsext/dnsind has made it to Draft 
Standard status.

Thus applying the Draft Standard rules on any document we send to Proposed
Standard, when we can, is good idea IMHO.

         Olafur

---

From: Doug Barton <[email-masked]>
Date: Fri, 25 Sep 2009 21:40:21 -0700

> and we need to figure out a way to prevent people like me from making the same

IANA could kill two birds with one stone by not assigning 8-11 "in the
foreseeable future" and assigning something totally different to
RSA/SHA{256|512}. There is a special place reserved in hell for people
who hijack code points (and port numbers, etc. etc.). Making examples
of you (and those who relied on you) should hopefully serve as the
"way to prevent people like you from making the same mistake." And
yes, I'm serious.

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 27 Sep 2009 16:56:49 -0400

On Fri, Sep 25, 2009 at 09:40:21PM -0700, Doug Barton wrote:

> RSA/SHA{256|512}.

Actually, in consultation with IANA, we've determined that we'll
assign the identifiers in the 8-11 range, but reserve the "polluted"
ones until there remain no other identifiers left.  In defence of
Jelte and his colleagues, we were in last call on what had previously
seemed like a completely uncontroversial document, and they did mark
the feature as experimental.  That said, it is indeed a very bad idea
to release software with this sort of optimistic assumption in it.
(But I think Jelte and his colleagues feel suitably chastised by the
facts of the matter.)

I appreciate that there might be some desire for a punitive assignment
strategy, but we _are_ about interoperation, after all.

A

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

---

From: Doug Barton <[email-masked]>
Date: Sun, 27 Sep 2009 17:35:46 -0700

> strategy, but we _are_ about interoperation, after all.

It has nothing to do with being punitive in the "punishment for its
own sake" category. Regardless of how well justified the decision to
release the code in this format was, as you pointed out it was wrong
to do it. By accommodating this mistake you both lower the bar a notch
and embolden the next person who decides to hijack a code point for
what they consider a "good reason."

If the feature was marked as experimental then the user impact of
assigning a different code point should be negligible. Is there a
separate mechanism I should avail myself of to make this a formal request?

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 27 Sep 2009 18:54:46 -0700

> separate mechanism I should avail myself of to make this a formal request?

BTW, I should probably make a few more things clear on this subject.
First of all, I haven't spoken to anyone at IANA about this, and I am
speaking only for myself. I have no axe to grind against Jelte
(indeed, I only know him from this list) and I like the idea of
getting RSA/SHA{256|512} deployed.

That said, I was at one time the general manager of the IANA, and
dealt with this problem (of people hijacking things and then expecting
IANA to legitimize them after the fact) on a regular basis. It's a
serious problem, and all of the past hand-waves in the name of
"interoperability" or whatever the excuse was at the time haven't made
things better, they've made things worse.

I'm sorry that Jelte and/or his users are stuck in the middle of this
thing, but we need to draw the line somewhere, and given the facts of
this particular case it seems like the right time to take a stand.

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Sep 2009 11:13:45 -0400

Dear colleagues,

> what they consider a "good reason."

I want to ask the WG for its views on the above argument.  I confess I
find it unpersuasive.  We are not the protocol police.  Moreover, I
don't believe anyone is watching us to see whether they can be
emboldened.  On the contrary, I suspect that the only effect of using
completely new identifiers would be to break an existing (but wrong)
released implementation without any concomitant benefit.

I am susceptible to persuasion, however, so if others feel as Doug
does, then it would be good to know it.

Best,

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Sep 2009 08:57:59 -0700

>does, then it would be good to know it.

Other IETF WGs, particularly in the Security Area have dealt with this very issue in the past. The short answer is that both of you are right in approximately the same amount. I have heard developers say "BigCo shipped with this number that they assumed IANA would assign in the Foo protocol, so we should not wait and just do the same". Other vendors have patiently waited because they didn't want to be assholes like BigCo. At least one WG did the "change the identifier to level the playing field" dance, and interoperability went to hell, and is still there many years later.

If you agree that both sides are right, then we should lean strongly towards interoperability, not punishing hijackers.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Schnizlein <[email-masked]>
Date: Mon, 28 Sep 2009 12:02:40 -0400

While I have my own memories of the anger I felt when discovering that  
broken applications were due to a colleague having made up numbers he  
should have requested that I allocate (uniqueness matters), my  
sympathy for Doug's experience does not convince me that numbers now  
in (erroneous) circulation should be assigned to some innocent new role.

John

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2009 16:51:10 +0000

> does, then it would be good to know it.

i don't feel precisely the way doug did, but i'm close.  we should reserve
these wrongly allocated identifiers until we run out of available code points,
in order to avoid penalizing other protocols with messages from these rogues.

however, we should standardize on different code points than any rogue has
used, because otherwise all hell will break loose.  if the IETF wants to
encourage self-allocation then they should reserve a range of code points
for that.

---

From: Jim Reid <[email-masked]>
Date: Mon, 28 Sep 2009 18:24:53 +0100

Although everyone's right, I tend to agree with Doug here. Why bother  
having such a registry if there's going to be an effective free for  
all with algorithm subtyping? It should not be acceptable for someone  
to just pluck algorithm numbers out of the air and then have IANA  
register these after the fact. Doing this now sets a precedent that  
could create nasty problems in the future, especially when all sorts  
of crazy crypto schemes start to get flung at a DNS that has broader  
DNSSEC uptake.

Algorithm numbers for private or experimental use where set aside. So  
I don't know why these weren't used for the "experiment" that has now  
somehow morphed into a production environment.

I think this incident has demonstarted there's a need for an RFC5395- 
like process for assigning algorithm identifiers for DNSSEC.

IMO, the identifiers that have been misused should be entered into the  
registry as "Reserved" or something like that. Then some to-be- 
invented process gets followed for identifiers to be assigned to the  
algorithms that accidentally got type codes withount undergoing IETF  
scrutiny.

---

From: [email-masked]
Date: Mon, 28 Sep 2009 18:03:01 +0000

well... the IANA used to be much more proactive in engagement
with the development process - and code points would not be
an after the fact assignment.  It happened before (this is not
new) and with the current process, it is the "easy" path...

Not just because of an un-approachable IANA, but a strict, process-driven
IETF that pretty much insists that no code be written before the 
spec is hammered out.  Of course everyone couldmove into the private
set-aside, kind of liek the address folks have abandoned the RIR process
for NAT/ULA space.  

Put too much red tape in place and folks will work around it.

--bill

---

From: Jim Reid <[email-masked]>
Date: Mon, 28 Sep 2009 19:33:04 +0100

On 28 Sep 2009, at 19:03, [email-masked] wrote:

> spec is hammered out.

Bill, I was not advocating a cumbersome process: far from it.

RFC5395 seems to be working reasonably well for RR type codes. It  
doesn't require RFCs or diverse implementations. All it takes is a  
reasonable enough amount of information for an independent reviewer to  
say whether IANA should assign a type code or not.

Something similar for algorithm numbers should work just as well too.  
Though in this case the reviewer would ask "does this crypto algorithm  
look sound?" rather than "does the proposed RR do bad things at zone  
cuts or with Additional Section processing?". There would be no need  
for WG review or comment.

In fact I'd argue that the reason for the current discussion is  
precisely because there is no process for registering algorithm codes  
other than writing a standards-track RFC.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Sep 2009 11:45:50 -0700

At 6:24 PM +0100 9/28/09, Jim Reid wrote:
>Although everyone's right, I tend to agree with Doug here. Why bother having such a registry if there's going to be an effective free for all with algorithm subtyping?

Straw-man alert: that's not what happened here, and it is inappropriate to suggest that it was. The author of an active WG document made the mistake of hard-coding numbers in the Internet Draft based on looking at the history of allocation (namely, monotonically increasing). The draft *with those numbers included* went through multiple iterations in the WG. None of the three of you objected to the use of those code points during that review.

That is far from "free for all".

> It should not be acceptable for someone to just pluck algorithm numbers out of the air and then have IANA register these after the fact.

If you believe that, why did not not object during WG Last Call, much less earlier? Why wait until now?

>Doing this now sets a precedent that could create nasty problems in the future, especially when all sorts of crazy crypto schemes start to get flung at a DNS that has broader DNSSEC uptake.

Having IANA assign after-the-fact *because* of vendor use is, of course, a bad idea, but that is not what Andrew proposed. We are talking about a WG work item for which there were multiple requests for review.

>Algorithm numbers for private or experimental use where set aside. So I don't know why these weren't used for the "experiment" that has now somehow morphed into a production environment.

The document in question is destined for Standards Track, not Experimental.

>I think this incident has demonstarted there's a need for an RFC5395-like process for assigning algorithm identifiers for DNSSEC.

Fully agree; that's what we have, modulo a document author who screwed up and dozens of probable reviewers who didn't call him on it.

>IMO, the identifiers that have been misused should be entered into the registry as "Reserved" or something like that. Then some to-be-invented process gets followed for identifiers to be assigned to the algorithms that accidentally got type codes withount undergoing IETF scrutiny.

Define "misused" in this case.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2009 19:07:41 +0000

> Date: Mon, 28 Sep 2009 18:03:01 +0000
> From: [email-masked]
> 

the day i met jon postel in person for the first time, it was because i
was attending my first IETF (somewhere in canada) and i'd stayed up all
night prototyping NOTIFY and i ran into bmanning in the hallway somewhere
and asked "how do i get a codepoint assigned for the NOTIFY opcode" and
he said "you have to talk to the IANA, i see him coming right now."  jon
heard me out, took me to the terminal room, logged into an ISI computer,
and made the assignment.  thus my prototype was able to be tested with
the same opcode number as it would have in production, even though there
was no spec, not even a draft, at that moment.

> IETF that pretty much insists that no code be written before the spec is
> hammered out.  Of course everyone couldmove into the private set-aside,
> kind of liek the address folks have abandoned the RIR process for NAT/ULA
> space.
> 

i think we should encourage prototyping and experimentation.  i should've
had to write a draft before i could get a codepoint assigned for NOTIFY,
and that rule came into effect shortly thereafter.  but i'm in favour of
having only as much red tape as people will not work around, so, +1 here.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 28 Sep 2009 12:31:26 -0700

On Mon, Sep 28, 2009 at 12:07 PM, Paul Vixie <[email-masked]> wrote:
> thus my prototype was able to be tested with

I think this is a desirable property of whatever allocation mechanism
is used.  I'd like to see people able to reserve an identifier for use
as long as they make a good faith explanation regarding its intended
use.  We need to discourage people from misappropriating available
identifiers, but if someone's going to use an identifier, it's better
to document it so we can avoid unnecessary incompatibilities.

E.g., even if GOST isn't accepted as a standard DNSSEC protocol suite,
IANA should still note that the identifiers 8--11 (or whichever) were
used by some prototype implementations, and should avoid allocating
them to other uses as long as there are unused identifiers available.

---

From: Jim Reid <[email-masked]>
Date: Mon, 28 Sep 2009 20:36:20 +0100

On 28 Sep 2009, at 19:45, Paul Hoffman wrote:

> Straw-man alert: that's not what happened here, and it is  
> inappropriate to suggest that it was. The author of an active WG  
> document made the mistake of hard-coding numbers in the Internet  
> Draft based on looking at the history of allocation (namely,  
> monotonically increasing). The draft *with those numbers included*  
> went through multiple iterations in the WG. None of the three of you  
> objected to the use of those code points during that review.
>

With respect Paul, it is.

You point out that the review process didn't pick up on this error.  
[I'm guilty as charged m'lud.] Which makes me wonder what other Bad  
Ideas or comparable administrative errors might be that draft and have  
escaped scrutiny. Or in other drafts for that matter.... Perhaps we're  
all burnt out with DNSSEC and nothing gets the same level of attention  
as in the early days of DNSSEC protocol development. If that's true,  
it's worrying.

>> It should not be acceptable for someone to just pluck algorithm  
>> numbers out of the air and then have IANA register these after the  
>> fact.
>

Because I did not notice it then. And it seems nobody else did either.  
Until Jelte 'fessed up.

> Having IANA assign after-the-fact *because* of vendor use is, of  
> course, a bad idea, but that is not what Andrew proposed. We are  
> talking about a WG work item for which there were multiple requests  
> for review.

Fair enough. But the review which did take place didn't spot the new  
algorithm IDs. So in that respect, it's not that different from just  
plucking numbers out of the air. The WG's still arrived at a position  
where algorithm codes that shouldn't have been assigned are about to  
be registered by IANA.

> The document in question is destined for Standards Track, not  

OK. I misremembered Jelte's initial mail.

> Define "misused" in this case.

Well how about "escaped proper scrutiny by the WG". Although the  
circumstances you've outlined are not the same as or as bad as  
"plucking numbers out the ether", the end result is pretty much the  
same.

If anything your mail strengthens my disapproval of a proposal to  
assign these codes. It points to a failure in the review process and  
then a rewriting of history to deal with that. This is Bad. I'm  
particularly worried about this when future attempts are made to roll  
more crypto algorithms into DNSSEC. Because now not only has a  
dangerous precedent been set, but someone would have a valid complaint  
that there was one set of rules for those inside the IETF machine and  
another for those who weren't. Imagine a DJB-style rant along the  
lines of "they let Jelte's codes though but won't give me one for the  
crypto I've deployed".

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Sep 2009 12:50:38 -0700

At 8:36 PM +0100 9/28/09, Jim Reid wrote:
>You point out that the review process didn't pick up on this error. [I'm guilty as charged m'lud.] Which makes me wonder what other Bad Ideas or comparable administrative errors might be that draft and have escaped scrutiny. Or in other drafts for that matter.... Perhaps we're all burnt out with DNSSEC and nothing gets the same level of attention as in the early days of DNSSEC protocol development. If that's true, it's worrying.

I fully agree with everything in the second paragraph, but I don't see how it leads to the first. We have a review process that (at least) allows us to find errors. That's not a free-for-all.

To be clear: if someone puts a value in an I-D that is not meant to be being reviewed by the WG, I have much, much less compassion for them expecting IANA to then give them the number they chose. I would want IANA to follow its monotonically-increasing rule which might or might not make those authors happy. But that's not what we are talking about here.

>Because I did not notice it then. And it seems nobody else did either. Until Jelte 'fessed up.

And then what? I don't see anyone, you included, saying on the list that the inclusion would cause an IANA reset. It did not come up until the mostly-unrelated discussion this week.

>But the review which did take place didn't spot the new algorithm IDs. So in that respect, it's not that different from just plucking numbers out of the air.
>. . .
>If anything your mail strengthens my disapproval of a proposal to assign these codes. It points to a failure in the review process and then a rewriting of history to deal with that. This is Bad.

We'll have to agree to disagree on this; I see the process quite differently than you do.

>I'm particularly worried about this when future attempts are made to roll more crypto algorithms into DNSSEC. Because now not only has a dangerous precedent been set, but someone would have a valid complaint that there was one set of rules for those inside the IETF machine and another for those who weren't.

Fully disagree. That would not be a "valid complaint" at all.

>Imagine a DJB-style rant along the lines of "they let Jelte's codes though but won't give me one for the crypto I've deployed".

I can imagine it, and I can imagine my response: "your document wasn't a WG document so the rules are different". Why would you want to respond in a different way?

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Sep 2009 13:32:56 -0700

Bill,

On Sep 28, 2009, at 11:03 AM, [email-masked] wrote:
> with the development process

Jon was a bit more technical than most and what was being standardized  
was much more limited than what it is today.

> Not just because of an un-approachable IANA,

Michelle and the other folks who do IANA stuff are unapproachable?   
There is an IANA booth at every IETF.  IANA staff answer phones and  
email.  How exactly is IANA unapproachable?

> but a strict, process-driven

Ignoring the anti-IETF hyperbole, IANA has allocated code points based  
on unhammered out drafts in the past.  This really shouldn't be that  
hard.

With respect to code point "hijacking", when IANA staff have asked in  
the past, the IESG has consistently come down on the side of  
prescriptive registries rather than descriptive.  In some cases, I  
actually think this is a mistake, but the job of folks at IANA isn't  
to make policy.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Sep 2009 16:31:13 -0400

On Mon, Sep 28, 2009 at 08:36:20PM +0100, Jim Reid wrote:

> plucking numbers out of the air.

Now, wait just a minute.  That's a total abdication of the WG's
responsibility for the quality of its output.  For instance, I
reviewed the drafts that had these algorithm numbers in them, and I
screwed up by not saying, "That ought to be TBD1 and TBD2."  (Indeed,
I didn't even notice this issue until we had to pull the draft back
from the IESG after the post-WGLC negative comments arrived.  If you
want to dump on someone, your chair is a good target here.)

If we're supposed to do review, and we somehow fail, we're not
absolved of the faults in the result.  This isn't "plucking numbers
out of the air", it's just a series of mistakes by humans.  Surely, if
we're worried about bureaucratic processes and so on, we ought not to
set a rule that tends to obscure the difference between, "Bad actor
tries to do something nasty to force a situation," and, "Oh, phooey,
we screwed up."

A

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

---

From: [email-masked]
Date: Mon, 28 Sep 2009 20:40:41 +0000

> was much more limited than what it is today.

	True and maybe.

> email.  How exactly is IANA unapproachable?

	well... as Paul pointed out - Jon would get out and
	meet with folks, go to WG meetings, etc.  Not have a booth
	where folks would need to walk up to talk to him.

> on unhammered out drafts in the past.  This really shouldn't be that  

	agreed - that should be the easy path.

> actually think this is a mistake, but the job of folks at IANA isn't  

	we've had this discussion before.

---

From: Jim Reid <[email-masked]>
Date: Mon, 28 Sep 2009 21:54:00 +0100

On 28 Sep 2009, at 21:31, Andrew Sullivan wrote:

> If you want to dump on someone, your chair is a good target here.)

I don't want to dump on anyone. There's been a collective failure here.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2009 09:59:51 +1000

In message <p06240817c6e68c6ad015@[10.20.30.158]>, Paul Hoffman writes:
> Other IETF WGs, particularly in the Security Area have dealt with this very i
> ssue in the past. The short answer is that both of you are right in approxima
> tely the same amount. I have heard developers say "BigCo shipped with this nu
> mber that they assumed IANA would assign in the Foo protocol, so we should no
> t wait and just do the same". Other vendors have patiently waited because the
> y didn't want to be assholes like BigCo. At least one WG did the "change the 
> identifier to level the playing field" dance, and interoperability went to he
> ll, and is still there many years later.

I don't see a interop problem here.  The zones will be treated as
insecure by everyone else.  By the time these numbers are reused
the offending code should no longer be being used.  We are talking
20+ years.

Just have everyone warn about them until 00:00 Jan 1, 2015 UTC.
TLD and other infrustructure providers should be requested not to
accept these algorithms code points until after this date and to
state why they are not being accepted.  This will help clean the
use of the offending code points out sooner.

This is easy to fix for offending zones.  Download and compile the
new code.  Generate new keys and sign the zone with those keys.

The only hard part is to make sure any published trust anchors are
pulled from validators that "understand" the code point.  DS should
be removed from parent zones before re-signing so the zone will
cleanly transition to being treated as insecure for these algorithms.

Mark
 
> If you agree that both sides are right, then we should lean strongly towards 
> interoperability, not punishing hijackers.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2009 12:11:29 +1000

> other than writing a standards-track RFC.
 
If one want to experiment with new crypto there already is a way
to do that without involving anyone other than the experimenters.
You don't need to go to IANA to experiment in this area.

If there is consensus that the algorithm is good/needed we can give
it a algorithm number and it is then likely to be picked up by
most/all of the vendors.  Having that consensus go through the RFC
process is not bad.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2009 12:25:35 +1000

In message <p06240877c6e6ad8692c4@[10.20.30.158]>, Paul Hoffman writes:
> >Although everyone's right, I tend to agree with Doug here. Why bother having
>  such a registry if there's going to be an effective free for all with algori
> thm subtyping?
> 
> Straw-man alert: that's not what happened here, and it is inappropriate to su
> ggest that it was. The author of an active WG document made the mistake of ha
> rd-coding numbers in the Internet Draft based on looking at the history of al
> location (namely, monotonically increasing). The draft *with those numbers in
> cluded* went through multiple iterations in the WG. None of the three of you 

The author also clearly marked the code points as TBA.  The examples
had a number in them but all the descriptive text was TBA.
 
> > It should not be acceptable for someone to just pluck algorithm numbers out
>  of the air and then have IANA register these after the fact.
> 

The numbers in the examples had no bearing on whether the design
was good or not.  Changing the examples to reflect a assigned code
point is a editorial change that doesn't require WG consensus.
 
> >Doing this now sets a precedent that could create nasty problems in the futu
> re, especially when all sorts of crazy crypto schemes start to get flung at a
>  DNS that has broader DNSSEC uptake.
> 
> Having IANA assign after-the-fact *because* of vendor use is, of course, a ba
> d idea, but that is not what Andrew proposed. We are talking about a WG work 
> item for which there were multiple requests for review.

And which were clearly marked as TBA.
 
> >Algorithm numbers for private or experimental use where set aside. So I don'
> t know why these weren't used for the "experiment" that has now somehow morph
> ed into a production environment.
> 
> >I think this incident has demonstarted there's a need for an RFC5395-like pr
> ocess for assigning algorithm identifiers for DNSSEC.

No it hasn't.  There is a way for anyone to experiment in this area
without having to get a algorithm number assigned.

> Fully agree; that's what we have, modulo a document author who screwed up and
>  dozens of probable reviewers who didn't call him on it.

It was immaterial to whether the document was good enough to go to
IESG and IETF last call or not.  Regenerating the examples for a
new code point is a mechanical process.

> >IMO, the identifiers that have been misused should be entered into the regis
> try as "Reserved" or something like that. Then some to-be-invented process ge
> ts followed for identifiers to be assigned to the algorithms that accidentall
> y got type codes withount undergoing IETF scrutiny.
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2009 12:49:09 +1000

> want to dump on someone, your chair is a good target here.)

You could TBA the DNSKEY record.  You can't really TBA a RRSIG as
the signature bits are dependent on the assigned code point.
 
> tries to do something nasty to force a situation," and, "Oh, phooey,

Perhaps we should have added [to be regenerated on code point
assignment] to prevent it being forgotten.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Sep 2009 07:43:48 +0000

* Andrew Sullivan:

> I want to ask the WG for its views on the above argument.

I guess we have to conede that the registry is not actively used.
IMHO, you can't rightfully complain if people bypass a dormant
registry.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Sep 2009 07:51:20 +0000

> was no spec, not even a draft, at that moment.

For port numbers, is it really that different today?  Some time ago,
when James Yonan requested a port number for OpenVPN, a decidedly
non-IETFy protocol with a single implementation, we were all surprised
by the quick assignment.

As far as I know, this WG has decided to put the DNS security
algorithm numbers registry into stasis.  This is not IANA's fault.

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 29 Sep 2009 11:08:38 +0200

> "way to prevent people like you from making the same mistake." And

As Jelte explained above there are a number of reasons why code was  
shipped with non IANA-assigned code points.

Speaking for NLnet Labs: It is not our policy to ship code with self- 
assigned code points enabled by default. Sometimes our code does  
contain such code points for interoperability testing (the running  
code part of rough consensus) but that code MUST be enabled at compile  
time. This time the code "escaped" in error and not because of  
conscious hijack, mea culpa non-the less.

The code using these code points has been disabled in more recent  
releases.

 From an Unbound perspective the code points can be safely used for  
RSA SHA256 en SHA512 but you would also not meet with any resistance  
if other code points would be assigned.

--Olaf Kolkman
   director NLnet Labs

PS:  While Jelte's email address now contains ISC, this happens while  
he was at NLnet Labs and is Labs' responsibility.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Sep 2009 00:09:26 +1000

> algorithm numbers registry into stasis.  This is not IANA's fault.

There is nothing preventing anyone using their own crypto for DNSSEC
except themselves.

   Algorithm number 253 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the DNSKEY
   RR and the signature area in the RRSIG RR begin with a wire encoded
   domain name, which MUST NOT be compressed.  The domain name indicates
   the private algorithm to use, and the remainder of the public key
   area is determined by that algorithm.  Entities should only use
   domain names they control to designate their private algorithms.

I would think that using 253 would be a good way to prove that there
is enough interest in a algorithm to get it assigned its own algorithm
number.

Mark

> --=20
> Kriegsstra=DFe 100              tel: +49-721-96201-1

---

From: bert hubert <[email-masked]>
Date: Tue, 29 Sep 2009 16:51:59 +0200

> There is nothing preventing anyone using their own crypto for DNSSEC
....

> is enough interest in a algorithm to get it assigned its own algorithm

Are you serious? I mean, it would never work, you'd have multiple
implementations out there speaking '253' and meaning different things.
That's no way to drum up interest..

    Bert

---

From: David Blacka <[email-masked]>
Date: Tue, 29 Sep 2009 11:28:18 -0400

> That's no way to drum up interest..

Bert, Mark is referring to the well-defined private algorithm  
mechanism present in DNSSECbis.  We don't have a lot of actual  
implementation experience with it, but it absolutely should work.

See RFC 4034 section A.1.1 and draft-ietf-dnsext-dnssec-bis-updates-09  
section 4.3.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Sep 2009 01:38:47 +1000

In message <[email-masked]>, bert 
hubert writes:
> Are you serious?

Yes.

> I mean, it would never work, you'd have multiple

KEY and DNSKEY w/ algorithms 253 and 245 are designed to be sub-typed,
(253 domain name and 245 oid).

DS however isn't (something we missed) which means that we need to
add the equivalent to DS for DNSKEY algorithms 253 and 254.  This
can easily be done by having new DS hash algorithm numbers which
indicates the hash field contains the domain name or oid as appropriate
as well as a hash.  The more radical approach, and one I don't
recommend, would be to add DNSKEY algorithms 253 and 254 knowledge
to DS hash algorithms 1 and 2 but you may have servers complain
about too long hash fields.

At the moment DNSKEY w/ algorithms 253 and 245 won't work reliably
in a secure delegation so we may as well fix the oversight.

All future has DS hash algorithms assignments should support 253
and 254.

When comparing DS's and the DNSKEY algorithms are 253 and 254 you
also check the domainname or oid as appropriate to determine if you
the child zone is signed with a algorithm the validator supports.

This presents no problems for validators that don't know about
algorithms 253 and 245 or for validators that don't know about the
proposed new DS hash algorithms.

This is fodder for draft-ietf-dnsext-dnssec-bis-updates.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Sep 2009 12:01:40 -0400

> This is fodder for draft-ietf-dnsext-dnssec-bis-updates.

Not unless you have specific text to propose.  We need to get that
document out the door, so I'm reluctant to add more stuff to it.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Sep 2009 02:03:11 +1000

In message <[email-masked]>, David Blacka wr
ites:
> 
> --Apple-Mail-6-1052992179
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed;
> 	delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> 

Which I missed seeing but works, so ignore most of my other email
except for the "yes".  Named doesn't yet implement this but then
it doesn't yet have support for any algorithms that need it to be
implemented.
 
Mark