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

[Ted Lemon <[e-mail]>]

Comments below.   Executive summary: everything's fine except I'm still not convinced nothing needs to be done about point 3 of my DISCUSS.   I will be incommunicado between Christmas and 1/5, and to some extent possibly sooner, so a quick response is essential if you are hoping to have this DISCUSS cleared before I get back.   (I realize that I took a while responding as well; this isn't intended to imply a criticism, but I figured I should let you know.)

Thanks!

On Nov 26, 2014, at 7:55 PM, Wes Hardaker <[e-mail]> wrote:
> * 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?

The danger of responding to a DISCUSS 78 days later is that the AD who put the DISCUSS on the document won't remember why, and unfortunately this is the case here.   The comment made sense to me at the time; looking at the document now, I am unable to see what I was concerned about here.   So I will clear this one, based on the hope that what you did to address my concern is beneficial.   If you are on the fence about adding that text and want to take it back out, at the time of this reading I have no basis for insisting otherwise.   Sorry about that.

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

Thanks!

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

Again, recollection is foggy, but e.g. what if some implementation decides it would be clever to use child synchronization to update DS records?  You say in the introduction that this document isn't supposed to support doing that, but you don't explicitly exclude DS records anywhere.   This concern is (IIRC) what triggered the comment.

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

OK

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

Good, thanks!