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

Wes Hardaker <wjhns1@hardakers.net> Thu, 18 December 2014 19:32 UTC

From: Wes Hardaker <wjhns1@hardakers.net>
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <0l4mtljwc5.fsf@wjh.hardakers.net> <8971F043-7DBC-4FD4-8BFD-C4B39090BF84@nominum.com>
Date: Thu, 18 Dec 2014 11:31:43 -0800
In-Reply-To: <8971F043-7DBC-4FD4-8BFD-C4B39090BF84@nominum.com> (Ted Lemon's message of "Tue, 16 Dec 2014 14:40:20 -0500")
Message-ID: <0lfvccoiu8.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/erzRN7Y1SLCMV0-_wDiLsMam1u4
Cc: dnsop@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
Subject: Re: [DNSOP] IESG COMMENT/DISCUSSION responses to the dnsop-child-sync draft
Precedence: list

Ted Lemon <Ted.Lemon@nominum.com> writes:

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

Not a problem.  It's not like I can talk!
>> *** 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.

Due to some other comments, the following text was put into place and is
already in my (not yet published) document.  This exists in the security
considerations:

   Thus, implementations of this protocol
   MUST NOT use it to synchronize DS records, DNSKEY materials, CDS
   records, CDNSKEY records, or CSYNC records.  Similarly, future
   documents extending this protocol MUST NOT offer the ability to
   synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or
   CSYNC records.  For such a solution, please see the complimentary
   solution [RFC7344] for maintaining security delegation information.

Does this (end-of-a) paragraph solve your problem?
-- 
Wes Hardaker
Parsons

[DNSOP] IESG COMMENT/DISCUSSION responses to the … Wes Hardaker
Re: [DNSOP] IESG COMMENT/DISCUSSION responses to … Ted Lemon
Re: [DNSOP] IESG COMMENT/DISCUSSION responses to … Wes Hardaker
Re: [DNSOP] IESG COMMENT/DISCUSSION responses to … Ted Lemon