Subject: [eppext] ID Tracker State Update Notice: <draft-ietf-eppext-reg-08.txt>

From: IETF Secretariat <[email-masked]>
Date: Thu, 02 Oct 2014 10:45:06 -0700

IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 2 Oct 2014 18:16:49 +0000

Thanks for moving the document along, Pete. I'll dig through the comments and see about an approach for each one.

What, if anything, do you suggest for the comments about the security considerations section? I've got the comment about including the considerations from 3735, but what about this comments from Joel Jaeggli and Ted Lemon? Joel's:

"the security considerations section doesn't have anything to do with the
protocol or the registry, nor is it instruction to iana, if it was it
would be in the iana considerations section."

Ted's:

" This seems wrong:

   Using email to deliver forms to IANA carries a risk of registry
   entries being created or updated by an attacker who is able to spoof
   the email address of a legitimate extension registrant.  This risk
   can be mitigated by replying to received messages with a request to
   confirm the requested action.  The reply will be delivered to the
   specified registrant, who can validate or refute the request.

If you have a man-in-the-middle, they can presumably modify messages in
both directions.   But as Kathleen said, the normal process of review
should catch problems of this sort. If that fails, and an erroneous
registration occurs, the registrant will see the incorrect IANA registry
entry.   So this will serve as an out-of-band mechanism for detecting
attacks of this type, since the MITM presumably won't be able to spoof
the SSL cert from the IANA web site."

...or Stephen Farrel's discuss:

"I believe that there are some uses of EPP that have been
mooted or even put in place that are considerd by quite a few
folks as being quite privacy unfriendly.  If so (and please
correct me if I'm wrong) that indicates that the DEs need to
explicitly include consideration of the privacy consequences
of proposed extensions and that DEs ought at minimum require
that any privacy considerations are fully documented in the
relevant specification(s). If it were up to me, I'd probably
go further on that and ask that the DEs try to ensure that
the world is more privacy friendly, but I suspect that'd be
beyond IETF consensus."

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 3 Oct 2014 12:17:31 +0000

I just finished an update that addresses (I think) all of the last call and IESG review comments. I added Stephen Farrel's text to the DE evaluation criteria section to make it clear that privacy considerations should be included in the evaluation. I modified the Security Considerations section as follows:

"4.  Security Considerations

   This document introduces no new security considerations to EPP.
   However, extensions should be evaluated according to the Security
   Considerations of RFC 3735 [RFC3735]."

I'm going to publish the update in a minute so you can see the rest of the changes using a diff.

Scott

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Thursday, October 02, 2014 2:17 PM
> To: Pete Resnick
> Cc: [email-masked]; [email-masked]
> Subject: Re: [eppext] ID Tracker State Update Notice: <draft-ietf-
> eppext-reg-08.txt>
> 
> Thanks for moving the document along, Pete. I'll dig through the
> comments and see about an approach for each one.
> 
> What, if anything, do you suggest for the comments about the security
> considerations section? I've got the comment about including the
> considerations from 3735, but what about this comments from Joel
> Jaeggli and Ted Lemon? Joel's:
> 
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext