Skip to main content

DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-05

Note: This ballot was opened for revision 04 and is now closed.

Joel Jaeggli Former IESG member
Yes
Yes (for -04) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) Yes
Yes (2016-08-23) Unknown
Thanks for adding alg 8 in response to my discuss. I think you might
want to do another editing pass just to check that the end result is
fully consistent, e.g. I'm not sure if alg 8 should also be mentioned in
section 1.3. The diff from -04 to -05 might also contain a few other
such things, but I'm in an airport now so better I clear the discuss 
and leave such tidying to you.

--- OLD COMMENTs below, I didn't check 'em vs. the latest
version

general, mostly 3.x.y: it'd have been nice to include a
dig command line for each of these tests - that'd save the
non-expert reader some time and allow easy scripting of
most of this BCP.

general: Why not say to include a test with a known, but
not well-known, public key (or DS) to check if anyone on
the path is fibbing? E.g. a tester could remember a few
public keys and check that they've not changed in a new
location.  While that may only catch out a cheating real
parent, did you consider including such a test?

- 3.1.4: How is a "recently defined type" a reasonable
thing to check for in a BCP? Seems odd anyway.

- 6.1: what if there is no user? Why not recommend telling
some network observatory? Aren't there some for DNSSEC?
Alexey Melnikov Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
I am agreeing with Terry's DISCUSS.

I think this is a useful document, but it is not entirely clear to me how well content of this document will age with time.

Nits:

In section 5:

  This will increase the likelihood that spit-view unsigned answers are found.

Should spit-view be split-view?

On page 14:
  For a stub resolver, problems with the name server MAY manifest themselves as the following types of error conditions:

This is not an implementation choice, so use of MAY is not appropriate. Change to "can" or the like.
Alia Atlas Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
I do agree with Terry's point.
Alissa Cooper Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
- Agree with Terry's DISCUSS.

- Sec. 2: The last paragraph here isn't really about "goals" and seems like it belongs more appropriately in Sec 3.

- Sec 6.1: I thought recently gathered data has been pointing to the futility of popping up security warnings (e.g., http://neurosecurity.byu.edu/media/Anderson_et_al._CHI_2015.pdf). Does it really make sense to recommend warning users in a BCP? What are users expected to do as a result? Is there any evidence about the proportion of users who even know what DNSSEC is?
Alvaro Retana Former IESG member
No Objection
No Objection (2016-07-07 for -04) Unknown
Just for good measure: I also agree with Terry's DISCUSS.
Ben Campbell Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
- I support Terry's discuss. 

- 1.2, 2nd paragraph: Is "full non-support" effectively different from "non-support" in this context?

Do we have reason to expect the github project to be maintained for the life of the RFC?

- 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org domain will be maintained for the life of the RFC?

- 5:

The first paragraph seems to say that the document does not accomplish it’s goal. Is that really the intent? (And doesn't the document at least do some of that?) 

"... we can determine what MUST be done in order..."
Spurious 2119 MUST

"short-circuit any unnecessary fallback attempts.":  Does "short circuit" mean the same as "avoid" in this context?

"problems with the name server MAY manifest": Spurious 2119 "MAY"

- 5.1, "It MAY be possible...": Spurious 2119 "MAY"

-5.1.2: s/real/really

- 6: "A newly established network connection MAY change state...": Spurious 2119 "MAY"

-8: Seems like there could be  more to say about the potential consequences about the “fail or proceed without security” decision in 6 and 6.1.
Benoît Claise Former IESG member
No Objection
No Objection (2016-07-07 for -04) Unknown
Here is Eric Vyncke's (pretty knowledgeable security expert) OPS DIR review (you'll see that it's in line with Terry's DISCUSS point): 
Based on my operational experience, I have seen multiple DNSSEC packets dropped by firewalls because they try to use EDNS0 rather than fragmenting. Does your I-D also address this issue?

I am a little puzzled by the hand waving "we also assume that the path is clear of "DNS interfering" crap-ware/middle-boxes, like stupid firewalls, proxies, forwarders." (I would avoid the use of "stupid") This restriction does not appear as realistic to me in the current deployment.

In the wave of IPv6 deployment and IPv4 sunset, I would suggest that examples (such as in 3.1.1) uses AAAA RR and not A.

It is a little unclear to me WHEN the host should run those test? At boot time? At every network attach? When it resumes operation after a sleep period? Or a periodic test (such as hourly) ? This could cause a scalability problem in vast WiFi deployment.

I am also a little puzzled by another hand waving "The goal of this document is to tie the above tests and aggregations to avoidance practices; however the document does not specify exactly how to do that." and later "Else return an useful error code" which will make interoperation (API portability) complex.

With a little improvement for some unclear (to me) text, this document could be useful. Especially if either the mitigation part is improved or removed completely.

I hope the above will help to improve a very useful document
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
I support Stephen & Terry's discuss points.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-07-04 for -04) Unknown
1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a real test?

2) To follow up with the tsv-art review: To avoid network as well as server overload, would it be useful to provide further guidance, when and how often these tests should be performed?

3) In section 6.1.  (What To Do): maybe also list logging as an option in cases where no user is directly involved but a human might check later.
Spencer Dawkins Former IESG member
No Objection
No Objection (2016-07-05 for -04) Unknown
This was an entertaining read. 

I share Mirja's comments. In addition:

I'm not sure how well ESL readers will understand "crap-ware"/"crap" in this passage ("crap-ware" is probably a reasonable term of art, if it's intelligible enough to readers):

   NOTE: when performing these tests we also assume that the path is
   clear of "DNS interfering" crap-ware/middle-boxes, like stupid
   firewalls, proxies, forwarders.  Presence of such crap can easily
   make the recursive resolver look bad.  It is beyond the scope of the
   document as how to test around the interference.

I'm not sure what "ideally MUST" means, in 

   However, querying many zones will
   result in answers greater than 1220 bytes so ideally TCP MUST be
   available.
Suresh Krishnan Former IESG member
No Objection
No Objection (2016-07-06 for -04) Unknown
Agree with Terry's DISCUSS and COMMENTs
Terry Manderson Former IESG member
(was Discuss) No Objection
No Objection (2016-08-11) Unknown
Thank you for addressing my DISCUSS (and other comments) in this new version.

Clearing my DISCUSS.