Subject: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Oct 2016 02:53:38 -0400

Just a reminder that the WGLC for  draft-ietf-dnsop-nsec-aggressiveuse 
will end later today (barring any stuck issues).  The authors appear to 
have addressed all open issues (except JINMEI's last comments).  Please 
read the current version here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

and speak up with any final questions, concerns, etc.

thanks
tim

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 6 Oct 2016 09:38:13 +0200

Hi,

> read the current version here:

I don't think my issues have been addressed in -03, except for the
bikeshedding Pull Request has been merged.

Best regards,
  Matthijs

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Oct 2016 12:18:28 +0100

I have read through the draft and sent a pull request with some minor
editorial fixes.

Here are some more substantial suggestions / questions. Sorry for being so
late in the process.

Would it make sense to be more specific about how to match queries to
cached NSEC/NSEC3 records? By cross-referencing to the relevant part of
the NSEC and NSEC3 specs, rather than repeating.

The draft seems to imply that only one NSEC record is needed for denial of
existence, and that wildcards are only problematic for NSEC3 - but
wildcards can also trip up NSEC, if the covering NSEC does not also cover
a relevant wildcard.

eg (modified text) ...

5.1.  NSEC

   Implementations which support aggressive use of NSEC SHOULD enable
   this by default.  Implementations MAY provide a configuration switch
   to disable aggressive use of NSEC and allow it to be enabled or
   disabled per domain.

   The validating resolver needs to check the existence of an NSEC RR
   matching/covering the source of synthesis and an NSEC RR covering the
   query name.

   If denial of existance can be determined according to the rules set out
   in RFC 4035 section 5.4, using NSEC records in the cache, then the
   resolver can immediately return an NXDOMAIN or NODATA response.

5.2.  NSEC3

   A validating resolver implementation MAY support aggressive use of
   NSEC3.  If it does aggressive use of NSEC3, it MAY provide a
   configuration switch to disable aggressive use of NSEC3 and allow it
   to be enabled or disabled for specific zones.

   NSEC3 aggressive negative caching is more difficult.  If the zone is
   signed with NSEC3, the validating resolver needs to check the
   existence of non-terminals and wildcards which derive from query
   names.

   If denial of existance can be determined according to the rules set out
   in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the
   cache, then the resolver can immediately return an NXDOMAIN or NODATA
   response.

TTLs

Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA
MINIMUM field. This is not quite the same as RFC 2308 negative cache entry
TTL, which is the minimum of the SOA MINIMUM and SOA TTL.

Should there be text along the lines of:

5.3.  Consideration on TTL

   The TTL value of negative information is especially important,
   because newly added domain names cannot be used while the negative
   information is effective.

   Section 5 of RFC 2308 states that the maximum number of negative cache
   TTL value is 3 hours (10800).  It is RECOMMENDED that validating
   resolvers limit the maximum effective TTL value of negative responses
   (NSEC/NSEC3 RRs) to this same value.

   Section 5 of RFC 2308 also states that a negative cache entry TTL
   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
   This can be less than the TTL of an NSEC or NSEC3 record, since their
   TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and
   RFC 5155 section 3.)

   A resolver that supports aggressive use of NSEC and NSEC3 should reduce
   the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in
   the authority section of a negative response, if the SOA TTL is
   smaller.

Wildcards

Should the box in section 7 say "positive responses" instead of "negative
responses"?

If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
and RFC 5155 section 8.8 which both discuss validating positive wildcard
responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
text if you want.

Security Considerations

This should mention the impact of replay attacks. Something like,

	Although the TTL of NSEC/NSEC3 records is typically fairly short
	(minutes or hours), their RRSIG expiration time can be much
	further in the future (weeks). An attacker who is able to
	successfully spoof responses might poison a cache with old
	NSEC/NSEC3 records. If the resolver is NOT making aggressive use
	of NSEC/NSEC3, the attacker has to repeat the attack for every
	query. If the resolver IS making aggressive use of
	NSEC/NSEC3, one successful attack would be able to suppress many
	queries for new names, up to the negative TTL.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or
