Barry, Thanks again for reviewing the responses. I provide my responses below on the "verify randomness" item.
-- JG James Gould Fellow 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 1/28/21, 11:48 AM, "Barry Leiba" <[email protected]> wrote: Thanks, Jim. We're good on everything except the "verify randomness" stuff, so let's just talk about that one a little more. >> — Section 5.2 — >> >> The registry SHOULD validate >> the randomness of the authorization information based on the length >> and character set required by the registry. For example, a registry >> that requires 20 random printable ASCII characters except space >> (0x20), should validate that the authorization information contains >> at least one upper case alpha character, one lower case alpha >> character, and one non-alpha numeric character. If the authorization >> information fails the randomness validation, the registry MUST return >> an EPP error result code of 2202. >> >> Oof! >> Random is random, and if we’re looking for a 12-character string >> “eobphbevwjcg” is as “random” as “eoB$hbevwjcg” is. I’m not happy >> with forcing password strings to pass arbitrary and very dubious >> randomness tests, especially with a “MUST reject with an error” >> requirement, and it’s likely that a good, randomly generated password >> will fail this test. You already have requirements here for >> generating strong passwords. And in reality, you can’t stop >> implementations from generating crappy passwords that all happen to >> begin with “Aa@“ if that’s what they want to do. I don’t mind a >> non-normative statement that such checks might be performed, as an >> alert to existing implementation situations. But making it a >> normative requirement doesn’t seem right. >> >> (And apart from that, it seems strange to say SHOULD validate… and >> then MUST reject, which I won’t do if I didn’t validate in the first >> place.) > > JG - Since the authorization information is generated by a system and > not by a user, it's important for the server to validate that it is > random, which is why it's defined using a normative SHOULD. Use of > randomized authorization information passwords is key to the approach, > and a basic randomization check can and should be done by the server. > The reason for the SHOULD and MUST pattern is to make the check a > recommendation with a SHOULD, and if a randomness check is implemented > it's assumed that an error will be returned and that result code MUST > be 2202 and not some other result code. The MUST is associated the > choice of the result code and not whether or not to return an error, > where I can't think of a scenario where a server would not return an > error if the randomization check is implemented and fails. I believe > the SHOULD and MUST are applicable and needed in the draft. First, I question the premise that "it's important for the server to validate that it is random": the specification says that it MUST be random, and gives additional guidance for making that happen. I disagree that it's important, or even desirable to attempt to confirm that, and I don't believe it's even possible to do such validation meningfully. JG - The random generated authinfo password is a requirement for the client in implementing the draft, but I believe that it's important for the server to do some level of validation that the client is randomly generating the password to meet the security elements of the practice. The server can do basic validation based on the length of the password, the chosen character set, and math. If the password is 20 or 25 characters based on the different character sets defined in the draft to meet the 128 bits of entropy, the server can validate that characters in different character groups (at least one lowercase letter, at least on uppercase letter, at least one number, at least one special character) using probability. What is the probability that a randomly generated password of 20 character contain all lowercase characters? The draft doesn't define the method for servers to use, but providing some level of validation is warranted. Second, I don't believe that the validation mechanism proposed works, and I contend that it's not reasonable. As I say, it's entirely possible for a properly created random password to fail the checks that are proposed here. JG - I believe that some basic validations is possible using the chosen character set, password length, character groups and probability. Third, I passed this by Ben Kaduk, and he agrees... so I would expect to get pushback from the Sec ADs on this point if it goes forward like this. JG - I would like to understand why from a security perspective recommending for the server to do validation that the client is using a random password is an issue. I view it as an important security element, where some basic validation can be done safely with a low probably of failure. If there were truly a reasonable way to do a randomness check, I would be in favour of it. It's not, because if you ask me to select a random five-digit number, "12345" is just as likely to come up as "39186", and just because my program generated "12345" doesn't mean it's broken. JG - The approach is to look at groups of characters existing in the generated password based on the length and the character set chosen. Let's say you decide to have a 5 digit password, what is the probability that the random password contains the digit 1? The probability is (1 - ((10 - 1)/10)^5) = 40.9%. How about the probability that the random generated password contains either a digit 1 or 2, (1 - ((10 - 2)/10)^5) = 67.2%. If you increase the length and adjust the character group, the probability will greatly increase. Let's get to a larger character set and length based on the entropy calculations in the draft. What is the probability that a 25 character randomly generated password with a 36 character set (a-z A-Z 0-9) contains at least one digit (0-9). That would be (1 - ((36 - 10)/36)^25) = 99.97%. The server can also look at the sequence of characters to validate randomness. The point is that it is possible using the password policies and probability to implement some level of randomness validation in the server. It's not a MUST in the draft but a SHOULD to recommend that the server should do some level of validation. Would you like us to add Ben and Roman to the discussion, so that we get their thoughts and suggestions now, rather than waiting for the formal IESG Evaluation? If you feel that it would help out, I support bringing them in. Barry _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
