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
