John C Klensin wrote: [skipping many good points] > I am very much in favor of high specification quality. [...] > we should aspire to specifications that are absolutely clear > about their strengths and weaknesses _especially_ where > security and basic network operations (e.g., scalability) are > concerned. Yes, e.g. STD 61 (2289, OTP) is ready in some way, and somebody cared to submit an implementation report. For the new SASL I've not heard that anybody intends to SASLprep 2444. Whatever that means, if used instead of CRAM-MD5 it wouldn't be _that_ much better wrt the dictionary attack discussed here before. For a CRAM-MD5 "AS" it boils down to "if all you want is not sending passwords in the clear you could ... BUT ...". One detail I like about OTP and CRAM-MD5 is that they need only 3 parameters where 2831 takes 9 or 10. A future 2026bis could make it clearer that anybody may submit an implementation / interoperability report, not only the original authors / editors. BTW, RFC 4234 to STD, anybody ? And of course RFC 4409 to STD, there I'd prefer to explicitly mention the Resent-* case in its section 8.1, and that would need a minor editorial update (+ a new informative reference). And if anybody insists on it add a caveat about CRAM-MD5 etc. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf