Excellent; I've updated my ballot position. (It looks like we are still waiting for Alissa to look at the updates, though.)
-Ben On Mon, Jun 01, 2020 at 06:51:21PM +0000, Gustavo Lozano wrote: > Thank you, Ben, > > Text added in the latest version of the draft: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-10.txt > > Regards, > Gustavo > > On 5/30/20, 11:39, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > 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
