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
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.
Ietf mailing list