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

[Barry Leiba <[e-mail]>]

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