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 > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 2/24/20, 6:02 PM, "Benjamin Kaduk" <[email protected]> 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 <[email protected]> > 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 > > > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > > > > > 703-948-3271 > > > 12061 Bluemont Way > > > Reston, VA 20190 > > > > > > Verisign.com <http://verisigninc.com/> > > > > > > On 2/22/20, 6:15 PM, "Barry Leiba" <[email protected]> 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 <[email protected]> > 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 > > > > > > > > _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
