> BC> == Detailed Description == > > > 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. Per your follow-up email, I'm not clear on whether you want changes here. If you do, speak up, especially if you have suggestions. > 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. I really don't think that "it won't work and there'll be error messages" is an "extremely optimistic description". If you have langauge changes, I'm happy to hear them out. > 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. That reading only applies to sites with a stash file nearby (though sites set up otherwise remain relatively uncommon in my impression, or are freeipa and will have AES keys). > 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. Session keys for sure, but ideally all of it. I tried to state this in the Summary; if I was insufficiently clear I'm happy to make changes! (Added rollover langauge to "Upgrade/Compatability Impact" section.) > It would also be nice to document a way to find principals which do not > have a sufficiently strong key. This is good feedback. I will explore and see if I can make something. > 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). I'm sure you're aware, then, that there's only so much I can do as a packager here. In particular, the KDC can't push keytab updates (because servers with keytabs are not required to be able to communicate with the KDC). The UX on this is *going* to be bad for anyone with weak crypto in use - which is part of why I want to pull it all out at once, so we don't have to do this again for a while. Please CC me on all future mails; I'm not subscribed to this list. Thanks, --Robbie _______________________________________________ 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