rough. Showers later. Good.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Oct 2016 18:32:17 +0200

On Thu, Oct 06, 2016 at 02:53:38AM -0400,
 Tim Wicinski <[email-masked]> wrote 
 a message of 17 lines which said:

> Just a reminder that the WGLC for
> draft-ietf-dnsop-nsec-aggressiveuse will end later today (barring
> any stuck issues).  The authors appear to have addressed all open
> issues

The way I understand it, in -03, there is no more *positive* answers
(NOERROR synthetized from a wildcard in the cache), only negative ones
(NXDOMAIN). Am I correct? (If so, I agree with the change.)

If this is true, then I would suggest some work on rewriting section 7
new text for updating RFC 4035. True, the cache needs to look at
wildcards to see if it can synthetize NXDOMAINs or not but the way it
is written, it is confusing, since a wildcard would *prevent*
synthesis. May be:

   Once the records are validated, DNSSEC enabled validating
   resolvers MAY use NSEC/NSEC3 resource records
   to generate negative responses until their effective TTLs   
   or signatures for those records expire. (This requires to also
   check there is no wildcard applicable for the QNAME.)

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 7 Oct 2016 14:34:51 +0200

Tony,

> the NSEC and NSEC3 specs, rather than repeating.

That would make total sense (at least for me). I tried to achieve that 
with my suggested text by repeating it, perhaps it's good enough to 
cross-reference. I am a bit worried though that the process for 
returning NSEC(3) records by an authoritative name server is slightly 
different than the process of for searching NSEC(3) records by a 
validating caching resolver, so that may be an argument for the 
repeating proposal.

Best regards,
   Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 11:55:23 -0400

> bikeshedding Pull Request has been merged.

Whoops, I got so excited by the pull req

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 11:58:51 -0400

> Whoops, I got so excited by the pull req

(.... apparently *really* excited, because I sent this before
finishing the reply!. Continuing....)

Whoops, I got so excited by the pull request that I skipped over the
rest of your mail :-)
I had removed the positive responses bit, but the WG seems to still
want it, so I'll be re-adding it. I think that that voids your
comment, but *please* let me know if I'm wrong -- I *hope* to publish
a new version later today, or possibly Sunday.

W

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 15:03:13 -0400

> I have read through the draft and sent a pull request with some minor

Thank you. These have been accepted / incorporated.

> Here are some more substantial suggestions / questions. Sorry for being so

No apologies needed, thanks for feedback.

>
> Would it make sense to be more specific about how to match queries to"

Yup!

>    resolver can immediately return an NXDOMAIN or NODATA response.

DONE.
Thank you for providing text. It certainly makes it easier to
understand / address comments.

>    cache, then the resolver can immediately return an NXDOMAIN or NODATA

DONE.
Thank you -- I reordered / reworded things slightly to make it flow
somewhat better, but it is basically still your text.

> Should there be text along the lines of:

... probably :-)

>    the authority section of a negative response, if the SOA TTL is

DONE.
This is great. I used your text, thank you.

> responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide

NOT DONE.
Yes please. That would be awesome!
I had removed Section 7 (Wildcards) because I thought that that was
what the WG wanted, but I apparently misjudged that. I have now put it
back, and tried to reconcile the positive and negative test, but do
not have any text like the above. I'd really appreciate some!

I have put beck the original Wildcard text, and am committing it to
GitHub. I will then try address the original wording issues which made
me remove it in the first place...

>         queries for new names, up to the negative TTL.

DONE.
Excellent. Incorporated. Thank you.

Thank you, I really appreciate everyone's assistance.
W

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 15:07:15 -0400

> (NXDOMAIN). Am I correct? (If so, I agree with the change.)

Yes, you *were* correct -- however, since then the WG has demanded^w
requested that we re-introduce the positive answer text, and so I have
just committed that to Github.
I have not yet, however, incorporated your original text fixup, I'll
do that now...

W

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Oct 2016 13:37:27 +0100

> Yes please. That would be awesome!

