Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

From: "Gould, James" <[email-masked]>
Date: Mon, 26 Apr 2021 21:08:29 +0000

Benjamin,

Thank you for your review and feedback.  I provides responses to your feedback embedded below.  Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will include changes from all of the feedback.

-- 

JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 4/21/21, 2:23 PM, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-regext-secure-authinfo-transfer-06: Discuss

    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/1x_mIFJ-zLPWFIDcykQFrXjxI71ZzFb_Wg7ZircyyhLW3CozdpwX3kNVg-mA5pDco5KEF8jHedG3kgX3Q9Xo2Net7Z5ohit0rRUUO1sjN0ZRmH-nKWURhgj3Iipq2JCdntBQ8pPbfJjvs4-xhVAysJ15K5B70hN2mLAmEhWFJLS1w_efP56Yn5-KMKtlrZbApoCRZf7rPXivpD0tFvZqUsCiaLJhRjezITS4nbdupjnrUei5o_FQWC5daBK4VUYj0/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
    for more information about DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://secure-web.cisco.com/1-l6dghkg8Lo7AiBGMYiae0h6FJhNsRSH26_rZNPQlWnaRgYK3kcZxY9W14m-dMM0khwg1IGtGRa8UhciRD20JvFL9P0TtgqnlBTwfsC-rxGTFVwOCtzkVhrRQGFF_Pi3vFSZPLTiJiPn1UhzOF_Qq0DxpjByXgIjKlBVR3SX6CxZg7ks5LXDTO9TuSSrXkvIlPQiQrQ-tuOvHqbxu2dJ_w4JbLhg9_aU-HVKpvcXM1W4CSEIcK2RYz7l2sGol9-1/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F

    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    (1) RFC 4086 does not state that "a high-security password must have at
    least 49 bits of randomness or entropy" as is claimed in Section 4.1 of
    this document.  It merely says that so much entropy is needed to have a
    one-in-a-billion chance of success for successfully guessing in the
    model laid out, and makes no statement about (absolute) "high" security.
    I don't think we need to spend as much time on what RFC 4086 says as we
    currently do, and could probably get to the "use at least 128 bits of
    entropy" advice much sooner.

JG - In section 8.1 of RFC 4086, it states "For a higher-security password, ... To go to a one-in-10^9 change, 49 bits of randomness are needed, ...".  To be accurate with the language in RFC 4086, "high-security" can be changed to "higher-security".  Do you agree with making that change?

    (2) There's also some text in Section 5.3 that I'd like to discuss briefly:

       The registry MUST NOT return any indication of whether the
       authorization information is set or unset to the non-sponsoring
       registrar by not returning the authorization information element in
       the response.  The registry MAY return an indication to the
       sponsoring registrar that the authorization information is set by
       using an empty authorization information value.  The registry MAY
       return an indication to the sponsoring registrar that the
       authorization information is unset by not returning the authorization
       information element.

    This seems to be assigning semantics to both absent-authinfo and
    empty-authinfo in the <info> response, but is giving *different* semantics
    to the response-to-sponsoring-registrar and
    response-to-non-sponsoring-registrar cases.  Is there precedent for
    changing the semantics of the response based on the identity of the
    client like this (not just changing the content of the response)?  Can
    we come up with a scheme that provides consistent semantics to all
    clients, perhaps based on <domain:null> vs empty <domain:pw> for
    unset/set, leaving "element is absent" for the deliberately ambiguous
    case?

JG - Yes, draft-ietf-regext-secure-authinfo-transfer changes the semantics of the RFC 5731 info response (section 3.1.2) based on the identity of the client.   The exact mechanism for signaling the existence or non-existence of authorization information is an element of draft-ietf-regext-secure-authinfo-transfer that needs to take into account the data sponsored (owned) by the registrar.  Non-sponsoring registrars don't have a need to know and must not know of the existence or non-existence of the authorization information.  Only the sponsoring registrar has a need to know.    

    (3) We may also need to discuss the efficacy of the transition plan, per
    my comments in Sections 6.1 and 6.3 -- my current understanding is that
    the proposed plan will break some existing workflows.  I am not sure if
    that is intended, desirable, and/or tolerable, and welcome further
    insight.

