Subject: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt

From: Patrik Fältström <[email-masked]>
Date: Tue, 17 Jul 2012 15:00:02 +0200

All,

As this was announced on June 14, 2012, and Scott Rose immediately followed up with an announcement (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and there have been exactly zero comments I am a bit shy of declaring victory.

Can I get please at least three people that have seen this version, read it, and support it moving forward (part from myself and the authors of the document?

   Patrik

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Jul 2012 11:55:36 -0400

> Can I get please at least three people that have seen this version, read it, and support it moving forward (part from myself and the authors of the document?

I have (finally!) reread the document (again!) and to be honest am getting bored with it -- I believe it is fully cooked and should be taken out of the oven and published before it gets burnt….

Warren "Stretching Analogies to Failure" Kumari.

--
The plural of anecdote is not evidence.
        -- Bill Lockyer, California Attorney General

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Jul 2012 09:23:55 -0700

> Can I get please at least three people that have seen this version, read it, and support it moving forward (part from myself and the authors of the document?

I have read the document and think it may be ready for IETF review, but it also might not. Section 3 still says:
   The
   validating end-system resolver sets the value(s) in the order of
   preference, with the most preferred algorithm(s) first as described
   in section 2.
It does not say how a resolver choses the order of preference, probably because they have no frigging idea how to measure that. How can one express a preference between RSA and ECDSA, for example, without knowing the RSA key length? Worse, how can you even have a preference when what you really have is a list of algorithms that you fully accept and a list that you fully reject?

My preference remains the same: get rid of this ordering, stop pretending that people who run resolvers care about this as much as security geeks do, and stop suggesting to people that they should care about something they do not understand. But if the WG wants to leave this in, no significant harm will be done.

--Paul Hoffman

---

From: Steve Crocker <[email-masked]>
Date: Tue, 17 Jul 2012 13:00:30 -0400

Paul,

There is a subtle point that may be helpful to recall.  The primary purpose of advertisement of which algorithms are understood by the resolver is to provide a measure of the adoption of new algorithms.  In the broad, slow cycle of introduction of new algorithms and the presumed phasing out of old algorithms, operators on the signing side of the equation will be choosing when to sign with a new algorithm and when to stop signing with an old algorithm.  They can sign with a new algorithm whenever they feel ready to do so, but they cannot rationally stop signing with the old algorithm until they have evidence that essentially all of the resolvers understand the new algorithm.  Thus, as I said, the primary purpose of this protocol extension is to provide measurable assessment of the uptake of a new algorithm.  From this perspective, the order of the algorithms within the resolver's advertisement is irrelevant.

Subordinate to this primary purpose is the potential for also advertising a preference.  Whether the responding system pays attention to the order is up to the responding system.  Also, as you suggest, the querying system may or may not have a real preference.  I don't think we have enough information to say one way or the other, and the perfect is the enemy of the good.  Let's move this forward and revisit your concern when there is some implementation and deployment experience to examine.  I hope is that this is the worst issue we will have to deal with.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Jul 2012 10:11:03 -0700

On Jul 17, 2012, at 10:00 AM, Steve Crocker wrote:

> There is a subtle point that may be helpful to recall.  The primary purpose of advertisement of which algorithms are understood by the resolver is to provide a measure of the adoption of new algorithms.  In the broad, slow cycle of introduction of new algorithms and the presumed phasing out of old algorithms, operators on the signing side of the equation will be choosing when to sign with a new algorithm and when to stop signing with an old algorithm.  They can sign with a new algorithm whenever they feel ready to do so, but they cannot rationally stop signing with the old algorithm until they have evidence that essentially all of the resolvers understand the new algorithm.  

Fully agree with all that.

> Thus, as I said, the primary purpose of this protocol extension is to provide measurable assessment of the uptake of a new algorithm.  From this perspective, the order of the algorithms within the resolver's advertisement is irrelevant.

And that too, of course.

> Subordinate to this primary purpose is the potential for also advertising a preference.  Whether the responding system pays attention to the order is up to the responding system.  Also, as you suggest, the querying system may or may not have a real preference.  

Nowhere in this document or any other DNSSEC RFC do we give any advice on why a resolver should have a preference. And that's a good thing.

> I don't think we have enough information to say one way or the other,

We disagree, strongly. Until you can show that more than a small fraction of the users of this will have a preference, saying that all of them need to have a preference in order to express it in a list adds a layer of complexity that you cannot show has any value.

> and the perfect is the enemy of the good.  

Thats a convenient way of saying "I don't know, but I liked this feature before, so let's leave it in". Some of us prefer not to add superfluous features and would use different trite saying to back our opinions.

> Let's move this forward and revisit your concern when there is some implementation and deployment experience to examine.  

Errr, how? Under what criteria could that evaluation be made? I propose that there are none possible.

> I hope is that this is the worst issue we will have to deal with.

Fully agree.

--Paul Hoffman

---

From: Dick Franks <[email-masked]>
Date: Tue, 17 Jul 2012 19:38:34 +0100

Patrik,

Read version 07, and support it moving forward.

Dick
--

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 17 Jul 2012 20:54:38 +0200

> Thats a convenient way of saying "I don't know, but I liked this feature before, so let's leave it in". Some of us prefer not to add superfluous features and would use different trite saying to bac…

Paul, I understand your issue and as one person that was part of the design of NAPTR, user of it, confused user, I completely understand the headache users might get that you talk about. But, while I might have headache over the weight and preference in for example NAPTR, I know people that do use it.

So, let me ask you:

Is this existence of this parameter for you a blocking factor for this document?

I do not mind if you expand a bit because I must as shepherd of this document understand whether what you feel is something that still is in the rough part of rough consensus, and if so that your view should be paused until there is IETF last call and your input goes to IESG.

I can understand if you see these kind of parameters in DNS "go away", but so far we have sort of used them in many RR Types, and maybe what you ask for is a generic change in how we design new RR Types. But the question is whether *THIS* document should be where we take that step on "generic design decisions".

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Jul 2012 12:06:25 -0700

> Is this existence of this parameter for you a blocking factor for this document?

I thought I was clear in my earlier message: no, not blocking. I bring it up now because it is a useless addition that is trivial to remove.

> I do not mind if you expand a bit because I must as shepherd of this document understand whether what you feel is something that still is in the rough part of rough consensus, and if so that your v…

I say "useless" because, unlike NAPTR, the ordering of the lists is optional. Because of this, the optionality of the preference ordering makes the ordering useless. That is, if I say I know "SHA1, SHA256" you don't know if I prefer SHA1 (because it's shorter, and I don't care about anything above 60 bits of strength) or whether I have no preference and listed them in numeric order or whether that order was set by my software. That is, you cannot determine if my order is surprising or uninteresting. This invalidates any value to the ordering.

If the WG leaves in the ordering, I believe that we need to add "however, interpreting the order in answers will lead to wrong conclusions". If I'm wrong and someone can show how a recipient can tell the difference between answers that were ordered on purpose and those that were not, that's great: we can add it to the draft.

> I can understand if you see these kind of parameters in DNS "go away", but so far we have sort of used them in many RR Types, and maybe what you ask for is a generic change in how we design new RR…

I do *not* want the parameters to go away: I said that I support the publication of this document. All I am saying is that the optional ordering is useless and will cause problems for validators ("where do I read why I should have a preference") and zones who make false assumptions on the order seen.

--Paul Hoffman

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 17 Jul 2012 21:11:53 +0200

Thanks!

   Patrik