On Fri, 25 Jan 2019 at 12:08, Evgeny <[email protected]> wrote: > On Fri, Jan 25, 2019 at 1:45 PM, Dave Cridland <[email protected]> > wrote: > > I'm hearing "no", here - which is fine - but I do have a design for > > enforced password changes and password resets, too. The former is > > built around SASL2 (XEP-0388) and was actually one of the original > > design goals. Password resets we built at Surevine as a SASL > > mechanism (which we used with SASL2, but it'd work with the existing > > SASL profile in RFC 6120 as well). > > 1) I already criticized SASL2 back then for unnecessary complexity. >
Yes, although I admit that when everything is criticised for unnecessary complexity it can become quite difficult to figure out what's a genuine complaint. This isn't just you, by the way - literally everything we try to do gets criticised on that basis. I found it relatively straightforward to implement, and moreover, adjusted the spec to match that. > 2) SASL2 still exists on the paper only without wide adoption. > Certainly it doesn't have wide adoption, but it has some. > 3) I'm not sure every operator will be fine with the solution to force > users changing passwords. I use a lot of services and I'm having hard > time remembering any service doing this so far. Should we ignore this > common practice? > I'm merely offering suggestions. I'm in full agreement that enforcing password changes is not a solution for many use cases. > 4) What about situation with -PLUS variants? What's the answer to above > Daniel's question related to TLSv1.3? Will we have problems with > TLSv1.4? > -PLUS variants are problematic on a number of environments because the necessary data isn't available. However, where available, tls-unique as written is *still* significantly better than no -PLUS at all, and requires a substantial effort to attack. > 4) I actually described several problems with SCRAM, and I did that for > a reason, but seems like only those related to SHA upgrades are > addressed (on the paper only BTW). What about potential downgrade > attacks (including false positives)? Is it clear for all developers? > For example, for me it's not that obvious what exactly to treat as a > downgrade attack. What about interop with other services? What about > performance degradation when SASL PLAIN is used with SCRAM'ed > passwords? We already have "avalanche problem" caused by server > restarts, and SASL PLAIN + SCRAM'ed passwords only worsen it. Also, if > an attacker harvests enough JIDs it may successfully perform DDoS > against the server forcing it to compute HMACs at a high rate. > > I'm not clear what you mean by "potential downgrade attacks (including false positives)". I think Sam addresses your comments about performance in much the same way I would. > >> I personally prefer: > >> 1) MUST for EXTERNAL and PLAIN > >> 2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all > >> given all the problems I have described in another thread) > > > > I'm hearing "yes" here, however. > > > > Would you be interested in updating the MTI? > > No. I don't have neither time nor desire to fiddle with IETF > bureaucracy. Furthermore, that's not me who put SCRAM in the RFC. Also, > we require SCRAM-SHA1-PLUS for years now, but still not every server or > client implement it (typically only SCRAM-SHA1 is implemented). And > seems like nobody gives a f*** for the RFC requirement. For me simple > wiki page with clarifications and provided solutions is enough. > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
