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

---

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.

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

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jul 2012 11:05:22 +1000

Sending a superset of the client's and recursive servers supported
algorithms is a *bad* idea.  DNSSEC only works reliably when both
the recursive server *and* down stream clients can validate responses.
By having the recursive server send a superset, authoritative servers
will stop using algorithms sooner than they should.  Instead of
sending the superset a server should send the intersection of the
clients + servers supported algorithms.  This may result in a empty
list.

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: Tue, 17 Jul 2012 18:18:06 -0700

> clients + servers supported algorithms.  This may result in a empty

What is the context for this comment? I never said anything about sending a superset of the supported algorithm list. The only place "superset" is mentioned in the draft does not apply above.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jul 2012 12:03:31 +1000

In message <[email-masked]>, Paul Hoffman writes
:
> What is the context for this comment? I never said anything about =
> sending a superset of the supported algorithm list. The only place =
> "superset" is mentioned in the draft does not apply above.
> 
> --Paul Hoffman=

   If the client did set the DO bit and the option(s) in the query, the
   validating recursive resolver MUST include the option(s) based on the
   setting of the CD bit.  If the CD bit is set, the validating
   recursive resolver MUST include the option(s) based on the client
   query or a superset of the client option(s) list and the validator's
   own list (if different).  If the CD bit is not set, the validating
   recursive resolver MAY copy the client option(s) or substitute its
   own option list.

Part of the problem here is that measuring what "end-system" support
is pointless, we really need to be measuring what the DNSSEC
validation path supports or else you won't meet the purpose as
outlined in the introduction.

   These proposed EDNS options serve to measure the acceptance and use
   of new digital signing algorithms.  These signaling options can be
   used by zone administrators as a gauge to measure the successful
   deployment of code that implements newly deployed digital signature
   algorithm, DS hash and NSEC3 hash algorithm used with DNSSEC.  A zone
   administrator is able to determine when to stop signing with a
   superseded algorithm when the server sees that a significant number
   of its clients signal that they are able to accept the new algorithm.
   Note that this survey may be conducted over the period of years
   before a tipping point is seen.

Part of the problem here is a myth that you can have reliable DNSSEC
without recursive servers validating results.  This has resulted
in "always set CD=1" and making decision like those above based on
what CD was set to in the request.  It also has skew the thinking
here that you can ignore the rest of the DNSSEC validation path and
get meaningful statistics.

Just have recursive server send the intersection set of supported
algorithms as seen in the last X seconds.  Where X is somewhere
between 1 hour and a week.  This can easily be done by having a
list of algorithms supported by the server and whenever you get a
incoming query with one of these options set but without one of
these algorithms you reset a counter to expire after X seconds for
that algorithm.  When you send a upstream query you send only those
algorithms that which don't have a expiry timer running.

Mark

---

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 18 Jul 2012 17:52:26 +0900

Hi,

I read the draft and followings are my comments.

- This kind of signaling mechanism is very useful especially for critical 
  zone operators such as Root and TLD.  Please move forward.

- In section 2, appearance of OPTION-CODEs are not limited. Appearance of 
  each OPTION-CODE (TBD1, TBD2 and TBD3) must be explicitly limited to 
  once to avoid confusion and packet size inflation.

Regards,

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 18 Jul 2012 12:33:27 +0200

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

Although I have my doubts about the utility of the mechanism itself I believe it is rather harmless. 

However, I would like to see to it that there is no perception that the implementation and use of this mechanism is not needed to be 'DNSSEC compliant'

I would like to see a sentence in the introduction added to the introduction, as last sentence:
"The implementation and use of the mechanism described herein is OPTIONAL."

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 18 Jul 2012 16:17:16 +0200

Hi,

On 07/18/2012 12:33 PM, Olaf Kolkman wrote:
>> 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?
>> 
> 
> 
> However, I would like to see to it that there is no perception
> that the implementation and use of this mechanism is not needed to
> be 'DNSSEC compliant'
> 
> I would like to see a sentence in the introduction added to the 
> introduction, as last sentence: "The implementation and use of the 
> mechanism described herein is OPTIONAL."
> 

I like the document, and it has improved significantly (yay!), but the
troublesome section today is indeed section 3.2.1. Validating
Recursive Resolvers.  Why is there a difference if the CD flag is set?
 The validator could well verify signatures, even if CD flag is set,
but with the CD flag set would not withhold bogus data with SERVFAIL.
 Then the set of algorithms for the validator may still be important -
it would not stop the data from being seen by the customer - but it
would disable the validator from picking the 'right DNSSEC signatures'
out of multiple candidates if it does not support the signing algorithm.

I would also prefer to (be allowed to) answer from cache even if the
previous query had a different list of supported algorithms (the
answer from the authority is the same), if the TTL has not expired, of
course.

The EDNS option codes in the query may not be supported by the
upstream server.  What is the expected result if the upstream
cache/authority does not support it, and how to deal with it?

Best regards,
   Wouter

---

From: [email-masked]
Date: Fri, 20 Jul 2012 05:29:32 +0900 (JST)

Hi, 

I read the document.

I agree to define EDNS0 option code because it is not used well.

As a private user, I oppose to set DAU, DHU and N3U in my resolvers.
Or if it is not mandatry, I will disabie this function.

There are three reasons.
They may be already discussed.
My comment may be too late.

1. Setting DAU, DHU and N3U may leak resolvers information to
   malicious servers.

2. Setting them increases query packet size, 25% or 50%.
   DNSSEC algorithms will increase, but we cannot disable old algorithms.
   We cannot decrease number of algorithms.

3. Setting DAU, DHU and N3U does not effect DNSSEC validation.
   It is useless to use DNSSEC.

I agree the draft if the implementation is not required and some
concerns are added at "Security considerations" or another part.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: Patrik Fältström <[email-masked]>
> All,
>

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Jul 2012 13:55:24 -0700

I like the document as well.

One nit:  Perhaps there  should be language somewhere to the effect of not honoring requests for obsoleted algorithms, to prevent this being used for downgrade attacks.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 20 Jul 2012 12:47:26 +0000

> algorithms that which don't have a expiry timer running.

I like this idea.  It avoids this draft's problem with violating EDNS's "hop-by-hop only" semantics by decoupling the recursor->authority message from any individual stub->recursor message.

Ray

p.s. did you actually mean "union" rather than "intersection" ?