It was 6 before and apparently we "need" to upgrade to 8 now. I am quite sure than in 5 years we would want to increase 8 to 10 and so on, this is purely Moore's law.
So to ease future maintenance I am just saying: remove this arbitrary limit in the protocol, since it is a policy decision anyway. Are there any other thoughts on inclusion of a minimum of 8 characters for the password in draft-gould-regext-login-security versus specifying no minimum and leaving the minimum up to server policy? My preference is to meet the existing security guidelines by specifying the minimum of 8 characters and Patrick’s preference is to remove the minimum. Any other thoughts on this is greatly appreciated. Thanks, — JG James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/9/18, 2:26 AM, "Patrick Mevzek" <[email protected]> wrote: On Wed, Jun 6, 2018, at 15:02, Gould, James wrote: > JG - I don't view the 8 minimum as a "sacred cow" that would require the > next iteration of the extension to increase it. It was 6 before and apparently we "need" to upgrade to 8 now. I am quite sure than in 5 years we would want to increase 8 to 10 and so on, this is purely Moore's law. So to ease future maintenance I am just saying: remove this arbitrary limit in the protocol, since it is a policy decision anyway. > but I don't believe that it makes sense to not > at least define the minimum to meet the existing security guidelines. For me defining a minimum has no sense if you do not define the space of possible passwords (which characers) and even various other constraints you may place (like no repeating character, or at least one uppercase, etc.) For the sake of it, imagine the space of allowed characters are digits. Do you think the security would be increased in any way going from a length of 6 to a length of 8 digits? > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 > and 8265. Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN version which is basically what we have currently) : this allows to decouple authentication needs to the underlying application/protocol, which also address Pieter remark about other ways to authenticate. This would of course imply bigger changes and deeper ones, but for extended features also. I note in passing that there was always a way to extend authorization mechanisms in EPP, for the domain:auth element. I have never seen however any extension proposing there anything different. -- Patrick Mevzek _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
