Last Call Review of draft-ietf-eppext-reg-08
review-ietf-eppext-reg-08-secdir-lc-nir-2014-09-25-00

Hi

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

TL;DR: The document is ready.

The document specifies no new protocol. EPP is already specified in RFC 5730,
and extending EPP is already specified in RFC 3735. This document only
specifies the IANA registry for such extensions. Most of the document is about
criteria for considerations by the designated expert, and there's a 3-page IANA
considerations section (includes lots of examples).

Some elements that seemed strange to me. I’m not trying to second-guess the
working group that produced this, as I’ve never participated in it, but I am
pointing these things out:

The registry policy is "specification required", which seems OK, and the
document points out correctly that this policy implies expert review. I’m used
to multiple registries with a single expert (such as in IPsec), so I was
surprised to see the requirements in section 2.1.1:

   The IESG should appoint a small pool of individuals (perhaps 3 - 5)

   to serve as designated experts as described in Section 3.2 of RFC

   5226.  The pool should have a single administrative chair who is

   appointed by the IESG.  The designated experts should use the

   existing eppext mailing list (

eppext at ietf.org

) for public discussion

   of registration requests.  This implies that the mailing list should

   remain open after the work of the EPPEXT working group has concluded.

I guess the number of experts relates to the amount of work to be done, so it
depends on the per-document requirements in RFC 3735 and on the amount of
documents that arrive in a unit of time.

NIT: Section 2.1 says, "An English language version of the extension
specification will appear in the registry”. The intent, I guess, is that the
English-language version is referenced from the registry.

Section 2.2.1 specifies the format for the registration form, which includes an
email address, I’m guessing that it’s used as a contact address. For
standards-track documents the email address should be

iesg at ietf.org

. I don’t know if that’s a good idea. Probably best to leave either the
editor’s address or the eppext working group.

Section 2.2.3 has some requirements for IANA, so it should be reviewed by IANA.
I think it needs a pointer from the IANA considerations section, which is what
they review.

The document just sets up an IANA registry. As such, security considerations
should probably be no different than any other interaction with IANA. The
security considerations describes a possible spoofing attack on the submission
process, which is done via email. This seems very unspecific to this document.
What's more, I'm not sure I understand why this document requires that
submissions be done through email. If IANA decides that they're opening a
facebook page, and registration requests should from here on be posted to their
"wall", do we need to rev this document?

This document makes no reference to the security of the extensions themselves.
Extensions that break the security assumptions of base protocols are a real
issue. This is covered to some extent in RFC 3735, but I would have liked the
document to specifically mention that this is part of the job of the expert
reviewer. Specifically, where section 2.1.1 says:

OLD:



   Extensions should be evaluated for architectural soundness using the

   guidelines described in RFC 3735 [RFC3735].



I think it would be better to add at the end there ", including the Security
Considerations section of that document.”

NEW:



Extensions should be evaluated for architectural soundness using the

   guidelines described in RFC 3735 [RFC3735], including the Security

   Considerations section of that document.

Yoav