JG - I responded to your feedback on section 6.1 and 6.3 below.  Implementing the transition plan is up to server policy, which includes the data used (e.g., % of registrars that signal support in login, % of registrars not setting authorization information on create) to determine the impact and best timing of the phases, the approach taken to notify the registrars (e.g., maintenance notices and reaching out to impacted registrars), and rollout plan (e.g., deploy to OT&E, deploy incrementally in Production with monitors).  Implementing non-backward compatible changes in the registry is not new and in general needs to be handled with adequate notification and in incremental steps.  Deprecating and removing TLS protocols and ciphers is a perfect example of rolling out a non-backward compatible change that is up to registry policy to handle.  The timing, notification, and legal aspects of implementing the transition is based on server policy.  

JG - 

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    I think that the introduction would benefit from expanding on the
    high-level motivation for this work (which I assume to include): the
    current/original lifecycle for authorization information involves
    long-term storage of encrypted (not hashed) passwords, which presents a
    significant latent risk of password compromise and is not consistent
    with current best practices.  The mechanisms in this document provide a
    way to avoid long-term password storage entirely, and to only require
    the storage of hashed (not retrievable) passwords instead of encrypted
    passwords.  (Or, in a more colloquial language, "passwords suck, and we
    want to get out of the business of handling them to the extent
    possible".)  The third paragraph does talk about the "overall goal", but
    doesn't say much about what we're moving *away* from (and why).

JG - I will add the following second paragraph to the introduction based on what you provided above:

The current/original lifecycle for authorization information involves
long-term storage of encrypted (not hashed) passwords, which presents a
significant latent risk of password compromise and is not consistent
with current best practices. The mechanisms in this document provide a
way to avoid long-term password storage entirely, and to only require
the storage of hashed (not retrievable) passwords instead of encrypted
passwords.

    I think giving some explicit consideration of the lifecycle and protocol
    interactions for the password 'salt' would be helpful.  (That is, that
    it's picked at random by the registry per password when a password is
    set and never goes on the wire, but is stored alongside the hashed
    password.)

JG - I'm not clear on the lifecycle and protocol interactions of the authorization information 'salt'.  The requirement is for the authorization information to be hashed with a salt.  Roman asked about guidance related to the length of the salt.  The purpose of the extension is to not cover the details of creating a salted hashed authorization information.  Some guidance can be provided on the length and aspects of the salt.  Do you have any recommendations or relevant references that would be useful in providing the guidance?

    The treatment in the introduction of "[use] the existing features of the
    EPP RFCs" made me wonder why this needed to be on the standards-track,
    as opposed to being an informational description of how to use what's
    already there.  The actual core of the spec, which includes changes to
    the semantics of some XML elements (e.g., in the info response), is
    clearly protocol work, though, so perhaps the abstract/introduction
    could be revisited to clarify the scope of the work.

JG - There is signaling of support of the practice by the client and the server in section 3 and the behavior implemented in the existing EPP commands in section 5, which are relevant to the protocol.  We had discussed the desired track of the draft in the working group which was captured in section 1 " What type of RFC is being requested" of the shepherd writeup. 

    Section 1

       "Strong Random Authorization Information":  The EPP RFCs define the
           password-based authorization information value using an XML
           schema "normalizedString" type, so they don't restrict what can
           be used in any way.  This operational practice defines the

    I suggest s/in any way/in any substantial way/ (not being able to use
    CR/LF/TAB is in some sense a restriction).

JG - Update will be made

       "Short-Lived Authorization Information":  The EPP RFCs don't
           [...]
           upon a successful transfer.  All of these features can be
           supported by the EPP RFCs.

    They can be supported, sure, but what about in practice?  Can we rely on
    such functionality being present?

JG - There is a mix in practices based on the discussion in the working group.  

    Section 3

       namespace URI in the login and greeting extension services.  The
       namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-
       1.0" is used to signal support for the operational practice.  The

    Written in this way this is codepoint squatting, assuming that the
    requested XML namespace value will be assigned.  Given that Section 8
    implies this stuff is deployed already, there really should have been an
    early allocation made.

JG - Elements of the draft have been implemented and in the case of the Verisign EPP SDK it has been implemented in Development.  Given the context and expected timing, conflict issues with the XML namespace "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" registration would seem unlikely as a practical matter.

       A client that receives the namespace URI in the server's Greeting
       extension services, can expect the following supported behavior by
       the server:

       1.  Support an empty authorization information value with a create
           command.
       [...]

    It's interesting to compare this to RFC 5731, that says "Authorization
    information as described in Section 2.6 is REQUIRED to create a domain
    object.  [...]  Failure to protect authorization information from
    inadvertent disclosure can result in unauthorized transfer operations
    and unauthorized information release.  [...]"  In some sense we are
    introducing a rather significant philosophical change in the nature of
    authorization information, that might be called out more prominently.

JG - The requirement for the authorization information at the time of create is one of the drivers for the definition of the extension.  How about referencing the requirement defined section 2.6 of RFC 5731 in the "Short-Lived Authorization Information" description of the Introduction: 

"The EPP RFCs don't explicitly support short-lived authorization information or a time-to-live (TTL) for authorization information, but there are EPP RFC features that can be leveraged to support short-lived  authorization information.  In section 2.6 of [RFC5731] it states that authorization information is assigned when a domain object is created, which results in long-lived authorization information.  This specification changes the nature of the authorization information to be short-lived.  If authorization information is set only when...."  

Does this help?

       7.  Support automatically unsetting the authorization information
           upon a successful completion of transfer.

    Just "support", or actually will in practice?
    (Probably applies to some of the other enumerated points as well, for
    both client and server, though I think not to all of them.)

JG - Support does mean will in this case.  Perhaps clarified with this proposed edit:  "Automatically unset the authorization information upon a successful completion of transfer.".  Do you believe this edit is helpful?

    Section 4

       with the <contact:pw> element).  Other EPP objects that support
       password-based authorization information for transfer can use the
       Secure Authorization Information defined in this document.  For the

    This is phrased just as "can use" (not "will use"), but we are
    supposedly defining an XML namespace used for capability negotiation in
    the initial EPP exchange, which really ought to have well-specified
    semantics.  *Must* the secure authorization information defined in this
    document be used for any applicable transfer, when the XML namespace we
    define is in effect for the capabilities to use?

