Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

["Gould, James" <[e-mail]>]

Barry,

I have no issue with changing "recommended" to "RECOMMENDED" in:

       It is RECOMMENDED that the plain text password in the <loginSec:pw>
       and <loginSec:newPw> elements use printable ASCII characters #x20
       (space) - #x7E (~), with high entropy, such as 128 bits.  If non-
       ASCII characters are supported with the plain text password, then use
       a standard for passwords with international characters, such as the
       OpaqueString PRECIS profile in [RFC8265].

This will be included in draft-ietf-regext-login-security-09 assuming there are no additional changes needed to address this final DISCUSS item.

Thanks,

-- 
 
JG



James Gould
Distinguished Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

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

On 2/15/20, 12:12 AM, "Barry Leiba" <[e-mail]> wrote:

    Hi, all...
    
    I'm sorry if I'm not completely clear about where the discussion is,
    but what Jim's mail system does to the quoting is horrendous (as is
    the case with most HTML-based mail systems), and I can't easily follow
    the thread.
    
    So I'm just picking up this recent bit from Ben:
    
    > I think it would probably be helpful for the responsible AD to chime in; my
    > understanding is still that the PRECIS profiles are to be used as part of a
    > protocol as opposed to part of a deployment, and that allowing for
    > different rules to be used in different sites is risky.  I understand that
    > there's the extra context here of the potential for preexisting deployments
    > that started using non-ASCII passwords in the absence of any guidance from
    > the IETF on how to do so, and we have to consider whether what we do will
    > break them, and so hearing from someone versed in the matter who has
    > thought about this particular case would help assuage my concerns.  One
    > possible route (given that, as I understand it, a lot of EPP deployments
    > involve exchange of configuration and deployment information between peers
    > out of band) would be to say that the PRECIS profile is used as a default
    > in the absence of other configuration knowledge for a given deployment,
    > though I acknowledge that this is not without flaws.
    
    I had discussed the PRECIS issue with Jim, which is what resulted in this text:
    
       It is recommended that the plain text password in the <loginSec:pw>
       and <loginSec:newPw> elements use printable ASCII characters #x20
       (space) - #x7E (~), with high entropy, such as 128 bits.  If non-
       ASCII characters are supported with the plain text password, then use
       a standard for passwords with international characters, such as the
       OpaqueString PRECIS profile in [RFC8265].
    
    I think that's adequate, given that (1) we really are expecting that
    almost all passwords out there are ASCII, and we're recommending
    keeping it that way, (2) we need to allow, but discourage, non-ASCII
    UTF-8 passwords for the (expectedly rare) cases where they might be
    used, and (3) these are stored passwords that are passed around,
    rather than passwords entered by users and subject to issues created
    by different input mechanisms and effects on eyeballs.
    
    I can see that we might want to change "recommended" to "RECOMMENDED",
    and I don't object to that (Jim?).  Beyond that, I'm not sure where
    you're going with "PRECIS profiles are to be used as part of a
    protocol as opposed to part of a deployment."  It's really both,
    depending upon the situation.  In this case, it's saying that if your
    server supports non-ASCII passwords, you'd better use the OpaqueString
    profile to handle them.  If your server doesn't (it supports only
    ASCII passwords), we're good.  From a PRECIS point of view, I don't
    see more that needs to be done with this.
    
    I think a large part of the point of the text that Jim added is an
    acknowledgement that in the common case of ASCII-only passwords, we
    don't have to worry about normalization/canonicalization of password
    strings at all, and just doing straight byte-string comparisons works.
    And the OpaqueString profile is there for cases where it's needed.
    
    Now, it's certainly true that if a server *supports* non-ASCII
    passwords, then *all* password processing on that server has to use
    the OpaqueString profile, even if there are not any actual non-ASCII
    passwords present... just in case one might show up.  And I think the
    text does say that.
    
    Is there something in this discussion that I'm missing that I need to
    address?  Is there specific text you might suggest?  Are there other
    issues beyond this one that are still open?  How close are we to
    resolving this?
    
    Barry