Mechanism table update (for now, doc only proposal)#602
Open
vanrein wants to merge 4 commits intocyrusimap:masterfrom
Open
Mechanism table update (for now, doc only proposal)#602vanrein wants to merge 4 commits intocyrusimap:masterfrom
vanrein wants to merge 4 commits intocyrusimap:masterfrom
Conversation
- It's not about encryption anymore in SASL - Barely any mechanisms actually provide encryption
- Set to 10 for all that only depend on password quality - Set to 50 for SCRAM, which imposes a lot of work on brute force - Perhaps need to distinguish salting, rainbow tables in a column? - Much of this is subjective and could lead to long discussion - The old values had many flaws associated with them - The idea is mostly to get *closer* to the reality of today
Author
|
This may lead to some discussion, once the storm settles let me know and I can dive into the code to update SSF there too. |
Contributor
|
Please update your commit(s) to be signed off on in accordance with our DCO. Thanks! |
Author
|
I'm not sure what you are asking, or what "our DCO" means. |
Contributor
Developer Certificate of Origin: https://developercertificate.org/ Generally, you need to add a "signed off" field to your commit (git commit -s --amend is generally sufficient) and then re-push your commit. |
Contributor
|
Reminder that this still needs sign off in accordance with the dco to be considered. |
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In a few steps, I've revised the table of authentication mechanisms. This table was long overdue for such an update, I think.
I added columns for Post Quantum protection (which is not an issue for authentication until Quantum Computers actually arrive, unlike for encryption, but systems change slowly so this is a useful aspect to document).
I added a column for the current state according to the IANA registry of SASL mechanism names.
I could not find anything on G2, and am wondering if it might be a misspelled GS2 name?
I have removed the remark about encryption from MAX SSF, as this is not considered of value in SASL anymore; it is mostly about authentication not encryption. I updated the description to reference brute-force search space instead, and added a value for low password quality and many-rounds effort on low password quality. The term MAX SSF might suggest that the password quality can be 128 bit, however, which is one of many ways in which the whole MAX SSF notion is confusing and perhaps disinformation.
I edited the MAX SSF column, and am well aware that it is subjective. Still, it did not reflect reality at all -- Kerberos5 has long deprecated DES, EXTERNAL is usually based on strong crypto, and so on.
I tried to make separately rejectable/acceptable commits out of this. Please use that when you (dis)agree with (parts of) this proposal. Any of these updates would improve the table, IMHO.