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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/ ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- 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)? 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? 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? 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. 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. 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? 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?) 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. 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. 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. 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. 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? 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? 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)? <!-- 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? I see the rrType defined but not used anywhere; is it still needed in this 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.) 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? 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"? 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.) Is it appropriate to use the urn:ietf:params:xml:ns:rdeObj[N] namespaces in the examples, vs. a dedicated "example" namespace? _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