Thinking about wildcards makes me wonder if we need to approach this whole
idea from two directions - firstly, how the validator proves to itself
that it can synthesize a negative response or a wildcard response; and
secondly, how it can prove that it did the right thing to a downstream
validator. At the moment the draft talks about the first aspect, but not
very much the second.

Specifically,

Should we treat synthesis as if the cache is pretending to be an
authoritative server?

e.g. for wildcards and NSEC3, something like,

	When synthesizing a wildcard response from its cache, the
	validating resolver MUST include all the records specified in
	RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6
	(for positive responses). That is, it MUST generate a response
	that matches what an authoritative server would send. If the
	required records are not present in the cache, the resolver SHALL
	query upstream instead of synthesizing the response.

If this makes sense then the other cases should be adjusted to describe
things in a similar way, e.g. referring to section 7 of RFC 5155 instead
of (or as well as?) section 8, and section 3.1 instead of / as well as
section 5 of RFC 4035.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.

---

From: Bob Harold <[email-masked]>
Date: Mon, 10 Oct 2016 12:06:58 -0400

On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski <[email-masked]> wrote:

> (Reading the version at
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse in case it
is different)

Section "3. Problem Statement"
The example domain includes a wildcard, but the text reads as though the
answer to "cat.example.com" would be that is does not exist.  Should the
wildcard be removed for this example?

-- 
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Mon, 10 Oct 2016 12:27:57 -0400

UI

On Monday, October 10, 2016, Bob Harold <[email-masked]> wrote:

>
> On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>> (Reading the version at https://github.com/wkumari/draft-ietf-dnsop-nsec-
> aggressiveuse in case it is different)
>

Doh!
Yes, yes it should.
I was trying to avoid having two separate example zones, but, well,
premature optimization and all that.. The way it is now is, um, just wrong.

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2016 18:10:43 -0000

>	query upstream instead of synthesizing the response.

Yes, although it's kind of subtle.  For example, I query for a.h.g.iana.fail:

;; QUESTION SECTION:
;a.h.g.iana.fail.		IN	A

;; ANSWER SECTION:
a.h.g.iana.fail.	3510	IN	A	2.2.2.2
a.h.g.iana.fail.	3510	IN	RRSIG	A 8 4 3600 20161211000000 20161010180056 31806 iana.fail. fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
*.h.g.iana.fail.	7110	IN	NSEC	b.h.g.iana.fail. A RRSIG NSEC
*.h.g.iana.fail.	7110	IN	RRSIG	NSEC 8 4 7200 20161211000000 20161010180056 31806 iana.fail. iQF8nmONvtzkvDy+8QRjlRRI12+XyJ0XZG8jig/o7EJ21P/VShfE3I9W 3E+JVnkKuYg3Wg3R4tSUSLVZKxVaL/yGSTDvI0+S4RfjNaTWoeuqb+qo vAw78j2TMjevWJPA+NhYjHqc6daB3b38kn5cN3vCYmAO1OR5pn+whdqN d94=
iana.fail.		3510	IN	NS	sdn.iecc.com.
iana.fail.		3510	IN	NS	osdn.iecc.com.
iana.fail.		3510	IN	NS	light.lightlink.com.
iana.fail.		3510	IN	RRSIG	NS 8 2 3600 20161211000000 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

You can see that the wildcard is *.h.g.iana.fail.

But query for e.h.g.iana.fail:

;; QUESTION SECTION:
;e.h.g.iana.fail.		IN	A

;; ANSWER SECTION:
e.h.g.iana.fail.	3600	IN	A	2.2.2.2
e.h.g.iana.fail.	3600	IN	RRSIG	A 8 4 3600 20161211000000 20161010180056 31806 iana.fail. fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
b.h.g.iana.fail.	7061	IN	NSEC	mx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.	7061	IN	RRSIG	NSEC 8 5 7200 20161211000000 20161010180056 31806 iana.fail. hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.		3403	IN	NS	sdn.iecc.com.
iana.fail.		3403	IN	NS	osdn.iecc.com.
iana.fail.		3403	IN	NS	light.lightlink.com.
iana.fail.		3403	IN	RRSIG	NS 8 2 3600 20161211000000 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

