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. 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. 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. 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. 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? Barry _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