JG - In the base EPP RFC 5730 authorization information is required, but the type of authorization information required is object-specific.  There is no requirement for all EPP objects to support password-based authorization information, which is the reason for the "can use" language.  The XML namespace defines the capabilities to use when password-based authorization information is used by the EPP object.  Do you believe "can use" should be changed to "MAY use"?    

    Section 4.1

       The strength of the random authorization information is dependent on
       the actual entropy of the underlying random number generator.  For
       the random number generator, the practices defined in [RFC4086] and
       section 4.7.1 of the NIST Federal Information Processing Standards
       (FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to produce
       random values that will be resistant to attack.  A random number
       generator (RNG) is preferable over the use of a pseudorandom number
       generator (PRNG) to reduce the predictability of the authorization
       information.  The more predictable the random number generator is,
       the lower the true entropy, and the longer the required length for
       the authorization information.

    This is not really the advice that I would be giving, myself.
    For one, using a true RNG is not necessarily better than a PRNG, since a
    good PRNG will have a lot of well-thought-out "whitening" functionality
    that makes the output fairly uniform.  A true RNG can be a true RNG
    while still sampling from a non-uniform distribution and leaving
    patterns in the output.  But more importantly, implementors of EPP are
    highly unlikely to need to care about the entropy gathering practices
    specified by NIST SP 140-2 and RFC 4086 -- they can and should just use
    /dev/urandom!  RFC 4086 was written in a time when /dev/urandom was not
    as reliable as it is nowadays, but the advice of "to obtain randon
    numbers under Linux, Solaris, [...] all an application has to do is open
    either /dev/random or /dev/urandom and read the desired number of
    bytes" is arguably the most important guidance in it.  (There's also a
    corresponding Windows API.)  If we don't think people will want to
    implement a 94-character alphabet themselves, we can suggest the widely
    available base64 encoding and say something like "read 18 bytes from
    /dev/random and base64 encode it, which will produce 24 characters of
    encoded output" or give the ROUNDUP(128/log2 64) math.  (I use 18 bytes
    because that avoids base64 padding characters.)

