Re: Secdir last call review of draft-ietf-regext-epp-fees-16

[Yoav Nir <ynir.ietf@xxxxxxxxx>]

Hi, Roger

Looks good.  What I think should also be said, is that the financial information passed to any customer is only information about that customer’s own account.  We wouldn’t want customer information to leak to other customers.

Yoav

On 6 Sep 2019, at 17:48, Roger D Carney <rcarney@xxxxxxxxxxx> wrote:

Good Morning,

 

Thank you for your comments Yoav, please see my responses below. A new version of the draft will be published shortly and will address all of the review comments that needed edits.

 

 

Thanks

Roger

 

-----Original Message-----

From: Yoav Nir via Datatracker <noreply@xxxxxxxx> 

Sent: Saturday, June 29, 2019 10:26 AM

To: secdir@xxxxxxxx

Cc: ietf@xxxxxxxx; draft-ietf-regext-epp-fees.all@xxxxxxxx; regext@xxxxxxxx

Subject: Secdir last call review of draft-ietf-regext-epp-fees-16

 

Notice: This email is from an external sender.

 

 

 

Reviewer: Yoav Nir

Review result: Has Nits

 

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.

 

The entire text of the Security Considerations section is as follows:

 

   The mapping extensions described in this document do not provide any

   security services beyond those described by EPP [RFC5730], the EPP

   domain name mapping [RFC5731], and protocol layers used by EPP.  The

   security considerations described in these other specifications apply

   to this specification as well.

 

This is what we like to call "security considerations by reference". I don't know what "security services" are in this context, but they are not the only thing that needs to be described in a Security Considerations section.

 

In this case, the draft adds information about fees, customer credit and pay schedule. This falls under the category of financial information, which should be protected in transit by security mechanisms that protect confidentiality and integrity. It is also true that any transport mechanism that complies with RFC

5730 provides those functions. So what I'm missing here is a sentence that calls this out specifically. Something along the lines of "This extension adds financial information to the EPP protocol, so confidentiality and integrity protection must be provided by the transport mechanism.  All transports compliant with RFC5730 provide that"

 

[RDC] We have added the following text to section 7: "This extension passes financial information using the EPP protocol, so confidentiality and integrity protection must be provided by the transport mechanism.  All transports compliant with RFC5730 provide the needed level of confidentiality and integrity protections."