Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 09:01:12 -0700

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?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2020 09:34:38 -0400

> in the examples, vs. a dedicated "example" namespace?

You're probably right: there is an "example" namespace, and when a URN
is used purely as an example it should use that namespace.

Barry

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 16 Apr 2020 22:26:40 +0000

Thank you, Benjamin,

Comments inline, prefixed with GL -.

Regards,
Gustavo

On 4/8/20, 09:01, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:

    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= 

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.

If the IESG does not object to this idea, probably the current security section in the draft could work with a few tweaks.

    Section 1

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.

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?

    Section 2

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.

    Section 3

    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.

GL - Not that I am aware of.

GL - Both. For example, in draft-ietf-regext-dnrd-objects-mapping, there is an object to specify aspects of policy for machine consumption.

    Section 4

GL - Agree, changed the title to "Conventions Used in This Document" in the new version of the draft.

    Section 5

    nit: comma splice.

GL - Fixed in new version of the draft.

GL - The sentence on section 5 is about not prescribing the transport mechanism.

    Section 5.1.1

GL - Correct, changed to date-time in the new version of the draft.

    Section 5.1.2

GL - Correct. You may want to take a look at the examples in draft-ietf-regext-dnrd-objects-mapping for further clarity.

    Section 5.1.4

    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

GL - Inherited from EPP.

GL - Correct.

GL- The element is used in https://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping. The element is in the schema for backward compatibility. There is a comment in the schema explaining that these are auxiliary elements.

    Section 10

GL - I will change the authentication SHOULDs to MUSTs in the new version of the draft.

GL - Sounds good, I will change this to a MUST.

    Section 11

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.

    Section 14, 15, 16

GL - Agree, I will change this.

GL - Agree, I will change this to the example URN namespace.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2020 18:04:50 -0700

Hi Gustavo,

>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddata-2Descrow_&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl…

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).

I agree, thanks.

> 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.)

> 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 Increm…

That should work, yes.

> 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 :)

> 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.

> 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?

>     as a maximum, especially if a registrar wants to use a domain name as an

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.

> GL- The element is used in https://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping. The element is in the schema for backward compatibility. There is a comment in the schema explaining t…

What prevents moving the definition to that other document?

> 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…

Yes, thanks!

> 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