Hi Gustavo, Thanks for the updates! I think the mention of the ICANN base agreement in the introduction serves to give some examples of well-reviewed procedures for escrow, and is enough to resolve my first discuss point.
I don't see a whole lot that looks relevant to my second point about (potential) escrow of authentication credentials, though. If I remember correctly we discussed that the intent was for those to not be included in the escrow dumps, but I don't remember whether we talked about putting any clarifying text in the document. Thanks, Ben On Wed, May 13, 2020 at 06:45:38PM +0000, Gustavo Lozano wrote: > Hi Benjamin, > > I think that the latest version of the draft covers your feedback. > > Here are the differences between 07 and 08, and 08 and 09: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-08.txt > https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-09.txt > > Thoughts? > > Thank you, > Gustavo > > On 4/20/20, 18:05, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > Hi Gustavo, > > On Thu, Apr 16, 2020 at 10:26:40PM +0000, Gustavo Lozano wrote: > > Thank you, Benjamin, > > > > Comments inline, prefixed with GL -. > > > > Regards, > > Gustavo > > > > On 4/8/20, 09:01, "Benjamin Kaduk via Datatracker" <nore...@ietf.org> > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-regext-data-escrow-07: Discuss > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > > > Please refer to > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=XLPt-K5FLKU1oce9PiZyutUV1_UJqbd348-sDIlLCD8&s=9EVCPSTvj9RgWF9Z3e7HBLsbaPg6R2CPwDhbFPM8sEM&e= > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddata-2Descrow_&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=XLPt-K5FLKU1oce9PiZyutUV1_UJqbd348-sDIlLCD8&s=Avsh9DG_m3aLijuq_I7ulh5IMkYG78XIOq1Puctc2ZU&e= > > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > Let's have a discussion about the overall plans for providing > guidance > > on mechanisms for (e.g.) cryptographic confidentiality and integrity > > protection of data both in transit and at-rest, > > authentication/authorization requirements, etc.. In particular, > what > > it's appropriate and necessary to include in this document vs. other > > documents, and how to provide some specific general baseline > guidance > > that can be used in the absence of conflictinc scenario-specific > > deployment requirements. Some further details in the COMMENT > section, > > but in general, it seems like there should be some "off-the-shelf" > > mechanism that can be used without a need for every deployment to > do a > > custom thing, for cases where there are not custom requirements. > It may > > not need to be part of this document, but we should have a plan for > > where it will be. > > > > Also, it's not clear to me whether we expect escrow of > > credentials/verifiers used to authenticate/authorize fourth parties > that > > perform operations (e.g., registrations) at the registry (see > comment on > > Section 3), and that is pretty important for knowing what security > > requirements to place on the escrow'd data. > > > > > > GL - > > > > I interpret your message: > > > > A new draft could provide the guidelines to implement an escrow > service that requires strong security controls. > > > > In the gTLD space, the legal agreements and processes (e.g. > accreditation, etc.) that govern escrow services make the need for this new > draft low priority. However, other parties (e.g., ccTLDs) interested in > implementing an escrow service could benefit from such a document. > > Maybe we could keep a reference to (e.g.) "Specification 2" of the ICANN > base registry agreement outside of the Implementation Status section (that > will be removed upon pulbication), to give readers a sense for what kind > of > prior art there is. > > > If the IESG does not object to this idea, probably the current security > section in the draft could work with a few tweaks. > > I do not see a reason why someone would object. (I assume that the > "tweaks" would include things like specifying to use TLS 1.3 or something > specific in order to meet the various checking requirements.) > > > That said, my main question in the first paragraph here was to get a sense > for what has already been done and what plans there are for future work. > Given the existence of ICANN's document and a potential plan to write our > own generic document, I don't feel a strong need to put specific > protocol/mechanism guidance in this document, provided that we can refer > to > one or both of the aforementioned items (whether as "WIP" or otherwise). > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I agree with Roman that the link to the charter is tenuous; perhaps > this > > is a "data format for files exchanged between registration entities > that > > needs extraction from EPP or RDAP", but it's not a perfect fit. > > > > Section 1 > > > > The goal of data escrow is higher resiliency of registration > > services, for the benefit of Internet users. The beneficiaries > of a > > registry are not just those registering information there, but > all > > relying parties that need to identify the owners of objects. > > > > Only relying parties that need to identify *owners* specifically (as > > opposed to consuming other registered data)? > > > > GL - I think the following text addresses your comment, do you agree? > > > > The goal of data escrow is higher resiliency of registration services, > for the benefit of Internet users. The beneficiaries of a registry are not > just those registering information there, but also the users of services > relying on the registry data. > > I agree, thanks. > > > In the context of domain name registries, registration data > escrow is > > a requirement for generic top-level domains and some country code > > top-level domain managers are also currently escrowing data. > There > > is also a similar requirement for ICANN-accredited domain > registrars. > > > > Are there easy references for these requirements being requirements? > > > > GL - I understand your comment: adding the documents where the > requirements for escrow are defined for gTLDs as informative references in > the draft. Am I correct? > > Yes. (I guess I should have read this part before I wrote above about the > ICANN stuff.) > > > Section 2 > > > > Watermark. If the Timeline Watermark of an Incremental Deposit > were > > to cover the Timeline Watermark of another (Incremental or > > Differential) Deposit since the last Full Deposit, the more > recent > > deposit MUST contain all the transactions of the earlier deposit. > > > > Do we define what it means for one Timeline Watermark to "cover" > another? > > > > GL - I think the following text addresses your comment, do you agree? > > > > If the Timeline Watermark of an Incremental Deposit were to cover > (i.e., one or more Incremental or Differential deposits exist for the period > between the Timeline Watermark of a Full and an Incremental or Differential > Deposit) the Timeline Watermark of another Incremental or Differential > Deposit since the last Full Deposit, the more recent deposit MUST contain all > the transactions of the earlier deposit. > > That should work, yes. > > > Section 3 > > > > Specifications covering the objects used by registration > > organizations shall identify the format and contents of the > deposits > > a registry has to make, such that a different registry would be > able > > to rebuild the registration services of the former, without its > help, > > in a timely manner, with minimum disruption to its users. > > > > Rebuilding registration *services* as opposed to just *operation* > sounds > > like it will require also escrowing credentials/credential verifiers > > used to authenticate to the registration organization in order to > make > > use of such services. > > > > GL - Not necessarily. For example, in the case of a domain Registry, a > domain Registrar could re-set the credential verifier. > > > > Such credentials would of course need very > > careful protection both in transit and at rest, in order to avoid > > compromising the integrity of the primary operations of the current > > registration organization. > > > > GL - Correct, escrowing of credentials/credential verifiers require > strong security controls. See my suggestion at the DISCUSS section of this > email. > > Okay, it seems like we are in agreement :) > > > Given the requirement for confidentiality and the importance of > > accuracy of the information that is handled in order to offer > > registration services, parties using this specification shall > define > > confidentiality and integrity mechanisms for handling the > > registration data. > > > > Do we have any recommendations/examples of such mechanisms in the > > pipeline? > > > > GL - Not that I am aware of. > > > > Specifications covering the objects used by registration > > organizations shall not include in the specification transient > > objects that can be recreated by the new registry, particularly > those > > of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. > > > > I'm not sure this is going to be terribly helpful guidance for > > non-domain-name data. I am acutely aware that cryptographic > (symmetric > > and/or private) keys are not the only type of data that this could > apply > > to, but it is the only type that I know of a concise/precise > description > > for. E.g., "cryptographic key material that is vital to the > integerity > > and/or security of operation of the registry and the systems that > rely > > on it but that is not vital to the continuity of operations (e.g., > > DNSSEC KSK/ZSK private keys)". > > > > Also, I would assume that the authenticatoin credentials I mention > above > > would not qualify for this requirement, since they are not things > that > > can be recreated by the new registry. > > > > Details that are a matter of policy should be identified as such > for > > the benefit of the implementers. > > > > (For human consumption or machine consumption?) > > > > GL - Both. For example, in draft-ietf-regext-dnrd-objects-mapping, > there is an object to specify aspects of policy for machine consumption. > > Ah, thanks for the pointer. > > > Section 4 > > > > Could we maybe use the section title "Conventions Used in This > > Document"? "General Conventions" could be interpreted as intended > for a > > broader scope, though based on (e.g.) RFC 8748 I don't think that's > the > > intent. > > > > GL - Agree, changed the title to "Conventions Used in This Document" in > the new version of the draft. > > > > Section 5 > > > > registry. The deposits are represented in XML. Only the format > of > > the objects deposited is defined, nothing is prescribed about the > > method used to transfer such deposits between the registry and > the > > escrow agent or vice versa. > > > > nit: comma splice. > > > > GL - Fixed in new version of the draft. > > > > Also, we said earlier that "parties using this specification shall > > define confidentiality and integrity mechanisms for handling the > > registration data" without, AFAICT, conditions on when that should > be > > done. So in some sense we do prescribe properties of the method > used > > for transfer, if I'm reading that correctly. > > > > GL - The sentence on section 5 is about not prescribing the transport > mechanism. > > > > Section 5.1.1 > > > > A REQUIRED <watermark> element contains the data-time > corresponding > > to the Timeline Watermark of the deposit. > > > > I will offer a third opinion, that this was meant to be dateTime. > > > > GL - Correct, changed to date-time in the new version of the draft. > > > > Section 5.1.2 > > > > I'm confused about the relationship between the <objURI> elements > in the > > <rdeMenu> and the objects in the <deletes> and <contents> elements > -- is > > <rdeMenu> just a list of "here are all objects that this update > > touchers", with the details in the other sections? > > > > GL - Correct. You may want to take a look at the examples in > draft-ietf-regext-dnrd-objects-mapping for further clarity. > > Ah, that does look helpful, thanks. Is there a way we could reference > that > document from this one as an example application? > > > Section 5.1.4 > > > > If an object is present in the <contents> section of several > deposits > > (e.g. Full and Differential) the registry data from the latest > > deposit (as defined by the Timeline Watermark) SHOULD be used > when > > rebuilding the registry. > > > > Why is this not a MUST? > > > > GL - To cover the case when the more recent differential deposit is > deemed to be invalid, and a previous differential deposit needs to be used > for rebuilding a registry. > > > > Section 6.1 > > > > Why is there a 13-character maximum for the deposit ID? > > But client IDs range from 3 to 16 characters (which seems kind of > short > > as a maximum, especially if a registrar wants to use a domain name > as an > > identifier)? > > > > GL - Inherited from EPP. > > I don't have a great sense for how strongly the EPP heritage justifies > keeping the (artificial) limit, i.e., whether any non-domain-name usage of > this mechanism would benefit much from longer identifiers. > > > <!-- A RDE version number is a dotted pair of decimal numbers > --> > > <simpleType name="versionType"> > > <restriction base="token"> > > <pattern value="[1-9]+\.[0-9]+"/> > > <enumeration value="1.0"/> > > </restriction> > > </simpleType> > > > > I assume the <pattern> is there to give the overall structure that > > subsequently defined <enumeration>s will adhere to? > > > > GL - Correct. > > > > I see the rrType defined but not used anywhere; is it still needed > in > > this document? > > > > GL- The element is used in > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dregext-2Ddnrd-2Dobjects-2Dmapping&d=DwIDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=8HUUPMzc75s9UE1V5gfdMVutMywATqGNU1WgLrT_Zqo&s=iYw77kgL26humLs0O00-I6G-NTOlGIOk2iBivV7qWoI&e= > . The element is in the schema for backward compatibility. There is a > comment in the schema explaining that these are auxiliary elements. > > What prevents moving the definition to that other document? > > > Section 10 > > > > Authentication of the parties passing data escrow deposit files > is > > also of the utmost importance. The escrow agent SHOULD properly > > authenticate the identity of the registry before accepting data > > escrow deposits. In a similar manner, the registry SHOULD > > authenticate the identity of the escrow agent before submitting > any > > data. > > > > I am failing to come up with a scenario in which these SHOULDs > would be > > violated; should they be MUSTs instead? (I'd like for the > "encrypting > > the data" in the previous paragraph to be a MUST as well, but that > case > > is less clear-cut.) > > > > GL - I will change the authentication SHOULDs to MUSTs in the new > version of the draft. > > > > Additionally, the registry and the escrow agent SHOULD use > integrity > > checking mechanisms to ensure the data transmitted is what the > source > > intended. Validation of the contents by the escrow agent is > > > > It seems like if there are no integrity checks then the escrow > mechanism > > is not really fit for purpose -- can't this be MUST? > > > > GL - Sounds good, I will change this to a MUST. > > > > Section 11 > > > > This specification defines a format that may be used to escrow > > personal data. The process of data escrow is governed by a legal > > document agreed by the parties, and such legal document must > regulate > > the particularities regarding the protection of personal data. > > > > "Regulate the particularities" is an interesting phrase, as it > merely > > specifies that some restrictions be made, but nothing about the > nature > > of them. Shouldn't we be saying something like "ensure that > > privacy-sensitive and/or personal data receives appropriate > protection"? > > > > GL - I think the following text addresses your comment, do you agree? > > > > This specification defines a format that may be used to escrow personal > data. The process of data escrow is governed by a legal document agreed by > the parties, and such legal document must ensure that privacy-sensitive > and/or personal data receives the required protection. > > Yes, thanks! > > > Section 14, 15, 16 > > > > Could we not reuse the same deposit-id for different examples? > > (Also, using 20191017001 with a watermark date of 2019-10-18 > > midnight-UTC is perhaps unnecessary cognitive dissonance.) > > > > GL - Agree, I will change this. > > > > Is it appropriate to use the urn:ietf:params:xml:ns:rdeObj[N] > namespaces > > in the examples, vs. a dedicated "example" namespace? > > > > GL - Agree, I will change this to the example URN namespace. > > Thanks for this and all the other clarifications and updates that I didn't > specifically respond to! > > -Ben > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