JG - I understand what you're saying, but I believe it's best to reference publicly available documents and provide guidance based on them.  Do you have any revised references that you would recommend including?  

    Section 4.2

    I strongly suggest giving some guidance to registrars on how to set the
    TTL (presumably a week or a few days is doable for common/generic domain
    transfers?).  The requirements in §4.3 are not really aligned with
    current best practices for password hashing for long term storage
    (which, admittedly, are designed for human-selected passwords and not
    random ones), so clamping down the TTL is going to be helpful for
    putting bounds on some classes of attack.

JG - The TTL is up to the registrar's business practices based on the perceived importance of a domain.  The guidance is that the authorization information should only be set during the transfer process.  This will be in days and not weeks or months, which was the concern that Roman had.  

    Section 4.3

    I note that draft-ietf-kitten-password-storage is underway to write
    down best practices for password hashing and storage.  It is probably
    not mature enough to be used as a definitive reference yet, but could be
    useful information.

JG - Great, thank you for the reference.  I'll give it a read.  

       1.  The authorization information MUST be stored by the registry
           using a strong one-way cryptographic hash, with at least a
           256-bit hash function such as SHA-256 [FIPS-180-4], and with a
           random salt.

    Typical password-hashing recommendations these days are things like
    Argon2 (winner of https://www.password-hashing.net/) or PBKDF2 (for
    somewhat more legacy systems).  The iteration count (and other
    parameters, for Argon2) can be tweaked depending on the systems in
    question and the esteimated strength of the password, but nobody is
    doing just a single-iteration of (salted) SHA256.  I note that we
    recently approved draft-ietf-lamps-crmf-update-algs that leaves in place
    a requirement that the iteration count MUST be at least 100 (and adds
    "SHOULD be as large as server performance will allow, typically at least
    10,000").  If the intent is to take advantage of the special
    considerations here about the nature of the passwords in question, in
    order to diverge from password-hashing best practice, we should be
    explicit about the intentional divergence.

JG - The goal of the draft is for the registries to use a strong one-way cryptographic hash. Inclusion of the "at least a 256-bit hash function such as SHA-256 [FIPS-180-4], and with random salt" language was added to provide some guidance, but it comes down to server policy and best practices at the time in choosing the desired hashing function and attributes (e.g., iteration count).  Let me know if you have any relevant RFCs that can be referenced for applicable hashing practices.  

       5.  The plain text version of the authorization information MUST NOT
           be written to any logs by the registrar or the registry, nor

    nit: "the registrar" is perhaps ambiguous in this scenario where we have
    both losing and gaining registrars.

JG - References to "the registrar" applies to both the losing and gaining registrar.   How about making the edit :  s/"the registrar or the registry"/"a registrar or registry"?  

    Section 4.4

       1.  Any input authorization information value MUST NOT match an unset
           authorization information value.

    Does this only apply to non-empty input authorization information?

JG - Yes, the WG wanted to ensure that an unset authorization information value is never incorrectly matched with an input authorization information value.

       3.  A non-empty input authorization information value MUST be hashed
           and matched against the set authorization information value,
           which is stored using the same hash algorithm.

    It might be worth a few sentences (not necessarily here) about
    password-hashing-algorithm agility and what an algorithm transition
    would look like.

JG - I believe the details of password-hashing-algorithm agility and algorithm transition is implementation that is based on server policy.  Let me know whether you have any current best standard practices to reference for guidance.

    Section 5.2

       Because of this, registries may validate the randomness of the
       authorization information based on the length and character set
       required by the registry.  For example, validating an authorization
       value contains a combination of upper-case, lower-case, and non-
       alphanumeric characters, in an attempt to assess the strength of the
       value, and return an EPP error result of 2202 if the check fails.

       Such checks are, by their nature, heuristic and imperfect, and may
       identify well-chosen authorization information values as being not
       sufficiently strong.  Registrars, therefore, must be prepared for an
       error response of 2202, "Invalid authorization information", and
       respond by generating a new value and trying again, possibly more
       than once.

    I note for the record that we had an earlier conversation about this
    behavior, and I still believe that it does not reflect a best practice
    for minimizing the use of weak passwords.  That said, it is a
    non-normative example, and we basically already had our discussion on
    this topic, so there is no need to rehash it again -- this is a
    non-blocking comment.

    Section 6

       3.  Losing registrar retrieves the stored authorization information
           locally or queries the registry for authorization information

    nit: I think s/retrieves the stored authorization information
    locally/retrieves the locally stored authorization information/ helps
    readability.

JG - Update will be made

    Section 6.1

    How do these features interact with the presence (or absence) of the
    secure-authinfo-transfer XML namespace in the <login>/greeting exchange?

    It seems like at least the "don't return the authorization information
    in the info response" change, if unilaterally implemented by the
    registry, would break the classic workflow for registrars that do not
    store the authorization information locally and require retrieving it
    from the registry.  (Or are they required to implement the ability to
    re-set the authorization information with an update, so that recovery is
    possible?)

JG - Correct, you picked up on the only non-backward compatible change in the transition.  Inclusion of not returning the authorization information in an info response in Transition Phase 1 is important to enable Transition Phase 2 to be done in the background without any direct impact to the registrars.  It's up to server policy, but generally registries would provide notice to registrars ahead of deployment for the updated behavior. 

    Section 6.2

       Hash New Authorization Information Values:  Change the create command
          and the update command to hash instead of encyrpting the

    nit: s/encyrpting/encrypting/

JG - Update will be made

       Supporting Comparing Against Encrypted and Hashed Authorization
       Information:  Change the info command and the transfer request
          command to be able to compare a passed authorization information
          value with either a hashed or encyrpted authorization information
          value.

    This seems to leave it implicit that the stored values in the registry
    include an indication of whether they are encrypted or hashed.  This is
    probably trivial to ensure, just by virtue of being formatted
    differently, but is an important enough property that I would suggest
    mentioning it specifically.

JG - Yes, it will be trivial to identify a stored encrypted value versus a stored hashed value.  Do you have any suggested text to provide clarity?

    Section 6.3

    As for the case in Section 6.1, are these changes contingent on the
    negotiation of the use of secure-authinfo-transfer?  Disallowing the
    creation of entries with non-empty authorization information values
    seems like it would break existing clients that do not implement
    secure-authinfo-transfer.  Is there some mechanism in place that is
    going to make secure-authinfo-transfer (e.g., contractually) required to
    implement for registrars?

JG - It is up to server policy on the timing and approach taken to notify the registrars with implementing the transition phases.  

    Section 9

       Section 4.1 defines the use a secure random value for the generation
       of the authorization information.  The server SHOULD define policy
       related to the length and set of characters that are included in the
       randomization to target the desired entropy level, with the
       recommendation of at least 128 bits for entropy.  The authorization
       information server policy is communicated to the client using an out-
       of-band process.  The client SHOULD choose a length and set of
       characters that results in entropy that meets or exceeds the server
       policy.  A random number generator (RNG) is preferable over the use
       of a pseudorandom number generator (PRNG) when creating the
       authorization information value.

    [my comment from above about RNG vs PRNG applies here as well.]

JG - Do you have any revised practices that you recommend referencing when it comes to the use of RNG vs PRNG?

    I am a little uneasy about the "SHOULD define policy", which may just
    reflect a misundersanding of the text.  If this is just an
    administrative policy that is written and read by humans, that is
    probably useful, but how it interacts with mechanical enforcement (per
    my previous comments) could spill over into a regime of giving normative
    recommendations to do things that I do not believe are best practice.

JG - Are you proposing to change the normative "SHOULD" with a non-normative "should"?   I believe it is important that the servers do define a policy to meet the desired entropy level.  

       Section 4.2 defines the use of an authorization information Time-To-
       Live (TTL).  The registrar SHOULD only set the authorization
       information during the transfer process by the server support for

    I guess I don't understand why this is only a SHOULD (and this same
    requirement seems to appear in Section 4.2 as well).  Given that we
    propose for the registry to reject creation with non-empty authorization
    information, it doesn't seem too big of a change to require that
    registrars also comply with this workflow.

JG - The reason for the SHOULD is that authorization information can be used for other purposes other than transfer, where the other purposes and the applicable elements are out-of-scope as defined in the Introduction.  In practice authorization information is only used for transfer, but there may be cases where authorization information can be used outside of the transfer process.

       the end of the transfer process.  The registry MUST store the
       authorization information using a one-way cryptographic hash of at
       least 256 bits and with a random salt.  All communication that

    [this text might have to change if the earlier comment about password
    hashing techniques results in a textual change]

JG - See my comment above.  

    Section 11.1

    (If my suggestion about RNG guidance is accepted, FIPS-140-2 will no
    longer need to be a normative reference.)

JG - Do you have any revised practices that you recommend referencing when it comes to the use of RNG vs PRNG?  The reference can be updated, but without another reference I would like to keep the normative reference to FIPS-140-2.

    I don't really understand why RFC 3688 is listed as normative but RFC
    7451 is listed as informative -- on both cases they're only referenced
    as the specification that created an IANA registry that we're getting
    an allocation in.

JG - The latest EPP RFC is RFC 8807, which lists RFC 3688 as normative.  The prior EPP RFC with RFC 8748 also lists RFC 3688 as normative.  This draft is following what was done in the prior two EPP RFCs.  I don't have an issue making it an informative reference if that is best.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Apr 2021 14:53:05 -0700

Hi James,

Also inline.

> Thank you for your review and feedback.  I provides responses to your feedback embedded below.  Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will include changes from…

I do not agree with that change.  "Higher" is inherently relative to some
baseline; in the case of RFC 4086, "higher-security" is with respect to the
baseline it has laid out of "an attacker has a 1-in-1000 chance of guessing
correctly given [scenario]".  The example given for "higher-security" just
moves the target from one in a thousand to one in a billion, but to be
strong in an absolute sense, we typically talk about a 1 in 2^64 or
1 in 2^128 chance of success.

Given that we go on to ignore the "49 bits" number and do the actual right
thing (128 bits of entropy) in the next paragraph, I don't really think we
need to reference this part of RFC 4086 at all.

That could condense things down, for example via:
OLD:
   For authorization information to be secure, it MUST be generated
   using a secure random value.  The authorization information is
   treated as a password, where according to [RFC4086] a high-security
   password must have at least 49 bits of randomness or entropy.  The
   required length L of a password, rounded up to the largest whole
   number, is based on the set of characters N and the desired entropy
   H, in the equation L = ROUNDUP(H / log2 N).  Given a target entropy,
   the required length can be calculated after deciding on the set of
   characters that will be randomized.

   Considering the age of [RFC4086], the evolution of security
   practices, and that the authorization information is a machine-
   generated value, the implementation SHOULD use at least 128 bits of
   entropy.  The lengths are calculated below using that value.

NEW:
   For authorization information to be secure, it MUST be generated
   using a secure random value.  The authorization information is treated
   as a password, and the required length L of a password, rounded up to the
   largest whole number, is based on the size N of the set of characters and
   the desired entropy H, in the equation L = ROUNDUP(H / log2 N).  Given a
   target entropy, the required length can be calculated after deciding on the
   set of characters that will be randomized.  In accordance with current
   best practices and noting that the authorization information is a
   machine-generated value, the implementation SHOULD use at least 128 bits of
   entropy as the value of H.  The lengths below are calculated using that
   value.

> JG - Yes, draft-ietf-regext-secure-authinfo-transfer changes the semantics of the RFC 5731 info response (section 3.1.2) based on the identity of the client.   The exact mechanism for signaling the…

I agree with your assessment of who needs to know what information.

I was trying to ask if we have a way to provide information (and not
provide information) in a way such that the semantics of the elements in a
given response do not depend on the identity of the client, since such
client-independence seems like it would result in a simpler implementation
and reduce the likelihood of security-relevant bugs.

If there is not such a way, that seems perhaps tolerable, but I did not see any
evidence that the WG had considered this topic and looked for a way to
provide those properties (giving the different parties the correct amount of
information and having the semantics of response elements be independent of
the client the response is sent to).  If the WG has already considered this
topic I'm happy to drop the discuss point; however, I think I provided a
sketch of a possible approach that could achieve these goals, and do not
see any argument presented that such a scheme is not workable.

