>>>>> "BC" == Ben Cotton <bcotton@xxxxxxxxxx> writes: BC> == Detailed Description == [elided] Is it just me or does this not actually say clearly what is changing? The first paragraph talks about two RFCs. The second paragraph talks about how easy it is to break single DES. The third paragraph talks about how disabled by default is undesirable. The fourth paragraph talks about it not being possible to remove RC4. But nothing says what is changing. The release notes section says: BC> krb5 removes support for several known-bad encryption types. BC> Hopefully users will see no changes. but it doesn't really say what "removes support" means, or exactly which encryption types will no longer be supported. BC> == User Experience == BC> Ideally no change! Worst case some users will see krb5 produce BC> error messages about bad enctypes not being able to be used (has no BC> enctype, could not fullfill enctype, etc.). These pains are the BC> feeling of the world grinding forward security-wise. I think this is an extremely optimistic description of the worst case behavior. There is a good document for migrating from old encryption types at https://web.mit.edu/kerberos/krb5-1.16/doc/admin/advanced/retiring-des.html Note that the last paragraph there mentions that single-DES is still basically OK for the K/M principal and it's not required to use allow_weak_crypto to access a database encrypted with single-DES. I can't tell if this change actually intends to remove all support for the single-DES algorithm, but if so then it is highly important to communicate the additional need to roll over the master key and stash files. It would also be nice to document a way to find principals which do not have a sufficiently strong key. I personally have a kerberos database which has existed for a very long time now and am still dealing with the 3DES deprecation (and the fact that the F29 crypto policies changed to remove it from supported_enctypes). - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
