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.
2) SASL2 still exists on the paper only without wide adoption.
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?
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?
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 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]
_______________________________________________
