Lars, Thank you for your review and feedback. Embedded I include responses to your comments. The updates made to the draft will be included in the publishing of draft-ietf-regext-secure-authinfo-transfer-07 after all feedback has been received.
Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/14/21, 11:20 AM, "Lars Eggert via Datatracker" <nore...@ietf.org> wrote: Lars Eggert has entered the following ballot position for draft-ietf-regext-secure-authinfo-transfer-06: No Objection 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://secure-web.cisco.com/1uqwHIhHybLEr4C7TkvDZToJn2za5hg4Nk9euvkmRhyppqzfjOALh0C4MB4fnyNQbi7KZEhL4Jko5NJeQ82DTF0qmrSx-IsqywJy0UFH69E3LarPqg1ERyhEocznd72BQEv9s-ZCzrQoe-5x6XtrrXBTxrAup-49yqM34PbPhpK2zQ5TLLicno3X7TRYWkw0_2_q0QmR5mFBgMxzX9WmGNI67Oufz1xzRAzRmaMlahfm3n7Woal8-2KpDJf_9dh42/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://secure-web.cisco.com/1gPhp7iEV3BSI_vMBwMSw2AUtW7QPm1RfHZGx_sKShFtu9NQLI5DVTEyjI_lEbhAzDz39jLgTXxp_IilyRNVE9XLBzz1hBAznGCuMLhi03Kh8uVcpEySac6XtBOdhRPwlE1cOxoyzJgU-Nzf_q2SCmjt6ukt6gC3DbS-pr9Mi_TG6CYrsHtCJ3zzpxdlmAfQTA-8uWL2--ad53vTP6sYJT0D7Br71c7tdVucPS8BeZQ_OpT6h6Fm6jwepRh3ieV0z/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are quite a few places where I think RFC2119 terms could be used to add clarity. I highlighted a few in the "nits" below, but it would be good to do an editing pass with an eye towards that. JG - Thank you, I'll give it a re-read to identify any issues. Section 1, paragraph 4, comment: > The overall goal is to have strong, random authorization information > values, that are short-lived, and that are either not stored or > stored as a cryptographic hash values by the non-responsible parties. The previous paragraph said "not stored by the client, and that are stored by the server using a cryptographic hash", which is slightly different? Can the client store or not? JG - Section 1, paragraph 4 is describing the goal of having random and short-lived authorization information, and linking the goal to the non-responsible parties, which include the registrar (client) and the registry (server). The requirements for the storage and transport is described in detail in section 4.3, where the authorization information MUST NOT be stored by the losing registrar and MUST only be stored by the gaining registrar as a "transient" value in support of the transfer process. I believe this language is appropriate when combining the client and server into the non-responsible parties. Section 1, paragraph 4, comment: > securely. The operational practice will not require the client > to store the authorization information and will require the Will it "not require the client to store" or will it "require the client not to store"? This is again slightly different to what was said above. JG - I agree this sentence is inconsistent with the remainder of the document, where it should say "The operational practice will require the client to not store the authorization information and ...". Not storing the authorization information is the general case with the transient storage case for the gaining registrar (client), defined using normative language in section 4.3. Section 4.1, paragraph 2, comment: > For authorization information to be secure, it MUST be generated > using a secure random value. The authorization information is Section 4 says "must be generated using a strong random value and have a short time-to-live (TTL)", which is slightly different? (And also doesn't use an uppercase MUST.) JG - You are correct, this is inconsistent. The first paragraph of section 4 is an introductory paragraph, and paragraph 4.1 contains the normative language to meet the goal of the introductory paragraph. I believe it is best to leave the normative language in the sub-section. This is my preference, but I would like to hear from others on this. ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 3, paragraph 3, nit: > A client that receives the namespace URI in the server's Greeting > extension services, can expect the following supported behavior by > the server: The term "client ... can expect" is odd, since it doesn't really map to RFC2119 conformance levels and is hence unclear. Would suggest to rephrase as "a server sending ... MUST implement". JG - Section 3 is associated with protocol signaling and defines the expectation of the other side of the connection (client when server signals and server when client signals), where the expected behavior is based on implementation of the draft and the normative language contained in the other sections. I believe the signaling section should not contain the normative language. Section 3, paragraph 4, nit: > A server that receives the namespace URI in the client's <login> > Command extension services, can expect the following supported > behavior by the client: As above, suggest to rephrase "can expect". JG - Same response to the previous feedback. Section 5.2, paragraph 7, nit: > Example of removing the "clientTransferProhibited" status and setting > the authorization information in an [RFC5731] domain name update > command. JG - This was the approach taken in the latest EPP RFC 8807, which the exception of the use of a colon at the end. I'll update each example reference to end with a colon instead of a period to be consistent. Not a complete sentence. (Similar issues in other "Example of" paragraphs below.) Section 1, paragraph 3, nit: - that are stored by the server using a cryptographic hash to provide, - - - for secure authorization information used for transfers. This - ---- + that are stored by the server using a cryptographic hash to provide + secure authorization information used for transfers. This JG - Will update Section 3, paragraph 3, nit: - extension services, can expect the following supported behavior by - - + extension services can expect the following supported behavior by JG - Will update Section 4, paragraph 2, nit: - authorization information to be secure it must be generated using a + authorization information to be secure, it must be generated using a + + JG - Will update Section 4.2, paragraph 2, nit: - authorization information by the sponsoring registrar, then the - ----- + authorization information by the sponsoring registrar, the JG - Will update Section 4.2, paragraph 2, nit: - client policy may be based on proprietary registrar-specific criteria + client policy may be based on proprietary registrar-specific criteria, + + JG - Will update Section 4.3, paragraph 3, nit: - 256-bit hash function such as SHA-256 [FIPS-180-4], and with a + 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a + + JG - Will update Section 4.3, paragraph 3, nit: - an NULL (undefined) value is dependent on the type of database - - + a NULL (undefined) value is dependent on the type of database JG - Will update Section 5, paragraph 2, nit: - To make the transfer process secure using secure authorization - ^^^ ------- + To secure the transfer process using secure authorization + ^^^^^ JG - Will update Section 5.2, paragraph 4, nit: - Because of this, registries may validate the randomness of the - ^^^ + Because of this, registries MAY validate the randomness of the + ^^^ JG - I will leave it as is, since this language was worked out with Barry Leiba, Benjamin Kaduk, and Roman Danyliw. Section 5.2, paragraph 5, nit: - sufficiently strong. Registrars, therefore, must be prepared for an - ^^^^ + sufficiently strong. Registrars, therefore, MUST be prepared for an + ^^^^ Section 5.2, paragraph 5, nit: - respond by generating a new value and trying again, possibly more + MUST respond by generating a new value and trying again, possibly more + +++++ JG - I will leave it as is, since this language was worked out with Barry Leiba, Benjamin Kaduk, and Roman Danyliw. Section 5.2, paragraph 6, nit: - Often the registrar has the "clientTransferProhibited" status set, so + Often, the registrar has the "clientTransferProhibited" status set, so + + JG - Will update Section 5.2, paragraph 9, nit: - cancels the transfer process by unsetting the authorization - - - information value and may add back statuses like the - ^^^ + MUST cancel the transfer process by unsetting the authorization + +++++ + information value and MAY add back statuses like the + ^^^ JG - Will update Section 5.2, paragraph 9, nit: - "eppcom:pwAuthInfoType" element, can have an empty authorization - - + "eppcom:pwAuthInfoType" element can have an empty authorization JG - Will update Section 6, paragraph 2, nit: - incremental steps of adoption. The transtion steps are dependent on + incremental steps of adoption. The transition steps are dependent on + + JG - I don't see a change above, where the pagination has the text lined up with the text above. Section 6.2, paragraph 3, nit: - and the update command to hash instead of encyrpting the - - + and the update command to hash instead of encrypting the + + JG - I don't see a change above, where the pagination has the text lined up with the text above. Section 6.2, paragraph 3, nit: - value with either a hashed or encyrpted authorization information - - + value with either a hashed or encrypted authorization information + + JG - I don't see a change above, where the pagination has the text lined up with the text above. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
