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

[Benjamin Kaduk <[e-mail]>]

I don't remember any other changes that would need to be in the -10
offhand, though the thread has branched a lot so I could have missed
something that we talked about early on.  (IIRC we ended up concluding that
we don't need to explicitly recommend that the updated server reject a
literal password of "[LOGIN-SECURITY]" in the absence of a <loginSec:newPw>
element, since it's fairly obvious; similarly, a current/unmodified client
has to be prepared for the server to reject that password and so would not
need to update its behavior.)

If you can't remember/find any other changes, go ahead and upload the -10
and I should be able to clear.

Thanks,

Ben

On Tue, Feb 25, 2020 at 04:33:04PM +0000, Gould, James wrote:
> Ben,
> 
> I believe I found the topic and the proposed text associated with identifying the nature of the need, which is outlined below.  I propose adding the sentence " EPP [RFC 5730] includes a maximum password length of 16 characters that inhibits implementing stronger password security policies with higher entropy." as the second sentence of the introduction.  This can be added to draft-ietf-regext-login-security-10.  Do you agree with this change?  Are there any other changes that are needed prior to the posting of draft-ietf-regext-login-security-10?
> 
>     Thanks for pointing to the list discussion of potential alternative
>     authentication approaches, and I'll see if I can make time to write
>     something down.  I'm not opposed to publishing an evolutionary improvement
>     while revolutionary changes are immature, but I do think that the document
>     should be more explicit about the nature of the need.  Yes, artificial
>     password-length limitations are bad and I'm happy to see this work to
>     remove them from EPP, but are there particular security deployment
>     considerations driving this, such as a desire to support memorable
>     passphrases that contain sufficent entropy?  From a purely
>     information-theoretic perspective, if we limit ourselves to the ASCII
>     alphabet from 0x20 to 0x7e, 16 charcters gives roughly 104 bits of entropy
>     available, which is not catastrophically bad; in combination with the
>     prerequirement for TLS client-certificate authentication, a server could
>     block or rate-limit brute-force guessing attacks and achieve a level of
>     security that is reasonable for many if not most web-available services
>     today.  Even if the perceived need is just "artificial limitations on
>     password length are detrimental to future evolution in security practice"
>     (which seems unlikely to me based on my bayesian prior), it seems worth
>     saying.  I suspect that there's more motivation in play, and would like to
>     better understand it.
>  
> JG2 - The only deployment consideration is being able to set passwords beyond the 16 character limit of RFC 5730 for the critical domain name registry systems.  Yes, there is multi-factor authentication with EPP (user name/password and client certificate, and optionally client IP address), but there is the operational need to enhance the security of the passwords with longer lengths and higher entropy (e.g., at least 128 bits).  Are you looking for a sentence being added to the introduction that identifies the problem more explicitly, such as:
>  
> EPP [RFC 5730] includes a maximum password length of 16 characters that inhibits implementing stronger password security policies with higher entropy.
> 
> -- 
>  
> 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/24/20, 6:02 PM, "Benjamin Kaduk" <[e-mail]> wrote:
> 
>     This text regarding internationalization/normalization works for me.
>     
>     Looking at the diff from -07 to -09, we seem in pretty good shape overall;
>     were we going to add a note to abstract and/or introduction about "this
>     extension allows for the use of strong passwords with EPP"?  (I think Jim
>     had proposed actual text at some point that's better than my paraphrased
>     version here.)
>     
>     -Ben
>     
>     On Mon, Feb 24, 2020 at 07:43:47AM -0800, Barry Leiba wrote:
>     > Great; thanks, Jim.  Ben, are you OK with this now?
>     > 
>     > Barry
>     > 
>     > On Mon, Feb 24, 2020 at 5:28 AM Gould, James <[e-mail]> wrote:
>     > >
>     > > Barry & Ben,
>     > >
>     > > Thanks for the detailed discussion.  I will change the "recommended" to the normative "RECOMMENDED" and change the PRECIS sentence to match Ben's proposal.  The end result will be:
>     > >
>     > > 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; the OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of other considerations.
>     > >
>     > > I'll include this change in the posting of draft-ietf-regext-login-security-09.
>     > >
>     > > 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/22/20, 6:15 PM, "Barry Leiba" <[e-mail]> wrote:
>     > >
>     > >     Thanks, Ben; this helps a lot.
>     > >
>     > >     Jim, are you good with Ben's suggestion or a variation of that?  It's
>     > >     just a small update to what you have, and makes it clearer that if you
>     > >     need I18N, PRECIS is the weay to do it.
>     > >
>     > >     Barry
>     > >
>     > >     On Fri, Feb 21, 2020 at 10:08 PM Benjamin Kaduk <[e-mail]> wrote:
>     > >     >
>     > >     > Hi Barry,
>     > >     >
>     > >     > On Sat, Feb 15, 2020 at 12:12:29AM -0500, Barry Leiba 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.
>     > >     >
>     > >     > I sympathize; I find that with some regularity I end up saving the
>     > >     > text/html component to a file and opening it in a browser in order to have
>     > >     > a chance of figuring out what's going on.
>     > >     >
>     > >     > > 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
>     > >     >
>     > >     > I'm much happier with your prose description here than the snippet quoted
>     > >     > from the document -- what's in the document now seems to be weaker than
>     > >     > what you say ("pick a standard; PRECIS is a standard" vs "you should use
>     > >     > PRECIS, though here's an out if you can't for some reason").
>     > >     >
>     > >     > My primary concern here is that the client and server need to know to use
>     > >     > the same standard (whatever it is).  Making this RFC say flatly "use
>     > >     > PRECIS" is IMO the easiest way to do that, though given how much other
>     > >     > stuff in EPP has to be set by out-of-band configuration I won't raise a
>     > >     > fuss if this ends up being another one.  If it does need to be known out of
>     > >     > band, though, my preference is always for that need to be stated in the
>     > >     > RFC.
>     > >     >
>     > >     > > 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.
>     > >     >
>     > >     > (repeating myself, but I think the text says "all password processing on
>     > >     > that server has to use the chosen standard for non-ASCII passwords" [which
>     > >     > is not necessarily the OpaqueString PRECIS profile])
>     > >     >
>     > >     > > 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?
>     > >     >
>     > >     > I think just adding the extra background and your sense of what the text is
>     > >     > trying to convey has been a big help.  I would suggest rewording to:
>     > >     >
>     > >     >   [...].  If non-
>     > >     >   ASCII characters are supported with the plain text password, then use
>     > >     >   a standard for passwords with international characters; the
>     > >     >   OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of
>     > >     >   other considerations.
>     > >     >
>     > >     > Your explanation suffices such that I will not require this change to clear
>     > >     > my Discuss, though.
>     > >     >
>     > >     > -Ben
>     > >
>     > >
>     
>