On Thursday, June 5, 2014, Brian E Carpenter <[email protected]> wrote:
> Totally bizarre. I found them in the trash on my gmail account, > but no trace of them in my local Gen-ART inbox. > > Presumably there was some finger trouble. I apologise, Nah, no worries, mate.. W > and please > watch this space for a corrected review. > > Regards > Brian > > On 06/06/2014 13:37, Warren Kumari wrote: > > I replied 6 days ago, Olafur followed up 3 days ago. > > > > Maybe you have us kill-filled? :-) > > > > W > > > > On Thursday, June 5, 2014, Warren Kumari <[email protected] > <javascript:;>> wrote: > > > >> Brian, can you please re-check? > >> > >> Olafur and I both replied -- I've just gotten off a plane and so cannot > >> easily resend, will do tomorrow if you didn't get our mails... > >> > >> W > >> > >> On Thursday, June 5, 2014, Brian E Carpenter < > [email protected] <javascript:;> > >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> > >>> I am the assigned Gen-ART reviewer for this draft. For background on > >>> Gen-ART, please see the FAQ at > >>> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >>> > >>> Please wait for direction from your document shepherd > >>> or AD before posting a new version of the draft. > >>> > >>> Document: draft-ietf-dnsop-delegation-trust-maintainance-13.txt > >>> Reviewer: Brian Carpenter > >>> Review Date: 2014-06-06 > >>> IETF LC End Date: 2014-05-26 > >>> IESG Telechat date: 2014-06-12 > >>> > >>> Summary: Almost ready > >>> -------- > >>> > >>> Comment: > >>> -------- > >>> > >>> These are my Last Call comments. I have seen no response. > >>> > >>> Minor issues: > >>> ------------- > >>> > >>>> 1. Introduction > >>> ... > >>>> Any manual process is susceptible to mistakes and / or errors. > >>> Also susceptible to social engineering or malicious leaks, I think. > >>> There's a fairly strong security argument for getting humans out > >>> of the process. > >>> > >>>> 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions > >>> ... > >>>> it is up to the consumer of the records to > >>>> translate that into the appropriate add/delete operations in the > >>>> provisioning systems > >>> Not clear here whether this is expected to be an automated or manual > >>> process. > >>> > >>>> If no CDS / CDNSKEY RRset is present in child, > >>>> this means that no change is needed. > >>> Not clear here how we ensure that update is performed exactly once. See > >>> below. > >>> > >>>> 4. Automating DS Maintenance With CDS / CDNSKEY records > >>>> > >>>> CDS / CDNSKEY resource records are intended to be "consumed" by > >>>> delegation trust maintainers. The use of CDS / CDNSKEY is optional. > >>> I think that could be OPTIONAL. > >>> > >>>> The child SHOULD publish both CDS and CDNSKEY resource records. > >>> Given the previous sentence, I think this needs to be > >>> > >>> If the child publishes either the CDS or the CDNSKEY resource record, > it > >>> SHOULD publish both. > >>> > >>>> 4.1. CDS / CDNSKEY Processing Rules > >>> ... > >>>> If there are no CDS / CDNSKEY RRset in the child, this signals that > >>>> no change should be made to the current DS set. This means that, > >>>> once the child and parent are in sync, the Child DNS Operator MAY > >>>> remove all CDS and CDNSKEY resource records from the zone. > >>> Does that mean the the child MAY/SHOULD/MUST monitor what the > >>> parent is publishing in order to automate this process? If not, you > >>> are calling for a manual operation. (The text in section 5 > >>> is repetitious, by the way, but still doesn't clarify this.) > >>> > >>>> If any these conditions fail the CDS / CDNSKEY resource record MUST > >>>> be ignored. > >>> Silently? Should this be logged? Any DOS potential here? Should use of > >>> these RRs be rate-limited in both child and parent to avoid any DOS > risk? > >>> > >>>> 6. Parent Side CDS / CDNSKEY Consumption > >>> I don't think you specify what the parent should do if it receives > >>> both a CDS and a CDNSKEY and they are inconsistent (in violation > >>> of section 4). Yes, it's a corner case but Murphy's law always applies. > >>> > >>>> 9. Security Considerations > >>> ... > >>>> While it may be tempting, this SHOULD NOT be used for initial > >>>> enrollment of keys since there is no way to ensure that the initial > >>>> key is the correct one. If is used, strict rules for inclusion of > >>>> keys such as hold down times, challenge data inclusion or similar, > >>>> ought to be used, along with some kind of challenge mechanism. > >>> Sh
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
