Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mechanism table update (for now, doc only proposal) #602

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

vanrein
Copy link

@vanrein vanrein commented Mar 25, 2020

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.

vanrein added 4 commits March 25, 2020 07:25
 - 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
@vanrein
Copy link
Author

vanrein commented Mar 25, 2020

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.

@quanah
Copy link
Contributor

quanah commented May 5, 2021

Please update your commit(s) to be signed off on in accordance with our DCO. Thanks!

@vanrein
Copy link
Author

vanrein commented May 6, 2021

I'm not sure what you are asking, or what "our DCO" means.

@quanah
Copy link
Contributor

quanah commented May 6, 2021

I'm not sure what you are asking, or what "our DCO" means.

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.

@quanah
Copy link
Contributor

quanah commented Oct 5, 2021

Reminder that this still needs sign off in accordance with the dco to be considered.

@quanah quanah added the reviewed reviewed in triage label Oct 5, 2021
@Neustradamus
Copy link
Contributor

@vanrein: Have you seen the @quanah comment?

"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."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
reviewed reviewed in triage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants