Hi Gustavo, I think that proposed text will work; please go ahead and include it in the next vesrion of the draft.
Sorry for the slow response, Ben On Fri, May 22, 2020 at 07:26:03PM +0000, Gustavo Lozano wrote: > Thank you, Ben, > > I think that the last sentence in the following proposed text for the second > paragraph of the security section could attend your second discuss point: > > Depending on local policies, some elements, or, most likely, the whole > deposit will be considered confidential. As such, the parties SHOULD take all > the necessary precautions such as encrypting the data at rest and in transit > to avoid inadvertent disclosure of private data. Regardless of the > precautions taken by the parties regarding data at rest and in transit, > authentication credentials MUST NOT be escrowed. > > If you agree that this covers your feedback, I will include it in the next > version of the draft. > > Regards, > Gustavo > > On 5/21/20, 15:07, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddata-2Descrow-2D08.txt&d=DwIDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=VDCiJAnAswUQ4avJ55sPxmYR4hLKtN9JoiudmZhps0M&s=ilArbwqLMrfNyTwmcvU6fk9KseAXlQKxRccN-kUQhOo&e= > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddata-2Descrow-2D09.txt&d=DwIDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=VDCiJAnAswUQ4avJ55sPxmYR4hLKtN9JoiudmZhps0M&s=iNhLzs77vPa3t0ibX42lkY967mU9pwYMkPEIU1slI1U&e= > > > > > 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
