After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Simo Sorce simo at
Mon Nov 5 12:10:39 EST 2018

On Mon, 2018-11-05 at 10:04 -0600, Benjamin Kaduk wrote:
> On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:
> > Greg Hudson <ghudson at> writes:
> > 
> > > On 11/01/2018 10:30 AM, Weijun Wang wrote:
> > > > Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
> > > > there any plan to remove them from etype list of KDC-REQ?
> > > 
> > > For RC4, I would like Microsoft to take the lead.  3DES is our 
> > > responsibility, and is probably not in nearly as much use (although I'd 
> > > have to at least check if we're still using it internally at MIT), so it 
> > > is probably not as painful to deprecate.
> > > 
> > > There is some ambiguity in how weak an enctype needs to be to qualify 
> > > for being affected by allow_weak_crypto.  The primary concerns about 
> > > des3-cbc-sha1 are its 64-bit block size and the fast speed of its 
> > > string-to-key operation; both of these are far less problematic than the 
> > > practical ability to recover a random single-DES key.  It would also be 
> > > a shame if administrators wound up enabling DES in order to make DES3 
> > > work (or RC4).
> > 
> > Maybe we need an "allow_very_weak_crypto" in addition to the
> > "allow_weak_crypto"?
> Perhaps ... though what is keeping us from biting the bullet and just not
> exposing single-DES at all (forcing sites that need it to stay on an old
> software branch)?

This or we turn allow_weak_crypto from a boolean to a list of weak
algos you want to re-enable with the value "true" turned to a default

In general DES is something we should really drop for default builds
going forward, just like MD5, I do not think it is right for the
majority of people to be made so vulnerable just for a few holdouts.

Holdouts can simply recompile their library and add back all the broken
crypto they want, until we drop the code completely, at which point
they can add downstream patches if they really insist using a bleeding
edge release with ancient crypto (what's the point ?).


Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

More information about the krbdev mailing list