You can see that it's synthesized from a wildcard, but you can't tell whether the wildcard was
*.iana.fail or *.g.iana.fail or *.h.g.iana.fail.

And if I query for i.g.iana.fail:

;i.g.iana.fail.			IN	A

;; ANSWER SECTION:
i.g.iana.fail.		3600	IN	A	1.1.1.1
i.g.iana.fail.		3600	IN	RRSIG	A 8 3 3600 20161211000000 20161010180056 31806 iana.fail. u3icLxUEeJ2RMuhUufrhvze8hUAEkNCKPAfVHXYlQq7D1don0l4opjI2 Sd6fxEPKcF8ah1vtCvIewFctbXQ/HH6gviKslrJekzJcX6PQccsMtygG SzAr3HyWf2HfcMfDJqW2PjP5v9teB/uR7KCWGbxYogFt+sEXu77xHhqi Kug=

;; AUTHORITY SECTION:
b.h.g.iana.fail.	6796	IN	NSEC	mx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.	6796	IN	RRSIG	NSEC 8 5 7200 20161211000000 20161010180056 31806 iana.fail. hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.		3138	IN	NS	sdn.iecc.com.
iana.fail.		3138	IN	NS	osdn.iecc.com.
iana.fail.		3138	IN	NS	light.lightlink.com.
iana.fail.		3138	IN	RRSIG	NS 8 2 3600 20161211000000 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

I get a different synthesized answer because in this case, there's one
wildcard for *.g.iana.fail and another one for *.b.g.iana.fail.

That's OK, and I believe it is straightforward for a cache to tell
what names it can synthesize and what names it can't, but it means
it'd probably be a good idea to make it clear that if there are other
names in the wildcard's range, the cache often can't synthesize
results.

R's,
John

PS: These names are real, feel free to poke at them.

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Oct 2016 19:37:36 +0100

John Levine <[email-masked]> wrote:
> Yes, although it's kind of subtle.

Yep, that's kind of why I am suggesting a more detailed spec but also
trying to leave as much as possible to the existing intricate
documentation.

>  For example, I query for
> a.h.g.iana.fail:
[snip]
> e.h.g.iana.fail.        3600    IN      RRSIG   A 8 4 3600
>       20161211000000
> 20161010180056 31806 iana.fail.
>

Ah, but that is what the label count (4) is for in the RRSIG A. The
QNAME has 5 labels so you know the RRSIG belongs to *.h.g.iana.fail, and
you have to work this out in order to validate it.

> names in the wildcard's range, the cache often can't synthesize

And the rules for authoritative servers say which records you have to
put in the answer, so I think it is enough for the cache to check that
it already has the right ones.

In your examples, the first NSEC covered *.h.g to b.h.g proving that
a.h.g did not exist and could be the result of wildcard expansion. In
the second query, e.h.g is outside that NSEC's range, so although the
cache knows it e.h.g is a candidate for wildcard synthesis, it
doesn't have the nonexistence proof, so it has to query upstream. And
it knows what nonexistence proof it needs from the rules for
authoritative answers.

I think something that might need saying (it probably isn't in the
existing specs) is that the validator should cache the wildcard record
that it retconned from the answer (*.h.g in this example). Or maybe it
is obvious from the fact that it is being used for synthesis :-)

Tony (sorry this is a bit vague and off the cuff).
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Oct 2016 13:23:17 -0400

On Mon, Oct 10, 2016 at 12:27 PM, Warren Kumari <[email-masked]> wrote:
>>> will end later today (barring any stuck issues).  The authors appear to have
>>> addressed all open issues (except JINMEI's last comments).  Please read the
>>> current version here:
>>>
>> https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse in case it is
>> different)
>>

... and I have just broken the example into two zones to address this
(example.com, example.org), and checked it into Github - please see
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse

I'd really like some help writing / expanding the wildcard text -- I'd
initially removed the "positive" side because I wasn't sure how to
concisely / clearly describe it[0].

If anyone has text which they'd be willing to contribute, it would be
gratefully accepted.

W
[0]: Ok, I'll be completely honest - this was also way easier :-P