[DNSOP] IESG COMMENT/DISCUSSION responses to the dnsop-child-sync draft

[Wes Hardaker <[e-mail]>]

After *way* too long of a delay (entirely my fault), here are some
responses to the IESG about the comments and discusses on the document.
It's close to finalized I hope, and I did publish a -04 to reflect the
changes made below.  Below is a list of the IESG member's and their
comments, as well as responses to them from me (starting with a marking
of "WJH:").

Notes from IESG review (of -03):

* DONE Alia Atlas

*** DONE First sentence in Sec 1 is missing an it:
    :LOGBOOK:
    - State "DONE"       from "TODO"       [2014-11-25 Tue 16:05]
    :END:
    "This document specifies how a child zone in the DNS ([RFC1034],
       [RFC1035]) can publish a record to indicate to a parental agent that
       can copy and process certain records from the child zone."

    WJH: Added

*** DUP In Sec 2: What does unpunishable data mean in
    :LOGBOOK:
    - State "DONE"       from "TODO"       [2014-11-25 Tue 16:06]
    :END:
    "Errors due to unsupported Type Bit Map bits, or otherwise
    nonpunishable data, SHALL result in no change to the parent zone's
    delegation information for the Child."

    WJH: It was a typo and already changed to "publishable"

*** DONE In Sec 3.1:

    It says " If the SOA serial numbers are equal but less than the
    CSYNC record's SOA Serial Field [RFC1982], the record MUST NOT be
    processed."  which seems to contradict what is stated in Sec
    2.1.1.1 "If the soaminimum flag is not set, parental agents MUST
    ignore the value in the SOA Serial Field.  Clients can set the
    field to any value if the soaminimum flag is unset, such as the
    number zero."

    Perhaps I'm missing a relevant DNS clue?

    WJH: good catch!  Changed to "If the soaminimum flag is set and the
    SOA serial numbers are equal but less than the CSYNC record's SOA
    Serial Field..."

* DONE Barry Leiba

*** DONE In the definition of the CSYNC Flags registry in the IANA
    Considerations, you have two conflicting statements:

    ONE:
       Assignment of new flag values are subject to
       "RFC Required" specifications [RFC5226].

    TWO:
       For new assignments to be made to this registry, a new RFC must be
       published via a Standards Action.

    Which is it: RFC Required, or Standards Action?  They are
    different (the former allows for Experimental or Informational
    RFCs, and RFCs in the Independent or IRTF streams; the latter
    requires a Standards Track RFC in the IETF stream).  There's
    also "IETF Review", which requires an IETF stream RFC, but
    allows Informational or Experimental).

    WJH: Changed to be standards-track

* DONE Pete Resnick

*** DONE Sections 4.2, 4.3, and 4.4:

    The MAYs in there MAY be inappropriate. The ones about providing
    interfaces sure don't seem like protocol options. On the others
    it's hard to tell. Please review. The SHOULDs in 4.1 and 4.4 seems
    also suspiciously wrong.


    Pete: last time I responded with the following comment.  Maybe it
    wasn't read, as the same comment is being repeated without a
    response to the following comment: 

	+ WJH: I changed a few of the MAYs, but most seemed appropriate.
          The SHOULD on the documentation is somewhat important, as
          without documentation from the parental agent stating they
          support the CSYNC type, and how they're making use of it,
          clients have no way to know whether the protocol can be
          used.  There is no discovery that you get something good
          from your parent if you publish a CSYNC record.  The parent
          must document they're support for children to know they can
          make use of it.

   Since you added additional text addressing the API related concern,
   I changed one MAY to a "may" in the following sentence:

        -   <t>Parental agents MAY offer a configuration interface to allow
        +   <t>Parental agents may offer a configuration interface to allow
            child operators to specify which nameserver should be considered
            the master to send data queries too.

   The 4.3 section didn't have similar MAYs, so I didn't do
   anything about them.

   In 4.4, I made the following change:

        -  <t>The frequency with which they poll clients (which MAY
        +  <t>The frequency with which they poll clients (which may
           also be configurable by the client)</t>


   For the SHOULD in 4.1, I downcased it as well:

        - Parental agents SHOULD, at a
        + Parental agents should, at a
          minimum, at least log errors encountered when processing CSYNC
          records.

   For the SHOULD in 4.4, I didn't change it.  Because, as mentioned
   previously, publicly documenting the parameters is fairly
   important.

   Maybe these address your concerns?  Your previous comment was
   rather vague in exactly what your issues were, so I'm guessing at
   what you wanted done.

* DONE Richard Barnes

*** DONE Adding on to Ted's DISCUSS:

    The Security Considerations need to make clear that this
    mechanism MUST NOT be used to synchronize DS records between
    child and parent (whether this is allowed through the base
    protocol or some extension).  This is because the DS records are
    the only thing the parent has that allows it to validate all the
    DNSSEC signatures that it is required to verify -- if an
    attacker can change the DS record, then it can change any other
    record it wants to.

    WJH: Ok, I added the following two middle sentences, marked with
    [new].  Do they seem sufficient?

    ... DNSSEC-secured operating environment in place.
    Additionally, this specification was not designed to synchronize
    DNSSEC security records, such as DS pointers.  [new] Thus,
    implementations of this protocol MUST NOT use it to synchronize
    DS records or DNSKEY materials. [new] Similarly, future
    documents extending this protocol MUST NOT offer the ability to
    syncronize DS or DNSKEY materials. For such a solution, please
    see the ...

    [the document makes it pretty clear in a number of places this
    must not be done, including the fact you aren't supposed to even
    use bits that aren't documented and the DS bit wasn't defined,
    but that being said: it's a good point that it should be well
    stated in the security considerations; thanks]

* DONE Stephen Farrell

*** DONE 
    - general: Couldn't a child ask for its CSYNC record to be
    published in the parent? (and so on up...) I think you should
    say a parent MUST NOT take a child's CSYNC in the same way
    that you say to not use CSYNC for DS RRs.

    WJH: added a note mentioning that CSYNC, CDS, CDNSKEY records
    MUST NOT be synchronized.

    [note, however, that a parent publishing a CSYNC record at the
    parent *for the child* would certainly be interesting and really
    only affect broken resolvers that were willing to accept
    non-authoratative answers; none the less, I don't mind
    mentioning it]

*** DONE 
    - 2.1.1.2.1: Is the meaning of "blindly" sufficiently clear
    that all implementers and deployers will get this right?
    I'm willing to believe you if you say it is.

    WJH: made the following change, which seems sufficient?:

      -  Specifically: a parental agent must not copy data blindly
      +  Specifically: a parental agent must not just copy the data


* DONE Ted Lemon

*** DONE Point 1--

    2.1.1.1 doesn't talk about SOA serial number overflow.  It's not clear to me
    that the security goal intended by this section is correctly addressed if the
    implementation assumes that the comparison operators defined in section 3.2 of
    RFC 1982 are used, rather than doing a simple unsigned compare.

    I don't think there's a clearly correct answer here, but the issue should be
    documented and, ideally, a choice should be made.   To clear this DISCUSS, the
    document needs to say which of the two sets of comparison operators apply, and
    needs to explain how serial number wrap events are accounted for (or that they
    are not accounted for, and this is an open issue with security implications).

    The easiest way to fix this would be to require a comparison for equality, but
    I realize that this would place an additional burden on implementations which
    may be impractical.

    WJH: Of all the comments received this one confuses me the most.
    Mostly because I think 1982 is quite clear about how to do the
    comparison operator and there is only one, the "less than"
    operation and it is discussed in 3.2 of 1982.  So, I'm not
    entirely clear what you're looking for.  I can add some text to
    explicitly mention wrapping, but that is exactly what 1982 is
    about: how to do comparisons with wrapping.  So, trying to add
    something that at least more explicitly mentions what I think
    you're looking for, I added this to the bottom 2.1.1.1:

        <t>Although Section 3.2 of <xref target="RFC1982" />
        describes how to properly implement a less-than comparison
        operation with SOA serial numbers that may wrap beyond the
        32-bit value in both the SOA record and the CSYNC record, it
        is important than a child using the soaminimum flag must not
        increment it's SOA serial number value more than 2^16
        (including any 32-bit wrapping) within the period of time
        that a parent might wait between polling the child for the
        CSYNC record.</t>

    It's actually not a security feature so much as a operational
    feature to prevent a parent from toggling back and forth between
    two values if one nameserver does not have the most recent data
    set.  But, the DNSSEC signature lifetimes could be long enough
    to allow for replays if the serial numbers increased by more
    than 2^16 within it.  So...  I added this:

        <t>To ensure that an older CSYNC record making use of the
        soaminimum flag can not be replayed to revert values, the SOA
        serial number MUST NOT be incremented by more than 2^16
        during the lifetime of the signature window of the associated
        RRSIGs signing the SOA and CSYNC records.  Note that this is
        independent of whether or not the increment causes the 2^32 bit
        serial number field to wrap.</t>

    Is this (these) sufficient to address your concerns?

*** DONE Point 2--

    In 3.2.1, you don't say what to do if the name server returns an NS record
    listing names queries on which result in NXDOMAIN, or for which neither A nor
    AAAA records exist.

    WJH: To the last paragraph of the NS section, I added two sentences:

      - 2 NS records").</t>
      + 2 NS records").  Parental agents MUST NOT perform NS updates
      + if there are no NS records returned in a query, as verified by
      + DNSSEC denial of existence protection.  This situation should
      + never happen unless the child nameservers are misconfigured.</t>

    WJH: and to the address section, added:

      - records for the child should be an empty set.
      + records for the child should be an empty set.  However, if the
      + end result of processing would leave no glue records present
      + in the parent zone for any of the of the in-bailiwick NS
      + records, then the parent MUST NOT update the glue address
      + records.  I.E., if the result of the processing would leave no
      + in-bailiwick A or AAAA records when there are in-bailiwick NS
      + records, then processing of the address records can not happen
      + as it would leave the parent/child relationship without any
      + address linkage.

*** NOFIX Point 3--

    I don't think you've specifically excluded RRtypes not mentioned in section
    3.2.  It's seems obvious to me based on what's stated in section 2 that the
    intention of the document is to only support these two RRtypes, but I think it
    is necessary to say so explicitly, if that is in fact what is intended.   If
    something else is intended, text explaining what is intended should be added.  
    E.g., if it's okay for cooperating child name servers to set bits not listed
    here, and for cooperating parent name servers to process them, you should say
    so.

    WJH: This is stated, and I think you missed it.  Section
    2.1.1.2.1 (about the type bit map field) states (slightly
    different based on a comment from Stephen, who did see it):

        Specifically: a parental agent must not just copy the data
        and must understand the semantics associated with an bit in
        the Type Bit Map field that has been set to 1.

    Let me know if you think this is insufficient.

*** DONE In 2.1.2, why SHOULD and not MUST here?

          Implementations that support parsing of presentation format
          records SHOULD be able to read and understand these TYPE
          representations as well.

    WJH: Because parsers don't necessarily need to understand the
    semantics of the record.  They just need to be able to keep
    reading and store the data.  Storing the data in ascii text is
    just fine if they're not going to process it in any other way.
    It'd be better if they understood it, but I can see cases where
    they don't full support everything (eg, new types listed even
    though they know some of them).

*** DONE In 3.2.1, what happens if the parent queries a host, and that host no longer
    appears in the updated NS record?   I think this is Mostly Harmless, but might
    be worth mentioning.   Also, in principle if the old server is left running but
    no longer authoritative, this whole scheme would fail if, for example, it had
    been the master prior to the change, were not configured to no longer serve the
    zone, and were no longer being updated.   This is probably worth mentioning as
    an operational consideration.

    WJH: Added the following text updates to address these points:

    To the bottom of section 3.2.1:
      <t>Note that it is permissible for a child's nameserver to
      return a CSYNC record that removes the queried nameserver
      itself from the future NS or address set.</t>

    To the bottom of section 4.2:

      <t>Children that wish to phase out a nameserver will need to
      publish the CSYNC record to the nameserver being removed and
      wait for the parental agent to process the published record
      before turning off the service.  This is required because the
      child can not control which nameserver in the existing NS set
      the parental agent may choose to query when performing CSYNC
      processing.</t>

-- 
Wes Hardaker
Parsons