Subject: Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt

From: "James Galvin" <[email-masked]>
Date: Fri, 15 Dec 2017 09:20:17 -0500

Matt - do you have an update of the document or to your comments below?

Working group - are there any other comments or review of this document. 
  We need additional review before we can go to working group last call.

Thanks!

Jim

On 14 Sep 2017, at 13:36, Matthew Pounsett wrote:

> On 16 June 2017 at 10:03, Antoin Verschuren <[email-masked]> wrote:
>
>> Dear authors,
>>
>> I could finally find some time to make a more thorough personal 
>> (chair-hat
>> off) preliminary review on this document.
>> Here are my comments:
>>
>
> Hi Antoin.  My apologies for taking so long to getting around to 
> replying.
> :)
>
> I think we've addressed most of your notes either in Jacques's reply 
> or in
> the latest update, but I wanted to discuss a couple of things 
> independently.
>
> " This document describes a simple protocol that allows a third party
>>    DNS operator to update DS records for a delegation, in a trusted
>>    manner, without involving the Registrant for each operation.  This
>>    same protocol can be used by Registrants.”
>>
>> This sounds dubious. Is the registrant involved or not?
>> I would say:
>>
>> " This document describes a simple protocol that allows any
>>    DNS-operator to update DS records for a delegation, in a trusted
>>    manner, without involving any intermediate administratieve 
>> entities
>> between the DNS-operator and the parent.”
>>
>
> I agree that the wording in the current draft is a bit awkward.  
> However,
> your suggestion isn't quite correct either, since we're expecting this
> draft to be implemented by registrars in a gTLD environment, and they 
> are
> not the parent.
>
> The intent of the current wording is to point out that this was 
> developed
> to allow third-party operators to update their customers' DNS without
> having to involve the customer, but then to also note that advanced
> registrants who want to automate their own DS updates can also use it 
> (it's
> not limited to third-party operators).
>
> What the API and processes described in the draft really allow is for 
> the
> registrant or their DNS operator to avoid the *authenticated* web UI 
> of
> their "Registration Entity", whether that be the registrar or the 
> registry,
> because nobody implements a way for a regsitrant to add credentials 
> for
> their DNS operator and we have no reason to expect anyone ever will.  
> Even
> if they did, there's still a scaling problem for the operator.
>
> I'm going to think about a better way to word this paragraph which 
> doesn't
> encourage the reader to think we're setting up something that is 
> entirely
> unauthenticated or unvalidated.   If you have any other suggestions 
> I'm
> glad to hear them.
>
>
>
>
>>
>>
>> 1. Introduction:
>>
>> "After a domain has been registered, one of three parties will
>>    maintain the DNS zone loaded on the "primary" DNS servers: the
>>    Registrant, the Registrar, or a third party DNS operator.”
>>
>> I object to this phrasing, as it suggest an entity performs it’s 
>> role as
>> DNS-operator as part of another role he might play. It’s always the
>> DNS-operator and only the DNS-operator that maintains the DNS zone.
>> An entity can act as both registrant AND DNS-operator, registrar AND
>> DNS-operator, or as a standalone DNS-operator, but an entity never
>> maintains a zone in any other role than as DNS-operator. They should 
>> be
>> clearly separated to keep roles and entities clearly defined.
>> This whole section need a thorough review on definitions of roles and
>> entities performing multiple roles.
>>
>> Does this work better?
>
> After a domain has been registered, the DNS operator for the child 
> zone on
> the "primary" DNS servers might be the registrant, the registrar, or a
> third party.
>
>
>
>> 3.2 Establishing a Chain of Trust:
>>
>> This is the section where I have most problems with.
>> The bootstrapping of a secure delegation can never be done over an
>> insecure channel such as DNS without a chain of trust for polling the
>> initial key.
>> Unfortunately, I have not followed the discussions for RFC8078, but 
>> when I
>> read that now, I think paragraph 3.3 and 3.5 from RFC8078 are a 
>> terrible
>> mistake security wise, and a downgrade from previous practice. I 
>> believe
>> that insertion of the first key at the parent should always have been 
>> over
>> a secure channel, or confirmed over a secure channel, and in the 
>> absence of
>> a chain of trust in DNS prior to a secure delegation, the only way to 
>> do
>> that is over the secure administrative channel such as EPP or another
>> proven secure channel which DNS without DNSSEC validation is not.
>> I challenge RFC8078 that it probably had too little review from 
>> security
>> folks, and I don’t want to make the same mistake here, which makes 
>> it even
>> less secure by saying "Once the Registrar sees these records it 
>> SHOULD
>> start acceptance processing.”
>> No way. It should never accept a security proof or security inception
>> process over an insecure channel.
>>
>> Also, the introduction of this document only states "Update DS 
>> records”
>> which I agree with, but Establishing a Chain of Trust is not updating 
>> but
>> bootstrapping.
>>
>
> I think we're going to have to continue to disagree, here.  Not only 
> has
> 8078 been published, but there are already registries implementing 
> security
> bootstrapping via CDS.  We've updated the text to be more explicit 
> about
> this, and I intend to strengthen the security considerations statement 
> more
> that this is a risk that a registration entity needs to carefully 
> consider
> before implementation.

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 20 Dec 2017 06:23:28 +0100

> Working group - are there any other comments or review of this document. 

I am working on a review for this document. I hope to be able to send it tomorrow.

-- 
  Patrick Mevzek
  [email-masked]