> JG - I responded to your feedback on section 6.1 and 6.3 below.  Implementing the transition plan is up to server policy, which includes the data used (e.g., % of registrars that signal support in…

Okay, I will respond below as well.

Thank you!

> JG - I'm not clear on the lifecycle and protocol interactions of the authorization information 'salt'.  The requirement is for the authorization information to be hashed with a salt.  Roman asked a…

My advice would be to pick a new random salt (128 bits is enough) each time
a password hash is to be stored, and store that salt for the duration of
the TTL (i.e., alongside the hashed password).  This is in contrast to
having a single salt per domain/object that is used for multiple passwords,
or having only a single salt per registry.

> JG - There is signaling of support of the practice by the client and the server in section 3 and the behavior implemented in the existing EPP commands in section 5, which are relevant to the protoc…

To be clear, I'm happy with this document being a Proposed Standard; I am
less sure whether the Abstract/Introduction should be talking about
"defines an operational practice" vs "defines a protocol mechanism" (etc.).

> JG - There is a mix in practices based on the discussion in the working group.  

Ah, interesting.  Would it work to say "all of these features are
compatible with the EPP RFCs, though not mandatory to implement"?  IMO that
gives a clearer picture of what the reader can expect from an existing
implementation.

> JG - Elements of the draft have been implemented and in the case of the Verisign EPP SDK it has been implemented in Development.  Given the context and expected timing, conflict issues with the XML…

It does seem unlikely to cause issues as a practical matter, which is why I
decided to not make a Discuss-level point about it.

> "The EPP RFCs don't explicitly support short-lived authorization information or a time-to-live (TTL) for authorization information, but there are EPP RFC features that can be leveraged to support s…

I like this text, though I'm not entirely sure where you are proposing to
put it.  I guess it could fit near the start of the section (i.e., before
the "A client that receives [...]")

> JG - Support does mean will in this case.  Perhaps clarified with this proposed edit:  "Automatically unset the authorization information upon a successful completion of transfer.".  Do you believe…

Yes, thank you.

> JG - In the base EPP RFC 5730 authorization information is required, but the type of authorization information required is object-specific.  There is no requirement for all EPP objects to support p…

I'm not entirely sure what effect we think changing "can use" to "MAY use"
will have.  My new understanding in light of your reply above is that (1) there
are not any other publicly defined EPP objects that support password-based
authorization information, and (2) we expect that any future EPP objects
that support password-based authorization information to specify their
interaction with the capabilities defined by the XML namespace created by
this document.  In my opinion it's more important to talk about the
expectations on future specifications than what options are available to
them, so we might say something about "specifications that define other EPP
objects" rather than the objects themselves.

> JG - I understand what you're saying, but I believe it's best to reference publicly available documents and provide guidance based on them.  Do you have any revised references that you would recomm…

I think the RFC 4086 reference can work, if framed suitably.  Something
like:

  The strength of the random authorization information is dependent on the
  random number generator.  Suitably strong random number generators are
  available in a wide variety of implementation environments, including the
  interfaces listed in Sections 7.1.2 and 7.1.3 of [RFC4086].

If you think this doesn't provide enough guidance for situations in which
there is not a useeful API available, we could also add something like:

  In environments that do not provide interfaces to strong random number
  generators, the practices defined in [RFC4086] and section 4.7.1 of the
  NIST Federal Information Processing Standards (FIPS) Publication 140-2
  [FIPS-140-2] can be followed to produce random values that will be
  resistant to attack.

> JG - The TTL is up to the registrar's business practices based on the perceived importance of a domain.  The guidance is that the authorization information should only be set during the transfer pr…

(I'm happy to keep this topic to Roman's thread.)

> JG - The goal of the draft is for the registries to use a strong one-way cryptographic hash. Inclusion of the "at least a 256-bit hash function such as SHA-256 [FIPS-180-4], and with random salt" l…

(I think the kitten draft mentioned above may be the first RFC that's
really in this space.  RFC 7617 mostly defers to
https://password-hashing.net, and for other IETF protocols we tend to
prefer to specify things that don't involve sending passwords around...)

> JG - References to "the registrar" applies to both the losing and gaining registrar.   How about making the edit :  s/"the registrar or the registry"/"a registrar or registry"?  

Sounds good.

> JG - Yes, the WG wanted to ensure that an unset authorization information value is never incorrectly matched with an input authorization information value.

I guess there are three potential cases that I had in mind for nailing down
the specific semantics for the input authorization information:

(1) <domain:authInfo><domain:null/></domain:authInfo>
(2) <domain:authInfo><domain:pw/></domain:authInfo>
(3) [there is no <domain:authInfo> element present]

Which (if any) of these three cases fall under the umbrella of "any input
authorization information"?  IMO, both (1) and (2) would be matched by the
language as written, but I don't think that the "MUST NOT match" is
supposed to apply to at least (1) and maybe not to (2) either.

So, I think that a text change is likely in order so that we really nail
down what behavior is expected for these edge cases.

> JG - I believe the details of password-hashing-algorithm agility and algorithm transition is implementation that is based on server policy.  Let me know whether you have any current best standard p…

I think BCP 201 is the go-to guidance for the need for algorithm agility.
That said, it's not terribly relevant for this specific text that I quoted;
if we are going to reference it it would need to be somewhere else.

>     secure-authinfo-transfer XML namespace in the <login>/greeting exchange?

It sounds like the intent is for the server to just make these behavior
changes regardless of the capability negotiation, then?

> JG - Correct, you picked up on the only non-backward compatible change in the transition.  Inclusion of not returning the authorization information in an info response in Transition Phase 1 is impo…

It seems like we should probably have some text in the document
acknowledging that there is potential for breakage if this change is made
in an uncoordinated manner, with either implicit or explicit recommendation
for the registries to provide notice of the change via an out-of-band
policy channel.

> JG - Yes, it will be trivial to identify a stored encrypted value versus a stored hashed value.  Do you have any suggested text to provide clarity?

"This requires that the stored values are self-identifying as being in
hashed or encrypted form"

> JG - It is up to server policy on the timing and approach taken to notify the registrars with implementing the transition phases.  

As for §6.1, I'd suggest that we have explicit text mentioning the risk
(and expectation of out-of-band mitigation).

> JG - Do you have any revised practices that you recommend referencing when it comes to the use of RNG vs PRNG?

My recommendation is to just omit the last sentence.

> JG - Are you proposing to change the normative "SHOULD" with a non-normative "should"?   I believe it is important that the servers do define a policy to meet the desired entropy level.  

I can't answer your question without knowing how you intend for this policy
to be enforced.  I think it's fine for the out-of-band communications from
registry to registrar to say "you need to use [strong random password, 128
bits, etc.] with characters selected from a set including [whatever] and
length at least [computed value]" and be able to impose contractual penalty
if audit discovers that the registrar failed to do so.  I am not okay with
either "SHOULD" or "should"-level suggestion that the registry software
should require at least one character from multiple character classes for
each submitted password at runtime.  (Checking the length at runtime is
fine.)

> JG - The reason for the SHOULD is that authorization information can be used for other purposes other than transfer, where the other purposes and the applicable elements are out-of-scope as defined…

Okay, thanks for the extra explanation.

> JG - Do you have any revised practices that you recommend referencing when it comes to the use of RNG vs PRNG?  The reference can be updated, but without another reference I would like to keep the…

I think that I am unsure what you are intending the terms "RNG" and "PRNG"
to mean, so it's hard to have a productive conversation.

For example, the term "PRNG" does not appear at all in FIPS 140-2, which
instead talks about "deterministic RNG"s and "nondeterministic RNG"s.
What it calls "deterministic RNGs" are inherently PRNGs, since they cease
to have random-like properties if the seed(s) (and algorithm) are disclosed.
What it calls "nondeterministic RNGs" are things that "produce output that
is dependent on some unpredictable physical source that is outside human
control" (for example, this might be based on radioactive decay, microphone
"shot noise", video of a laval lamp).  These are what I refer to as (true)
RNGs, since there is no "pseudo" part that can be unmasked based on
disclosure of some separable information.  Even FIPS 140-2, however, does
not want you to use nondeterministic RNG outputs directly for
keys/passwords -- they can only be used to produce seeds for deterministic
RNGs and to produce IVs.

So I'd really like to hear what you think "RNG" means and why you think
FIPS 140-2 is supporting the use of RNGs over PRNGs.

> JG - The latest EPP RFC is RFC 8807, which lists RFC 3688 as normative.  The prior EPP RFC with RFC 8748 also lists RFC 3688 as normative.  This draft is following what was done in the prior two EP…

It doesn't really matter either way; there's basically no harm in listing
something as normative when it doesn't have to be.  I just mentioned it out
of a desire for consistency within the document; if you prefer to have
consistency across documents I won't argue with that.

Thanks,

Ben