[regext] Lars Eggert's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/



----------------------------------------------------------------------
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.

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?

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.

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.)

-------------------------------------------------------------------------------
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".

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".

Section 5.2, paragraph 7, nit:
>    Example of removing the "clientTransferProhibited" status and setting
>    the authorization information in an [RFC5731] domain name update
>    command.

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

Section 3, paragraph 3, nit:
-    extension services, can expect the following supported behavior by
-                      -
+    extension services can expect the following supported behavior by

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
+                                          +

Section 4.2, paragraph 2, nit:
-    authorization information by the sponsoring registrar, then the
-                                                              -----
+    authorization information by the sponsoring registrar, the

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,
+                                                                         +

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
+                             +

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

Section 5, paragraph 2, nit:
-    To make the transfer process secure using secure authorization
-       ^^^                      -------
+    To secure the transfer process using secure authorization
+       ^^^^^

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
+                                ^^^

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
+   +++++

Section 5.2, paragraph 6, nit:
-    Often the registrar has the "clientTransferProhibited" status set, so
+    Often, the registrar has the "clientTransferProhibited" status set, so
+         +

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
+                          ^^^

Section 5.2, paragraph 9, nit:
-    "eppcom:pwAuthInfoType" element, can have an empty authorization
-                                   -
+    "eppcom:pwAuthInfoType" element can have an empty authorization

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
+                                             +

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
+                                                    +

Section 6.2, paragraph 3, nit:
-       value with either a hashed or encyrpted authorization information
-                                         -
+       value with either a hashed or encrypted authorization information
+                                        +