>-----Original Message----- >From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Hugo Salgado- >Hernández >Sent: May-19-16 2:59 PM >To: Olafur Gudmundsson >Cc: regext@ietf.org >Subject: Re: [regext] I-D Action: >draft-ietf-regext-dnsoperator-to-rrr-protocol- >00.txt > >Hi Olafur. Some comments below. > >In "4.4.1. Initial Trust Establishment (Enable DNSSEC validation)" >I'm concerned on having an "out-of-band" validation of the right DS/DNSKEY >value. Using only the CDS record through DNS is weaker than current method, >when there's an EPP from the registrar or a registrant confirmation through its >domain control panel of the right key. I think it could be solved using this >initial POST including in the restful API call the CDS/DS/DNSKEY or CDNSKEY >value as a request parameter, which can be matched with DNS. >
We are working under the concept that the CDS records present in the zone file are indications of intention to sign/unsign/update the DS records of the domain in the parent zone and not based on who issues the request to perform the action. The CDS is public, already available at the child, any actor could get the CDS and supply with the POST request. >In "4.5.1. Setup Initial Establishment with Challenge", I'm wondering if the >right >method should be GET instead of POST. I'm not a REST expert, but I'd expect a >read-only operation to be GET. Although its true that some registrar could >associate the token in the moment of the call, also the registrar could have >pre-generated tokens already associated with domains. So this call is a GET of >that value. POST to create a new entry (new challenge), I think it's the right action. >Also, I think it could have an "expiration datetime" in the response, after >which >the DNS operator should ask again for a new value. > Good point, this could be based on the parent policy, the presence or not of an expiration datetime. >Regards, > >Hugo > > >On 11:02 26/04, Olafur Gudmundsson wrote: >> >> This version is identical to version that was used for the call for >> adoption the track was changed to Standards track. >> >> A version 01 is in the works and will be published soon. >> >> Olafur (for editors) >> >> > On Apr 26, 2016, at 11:01 AM, internet-dra...@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> > This draft is a work item of the Registration Protocols Extensions of the >IETF. >> > >> > Title : Third Party DNS operator to Registrars/Registries >> > Protocol >> > Authors : Jacques Latour >> > Olafur Gudmundsson >> > Paul Wouters >> > Matthew Pounsett >> > Filename : draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt >> > Pages : 10 >> > Date : 2016-04-26 >> > >> > Abstract: >> > There are several problems that arise in the standard >> > Registrant/Registrar/Registry model when the operator of a zone is >> > neither the Registrant nor the Registrar for the delegation. >> > Historically the issues have been minor, and limited to difficulty >> > guiding the Registrant through the initial changes to the NS records >> > for the delegation. As this is usually a one time activity when the >> > operator first takes charge of the zone it has not been treated as a >> > serious issue. >> > >> > When the domain on the other hand uses DNSSEC it necessary for the >> > Registrant in this situation to make regular (sometimes annual) >> > changes to the delegation in order to track KSK rollover, by updating >> > the delegation's DS record(s). Under the current model this is prone >> > to Registrant error and significant delays. Even when the Registrant >> > has outsourced the operation of DNS to a third party the registrant >> > still has to be in the loop to update the DS record. >> > >> > There is a need for a simple protocol that allows a third party DNS >> > operator to update DS and NS records in a trusted manner for a >> > delegation without involving the registrant for each operation. >> > >> > The protocol described in this draft is REST based, and when used >> > through an authenticated channel can be used to establish the DNSSEC >> > Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC >> > trust is established this channel can be used to trigger maintenance >> > of delegation records such as DS, NS, and glue records. The protocol >> > is kept as simple as possible. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rr >> > r-protocol/ >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-pro >> > tocol-00 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at >tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > regext mailing list >> > regext@ietf.org >> > https://www.ietf.org/mailman/listinfo/regext >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext >> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
