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

2016-10-12 Thread Warren Kumari
On Mon, Oct 10, 2016 at 12:27 PM, Warren Kumari  wrote:
> UI
>
> On Monday, October 10, 2016, Bob Harold  wrote:
>>
>>
>> On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski  wrote:
>>>
>>>
>>> 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.
>>>
>> (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?
>
>
>
> 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.
>

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

> W
>
>
>
>>
>>
>> --
>> Bob Harold
>>
>
>
> --
> 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



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-10 Thread Tony Finch

John Levine  wrote:
> >Should we treat synthesis as if the cache is pretending to be an
> >authoritative server?
>
>
> 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]
> You can see that the wildcard is *.h.g.iana.fail.
>
> But query for e.h.g.iana.fail:
>
> ;; ANSWER SECTION:
> e.h.g.iana.fail.3600IN  A   2.2.2.2
> e.h.g.iana.fail.3600IN  RRSIG   A 8 4 3600
>   2016121100
> 20161010180056 31806 iana.fail.
>
> 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.

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.

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

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    http://dotat.at/  -  I xn--
  zr8h punycode

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-10 Thread John Levine
>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.

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.3510IN  A   2.2.2.2
a.h.g.iana.fail.3510IN  RRSIG   A 8 4 3600 2016121100 
20161010180056 31806 iana.fail. 
fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c 
XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 
6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
*.h.g.iana.fail.7110IN  NSECb.h.g.iana.fail. A RRSIG NSEC
*.h.g.iana.fail.7110IN  RRSIG   NSEC 8 4 7200 2016121100 
20161010180056 31806 iana.fail. 
iQF8nmONvtzkvDy+8QRjlRRI12+XyJ0XZG8jig/o7EJ21P/VShfE3I9W 
3E+JVnkKuYg3Wg3R4tSUSLVZKxVaL/yGSTDvI0+S4RfjNaTWoeuqb+qo 
vAw78j2TMjevWJPA+NhYjHqc6daB3b38kn5cN3vCYmAO1OR5pn+whdqN d94=
iana.fail.  3510IN  NS  sdn.iecc.com.
iana.fail.  3510IN  NS  osdn.iecc.com.
iana.fail.  3510IN  NS  light.lightlink.com.
iana.fail.  3510IN  RRSIG   NS 8 2 3600 2016121100 
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.3600IN  A   2.2.2.2
e.h.g.iana.fail.3600IN  RRSIG   A 8 4 3600 2016121100 
20161010180056 31806 iana.fail. 
fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c 
XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 
6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
b.h.g.iana.fail.7061IN  NSECmx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.7061IN  RRSIG   NSEC 8 5 7200 2016121100 
20161010180056 31806 iana.fail. 
hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 
7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 
ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.  3403IN  NS  sdn.iecc.com.
iana.fail.  3403IN  NS  osdn.iecc.com.
iana.fail.  3403IN  NS  light.lightlink.com.
iana.fail.  3403IN  RRSIG   NS 8 2 3600 2016121100 
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.  3600IN  A   1.1.1.1
i.g.iana.fail.  3600IN  RRSIG   A 8 3 3600 2016121100 
20161010180056 31806 iana.fail. 
u3icLxUEeJ2RMuhUufrhvze8hUAEkNCKPAfVHXYlQq7D1don0l4opjI2 
Sd6fxEPKcF8ah1vtCvIewFctbXQ/HH6gviKslrJekzJcX6PQccsMtygG 
SzAr3HyWf2HfcMfDJqW2PjP5v9teB/uR7KCWGbxYogFt+sEXu77xHhqi Kug=

;; AUTHORITY SECTION:
b.h.g.iana.fail.6796IN  NSECmx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.6796IN  RRSIG   NSEC 8 5 7200 2016121100 
20161010180056 31806 iana.fail. 
hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 
7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 
ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.  3138IN  NS  sdn.iecc.com.
iana.fail.  3138IN  NS  osdn.iecc.com.
iana.fail.  3138IN  NS  light.lightlink.com.
iana.fail.  3138IN  RRSIG   NS 8 2 3600 2016121100 
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 

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

2016-10-10 Thread Warren Kumari
UI

On Monday, October 10, 2016, Bob Harold  wrote:

>
> On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski  > wrote:
>
>>
>> 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.
>>
>> (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?
>


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




>
> --
> Bob Harold
>
>

-- 
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-10 Thread Bob Harold
On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski  wrote:

>
> 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.
>
> (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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-10 Thread Tony Finch
Warren Kumari  wrote:
>
> >
> > 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.
>
> NOT DONE.
> 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    http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-07 Thread Warren Kumari
On Thu, Oct 6, 2016 at 12:32 PM, Stephane Bortzmeyer  wrote:
> On Thu, Oct 06, 2016 at 02:53:38AM -0400,
>  Tim Wicinski  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.)

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

>
> 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.)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-07 Thread Warren Kumari
On Thu, Oct 6, 2016 at 7:18 AM, Tony Finch  wrote:
> I have read through the draft and sent a pull request with some minor
> editorial fixes.

Thank you. These have been accepted / incorporated.

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

No apologies needed, thanks for feedback.

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

Yup!

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

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


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

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

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

... probably :-)

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

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

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

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

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

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

2016-10-07 Thread Warren Kumari
On Fri, Oct 7, 2016 at 11:55 AM, Warren Kumari  wrote:
> On Thu, Oct 6, 2016 at 3:38 AM, Matthijs Mekking  
> wrote:
>> Hi,
>>
>> On 06-10-16 08:53, Tim Wicinski wrote:
>>>
>>> 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:
>>
>> I don't think my issues have been addressed in -03, except for the
>> bikeshedding Pull Request has been merged.
>
> 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

>
>>
>> Best regards,
>>   Matthijs
>>
>>
>>
>>
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>>
>>> and speak up with any final questions, concerns, etc.
>>>
>>> thanks
>>> tim
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> 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



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-07 Thread Warren Kumari
On Thu, Oct 6, 2016 at 3:38 AM, Matthijs Mekking  wrote:
> Hi,
>
> On 06-10-16 08:53, Tim Wicinski wrote:
>>
>> 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:
>
> I don't think my issues have been addressed in -03, except for the
> bikeshedding Pull Request has been merged.

Whoops, I got so excited by the pull req

>
> Best regards,
>   Matthijs
>
>
>
>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> and speak up with any final questions, concerns, etc.
>>
>> thanks
>> tim
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-06 Thread Stephane Bortzmeyer
On Thu, Oct 06, 2016 at 02:53:38AM -0400,
 Tim Wicinski  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.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-06 Thread Tony Finch
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    http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or
rough. Showers later. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2016-10-06 Thread Matthijs Mekking
Hi,

On 06-10-16 08:53, Tim Wicinski wrote:
> 
> 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:

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

Best regards,
  Matthijs




> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
> 
> and speak up with any final questions, concerns, etc.
> 
> thanks
> tim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop