- gtld-tech - lists.icann.org

URS and replay attacks
by Rubens Kuhl Sept. 1, 2015

Sept. 1, 2015

@ll, I'm wondering what we have, if any, in resources to prevent URS replay attacks. The threat scenario we've made include access to the "Sent Items" folder of an URS Provider, without access to PGP information. With such access, domains that already received URS-Lock and URS-Suspend commands might be subject to lock or suspension again, even if there is not, at that time, an URS procedure ongoing. That could even happen with a new registrant of that domain. I couldn't find anything in the requirements or URS Provider RFIs that would generate information capable of mitigating this threat... am I missing something ? Rubens

2 2

Verification of the ROID in PDT and upcoming Advisory
by Francisco Arias Aug. 27, 2015

Aug. 27, 2015

Dear Colleagues, As a follow up to the draft updated PDT specifications (http://newgtlds.icann.org/en/announcements-and-media/announcement-2-22jul1 5-en) and the gTLD Registries Operational Workshop held in Buenos Aires, I would like to let you know that ICANN is planning to release a verification of the ROID format as part of Pre-Delegation Testing (PDT). The ROID check would be done as part of both the EPP and Whois tests cases. The verification would check two things: 1) that the ROID is properly formatted as described in RFC 5730, per Specification 6 of the registry agreement; and 2) that the repository identifier used is already registered with IANA (https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xht ml). This update will be implemented at the same time as the updates regarding the RDDS (Whois) Advisory. We will implement warnings (no failures) in case of deviations starting on 2 November 2015, and strict enforcement will start on 31 January 2016. Finally, ICANN is planning to release in the next few weeks an advisory at https://www.icann.org/resources/pages/advisories-2012-02-25-en describing the considerations that registries should have when migrating ROIDs. I have attached a draft of the advisory and would appreciate any input you may have by 17 August. Please let me know if you have any questions or comments. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

2 5

Call for Presentations for TechDay at ICANN Dublin
by Dr Eberhard Lisse Aug. 20, 2015

Aug. 20, 2015

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Dublin. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Re: [gtld-tech] Draft updated PDT specs and request for feedback
by Kal Feher Aug. 5, 2015

Aug. 5, 2015

My comments on the draft test documents. PDT_TP_Whois: 1. The following line appears to have no matching explicit requirement from the RA or the Whois clarification, it should be removed. In particular the portion relating to the ability to copy and paste the output: “When rendered using a modern web browser the Web whois port 80/443 output MUST contain a section corresponding to the Whois port 43 output that can be copied as a single unit and pasted into a text file.” 2. The AWIP footer should be optional for all reply types. Neither the AWIP policy, nor the Whois clarifications require that the AWIP footer appear under a specific reply type. It is acceptable to include it in all reply types. The text in section 5.5 of the PDT Whois_TP (Appendix) should be updated to reflect the two policy statements by including ‘AWIP footer’ as an optional section above the legal disclaimer for each reply type. 3. The AWIP section description in 5.6.8 PDT_Whois_TP (Appendix) should include both acceptable URLs found in https://www.icann.org/resources/pages/policy-awip-2014-07-02-en. The Whois clarification Advisory references the AWIP announcement and the URL contained therein and does not explicitly override using either EPP status link. PDT_Whois_TC_CLI: WhoisCLI01 - There is no Char Encoding declaration section in the current pdtwhois.xml file or matched schema files. I’m assuming this variable doesn’t refer to the xml header. Should a new input file and schema have been provided with the drafts test cases? If so, please send that to the list for review as well. PDT_Whois_TC_Web: WhoisWeb01 – There is no explicit or implied requirement for HTTPS for web based whois in the Registry Agreement or the clarifications announcement. The lack of HTTPS should not be cause for a warning. The previous PDT_Whois_TC_Web document (E) had HTTPS as optional and I’m not aware of any recent approved policy which overrides this. Perhaps the pdtwhois.xml file should include an element stating whether HTTPS is supported or not. If it is, then the criteria for PASS, WARN and FAIL can remain unchanged. If HTTPS is explicitly not supported, then HTTPS testing should be limited to confirming that it is in fact not available. -- Kal Feher -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: Friday, 24 July 2015 7:24 PM To: gtld-tech(a)icann.org Cc: Russ Weinstein Subject: [gtld-tech] Draft updated PDT specs and request for feedback This message contains a digitally signed email which can be read by opening the attachment.

3 5

Re: [gtld-tech] ICANN CRL expired and not updated yet
by Kal Feher July 30, 2015

July 30, 2015

Francisco, Can you please provide the length of the outage period and the symptoms observed by users as currently understood? Clearly stating the known facts would be useful for all those who rely on the service and who need to now identify invalid submission failures. -- Kal Feher -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: Tuesday, 28 July 2015 11:39 AM To: David Krizanic; gtld-tech(a)icann.org Subject: Re: [gtld-tech] ICANN CRL expired and not updated yet This message contains a digitally signed email which can be read by opening the attachment.

3 3

ICANN CRL expired and not updated yet
by David Krizanic July 28, 2015

July 28, 2015

All, We've had registrars come to us with complaints of inability to submit sunrise applications and it turns out that the ICANN CRL (http://crl.icann.org/tmch.crl) has expired, since there's been a number of seemingly unrelated issues over the past months our sunrises have been suffering. We are now waiting for an update while validating any SMD is failing. Best, David DAVID KRIZANIC Famous Four Media - Head of Technology 2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar Phone: +350 216 50006 Email: dkrizanic(a)famousfourmedia.com

3 4

Re: [gtld-tech] ICANN CRL expired and not updated yet
by Francisco Arias July 27, 2015

July 27, 2015

Hi David, We are looking into this and should have an update shortly. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN On 7/27/15, 8:29 AM, "David Krizanic" <dkrizanic(a)famousfourmedia.com> wrote: >All, > >We've had registrars come to us with complaints of inability to submit >sunrise applications and it turns out that the ICANN CRL >(http://crl.icann.org/tmch.crl) has expired, since there's been a number >of seemingly unrelated issues over the past months our sunrises have been >suffering. We are now waiting for an update while validating any SMD is >failing. > >Best, >David > >DAVID KRIZANIC >Famous Four Media - Head of Technology >2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar >Phone: +350 216 50006 >Email: dkrizanic(a)famousfourmedia.com > >

1 1

Draft updated PDT specs and request for feedback
by Francisco Arias July 24, 2015

July 24, 2015

Please see below an announcement regarding draft updated PDT specifications and request for feedback. Regards, -- Francisco. On 7/23/15, 8:48 PM, "Russ Weinstein" <russ.weinstein(a)icann.org> wrote: >--- > >Colleagues, > >We have just released a draft of the Pre-Delegation Testing (PDT) >specifications for the Whois Testing, incorporating the recently >published clarification Advisory >(https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04 >-27-en). We would like to use this mailing list to solicit feedback >regarding the specifications between now and August 14. At which point >we will close the feedback period, make any necessary changes to the test >specifications and begin the software development cycle. We plan to >implement testing to the new specifications in early November 2015. All >testing done before the enforcement date of the Advisory (31 January 2015) >will treat any conformance with the Advisory as a "warning condition” and >will not prevent the registry from passing PDT. Any conformance after the >enforcement date will be treated as a "fail condition" and the registry >will not pass PDT until they meet all requirements. > > >Please see the announcement published on 23 July for the release of the >draft Whois specifications: >http://newgtlds.icann.org/en/announcements-and-media/announcement-2-22jul1 >5-en where you will find a link to the documents. Please review the >README file included as it provides more details about the timeline >toward implementation. > >Your feedback and participation is appreciated. Thanks > >__ > >Russ

1 0

FW: IETF lager working group
by Francisco Arias July 19, 2015

July 19, 2015

FYI On 7/18/15, 8:31 AM, "Marc Blanchet" <marc.blanchet(a)viagenie.ca<mailto:marc.blanchet@viagenie.ca>> wrote: Hello, a new IETF working group has been formed recently, named: lager (Label Generation Rules). Charter listed below FYI. This work has impact to any software that checks if domains (especially tlds and 2nd level) are valid for a registry, for various use cases: registration, domain check, etc… Valid not in the IDNA2008 sense, but the « file format » defines the restricted set of code points and related rules (variants for example) accepted by a registry. since the wg was formed after the deadline to submit meeting requests for Prague, we do not have a formal meeting session. But Scott and I, co-chairs, would like to arrange some informal talks (Scott company will pay the lager…) to start the work. Could anyone interested in attending that informal meeting send me+scott an email so we can doodle a meeting time during the Prague IETF week. Regards, Marc. Lager Charter ( http://datatracker.ietf.org/wg/lager/charter/) Domain registries, particularly those implementing IDNA (RFC 5890 et.al), usually maintain a set of criteria (or "ruleset") that governs permissible labels allowed for registration, such as [IANAIDNTABLES]. These rulesets are commonly a mixture of eligible code points along with contextual criteria that must be met concerning the positioning of certain code points. Some registries also specify rules regarding variant labels and how they are to be handled. Domain registries commonly need to share these rules, but there is no interoperable format that can be used that can support many common use cases. This group seeks to produce such a format, which will enable re-use and sharing of existing rulesets, and simpler implementation of new rulesets in registries. A comprehensive format specification has been developed, named Label Generation Rules, primarily to support the rules to be used for the DNS Root Zone [Davies]. This group will use this specification as a starting point to develop a common XML language that provides a superset of functionality of current specifications [RFC 3743, RFC 4290, et.al], along with other known use cases. This single format is expected to supersede existing formats, and form the basis for future rulesets used at different levels of the DNS hierarchy. Work items: - Standard Track Specification of the Label Generation Rules References: [Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/ [IANAIDNTABLES] https://www.iana.org/domains/idn-tables

1 0

Publishing of the Change Poll EPP Extension IETF Draft
by Gould, James July 7, 2015

July 7, 2015

The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/html/draft-gould-change-poll-00 ) has been submitted to the IETF. I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-side change, including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. We would like this draft to be included in a re-charting of the EPPEXT Working Group. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 2