Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jun 2011 16:11:55 -0400

At 16:16 -0400 5/25/11, Edward Lewis wrote:

Since someone misread this, I'll add for clarification:

>This is incorrect in 3.4.1:
>
>#   A validating recursive resolver MUST set the DO bit [RFC4035] to
>#   indicate that it wishes to receive DNSSEC RRs in the response.  If
>
>Try this, as an example:  "$ dig @a.dns.jp jp dnskey"
>
>(No EDNS0, no DO, but I get DNSKEY records back.)

What's incorrect (in my opinion) is the use of "MUST" in the quoted 
text.  As in, referring to the example dig, I don't "MUST set the DO 
bit" to see DNSKEY records.  I can indicate I want to see 
DNSSEC-related records merely by asking for them specifically or via 
QTYPE=ANY.

I'm quibbling over the wording, yes.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Jun 2011 16:47:26 -0400

Suggested replacement text:

Change from:
wishes to receive DNSSEC RRs in the response
to:
wishes to have DNSSEC RRs added to the response, where appropriate.

Brian

On Mon, Jun 6, 2011 at 4:11 PM, Edward Lewis <[email-masked]> wrote:

> What's incorrect (in my opinion) is the use of "MUST" in the quoted text.
>  As in, referring to the example dig, I don't "MUST set the DO bit" to see
> DNSKEY records.  I can indicate I want to see DNSSEC-related records merely
> by asking for them specifically or via QTYPE=ANY.
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jun 2011 13:50:35 -0700

How about instead "A validating recursive resolver sets the DO bit...", eliminating the (clearly not correct) "MUST"?

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jun 2011 09:33:39 +1000

> >(No EDNS0, no DO, but I get DNSKEY records back.)

A validating recursive resolver MUST set the DO bit [RFC4035] to
indicate that it is willing to receive DNSSEC RRs associated with
the answer that were not directly requested.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Jun 2011 07:33:18 +0100

--On 6 June 2011 16:11:55 -0400 Edward Lewis <[email-masked]> wrote:

> DNSKEY records.  I can indicate I want to see DNSSEC-related records
> merely by asking for them specifically or via QTYPE=ANY.

If we want to pick nits, there are 2 problems. One, as you've set out, there
are other ways to get DNSSEC RRs. More significantly perhaps, this isn't
an RFC2119 "MUST" at all. Consider the ambiguous and analagous sentence
"You must take 280 to get to SFO quickly". What this probably means is
not that you MUST got to SFO quickly, nor MUST go to SFO at all, but
that if you want to get to SFO quickly, taking 280 is the way to do it;
it is not saying you "MUST" take 280 at all. I think the same applies
to the sentence above.

I think Paul's fix is right:
 "A validating recursive resolver sets the DO bit [RFC4035] to
  indicate that it wishes to receive DNSSEC RRs in the response."

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Tue, 7 Jun 2011 10:33:41 +0100

> indicate that it wishes to receive DNSSEC RRs in the response."

Although this ship has already sailed, the text above could be further  
improved IMO by inserting "and validate" after "receive".

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Jun 2011 07:49:40 -0400

At 13:50 -0700 6/6/11, Paul Hoffman wrote:
>How about instead "A validating recursive resolver sets the DO bit...",
>eliminating the (clearly not correct) "MUST"?

>  indicate that it wishes to receive DNSSEC RRs in the response."

Looking at the three suggestions, I agree with the rationale that 
Alex used.  I'm tempted to use more analogies, but he has 
sufficiently flogged the horse.  All three are options (Paul's, 
Brian's and Mark's) are valid alternatives but Alex is right that the 
problem here is the use of the RFC 2119 MUST, so I'd lean with Paul's 
option.

(I've had my head up the "compliance" pipe recently.  That's where 
this nit-picking is coming from.)

---

From: "Posner, Sebastian" <[email-masked]>
Date: Wed, 8 Jun 2011 13:02:57 +0200

Alex Bligh wrote:

> If we want to pick nits, there are 2 problems. One, as you've set out,
> there are other ways to get DNSSEC RRs. More significantly perhaps, 
> this isn't an RFC2119 "MUST" at all. Consider the ambiguous and 
> analagous sentence "You must take 280 to get to SFO quickly". 
> What this probably means is not that you MUST got to SFO quickly, 
> nor MUST go to SFO at all, but that if you want to get to SFO quickly, 
> taking 280 is the way to do it; it is not saying you "MUST" take 280 
> at all. I think the same applies to the sentence above.
> 

Why not rephrase it like you stated in your example: FIRST the 
condition THEN the measures that must be taken IF the condition is met.

"A validating recursive resolver that wishes to receive DNSSEC RRs 
in the response MUST set the DO bit [RFC4035] (in the question 
packet to indicate this)."

This points out that is is a 2119-MUST, but only if the condition is met.

Greets,

Sebastian
-- 
Sebastian Posner

---

From: Alex Bligh <[email-masked]>
Date: Wed, 08 Jun 2011 12:47:04 +0100

> This points out that is is a 2119-MUST, but only if the condition is met.

Because the "MUST" is not a requirement of
draft-ietf-dnsext-dnssec-algo-signal but a requirement of RFC4035 (from
memory). We, after all, don't specify all the other things they "MUST"
do to get DNSSEC to work.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jun 2011 23:27:48 +1000

> do to get DNSSEC to work.

The problem is that DNSSEC RRs includes DNSKEY, DS, RRSIG, NSEC and NSEC3
some of which can be queried for directly without setting DO.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 08 Jun 2011 15:07:16 +0100

That is one problem. But there is another, as I wrote previously:

> there are other ways to get DNSSEC RRs. More significantly perhaps, this
> isn't an RFC2119 "MUST" at all. Consider the ambiguous and analagous
> sentence "You must take 280 to get to SFO quickly". What this probably
> means is not that you MUST got to SFO quickly, nor MUST go to SFO at all,
> but that if you want to get to SFO quickly, taking 280 is the way to do
> it; it is not saying you "MUST" take 280 at all. I think the same applies
> to the sentence above.

This document does not mandate that DO is set for such a query; that
is the job of RFC4035. It is using "must" other than in an RFC2219 sense.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jun 2011 10:26:21 -0400

>some of which can be queried for directly without setting DO.

Why does everyone forget NSEC3PARAM?  Poor little record, gets no respect.

;)

All of the DNSSEC records can be queried "directly" without setting 
the DO.   All but NSEC3 match the query type any/all ("*").  Even the 
NSEC3 can be found in the answer section - if the QTYPE is AXFR or 
IXFR.

The sum of this is - Alex's comment is right.  It's certainly not a 
MUST and not even really a "must."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jun 2011 14:59:25 -0400

2011/5/25 Edward Lewis <[email-masked]>

> At 14:51 -0400 5/25/11, Patrik Fältström wrote:
>
>> As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, I
>> am hereby informing we today start a four week working group last call.
>>
>
>

I'm assuming you mean this document:
> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-01
>
> I don't support this document even though I support this ideal:
>
> #   This proposed EDNS option serves to measure the acceptance and use of
> #   new digital signing and hash algorithms.
>
> (That is - I don't think this document achieves its goal.)
>
> I get that it is good to know what the right algorithm (in the DNSSEC
> sense) to use is.  But I don't like the thought that a client's algorithm
> request would be used to alter the contents of an response.  It would be
> better to be aware of algorithms, what's deployed, and what to signed with
> in a strategic posture, not a tactical posture.
>
> In the document there is this in section 5:
>
> #   When an authoritative server sees the DAU option in the OPT meta-RR
> #   in a request the normal algorithm for servicing requests is followed.
>
> However, in 3.1 it says this:
>
> #   Typically, stub resolvers rely on an upstream recursive server (or
> #   cache) to provide a response; any algorithm support on the stub
> #   resolver's side SHOULD be honored (if possible) by an upstream
> #   recursive cache.
>
>
Propose change:
 "Typically, stub resolvers rely on an upstream recursive server (or cache)
to provide a response. So optimal use of the AU option depends on if the
stub resolver performs its own DNSSEC validation."

What if a server is both authoritative and an upstream recursive cache?  If,
> "honored" (in the latter draft fragment) means to send only the algorithm
> that is in the stub's request OPT RR, there's a conflict with
> "normal...servicing."
>
> I feel that this draft has the potential to open up a can of worms with
> interactions between signaling bits (namely DNSSEC OK in EDNS0 and the CD
> bit in the header) and having to deal up and down the authority to
> (validating) forwarder to (validating) cache to stub resolvers.
>
> I don't think that algorithm roll (or choice) is the issue we thought it
> was a few years ago when the idea behind this draft came up, i.e., I don't
> see the draft solving a real problem.  For example, it could be more likely
> that a recommendation will come out to change key size from 1024 to 2048
> than change from SHA-1 to SHA-256.  Recent haggling over hash algorithms has
> convinced me that attacks on hash algorithms aren't much of a threat because
> of the limited syntax of DNS records.  Perhaps even less of a threat than
> the difference in key lengths.
>
>
Not sure if I agree 100% (hence the draft).  See draft-ietf-dnsext-ecdsa-00
for an example.  The two algorithm codes refer to the same algorithm, but
with different curves as well as different hash algorithms.

> I don't think this option is needed now, and could cause architectural pain
> later on.
>
> PS :
>
> Section 4 shouldn't be there (at least not standalone).  And there is no
> reference or definition of "middlebox."
>
>
Section 4 was added because of a comment on an earlier version that
requested the section.  Propose changing to a more generic "Intermediate
System".

> (No EDNS0, no DO, but I get DNSKEY records back.)

Changed to remove the MUST based on on the thread comments.

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

---

From: Lutz Donnerhacke <[email-masked]>
Date: Wed, 8 Jun 2011 23:13:14 +0200

> Why does everyone forget NSEC3PARAM?  Poor little record, gets no respect.

That's not a record. It's a configuration entity at a terrible wrong place.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Jun 2011 08:35:50 -0400

On 08/06/2011 5:13 PM, Lutz Donnerhacke wrote:
> Edward Lewis<[email-masked]>  wrote:

<no-hat>
Just like the SOA record it is instructing Authoritative servers how to 
behave for a particular zone, I guess the SOA was also a mistake :-)

	Olafur
Ps: Feel free to blame me for the existence of the NSEC3PARAM record it
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Jun 2011 10:23:41 -0400

>behave for a particular zone, I guess the SOA was also a mistake :-)

Oddly, I had the same reaction as Olafur.  Where are my meds?

>Ps: Feel free to blame me for the existence of the NSEC3PARAM record it

Sigh, we'll just add *that* to the list
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Jun 2011 10:57:12 -0400

At 14:59 -0400 6/8/11, Scott Rose wrote:

>Proposed change:
>  "Typically, stub resolvers rely on an upstream recursive server (or cache) to
>provide a response. So optimal use of the AU option depends on if the stub
>resolver performs its own DNSSEC validation."

The latter sentence - The most appropriate use of the AU option is by 
a validating stub resolver performing validation only for its own 
protection, i.e., it does not intend to answer queries itself.

>Section 4 was added because of a comment on an earlier version that requested
>the section.  Propose changing to a more generic "Intermediate System".

Either way - the adjective used for "system" needs to be defined (in 
situ or via reference) at a minimum.  And there might be more 
expansion needed to justify it being a separate section.