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

[Weijun Wang]

Hi Greg

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?

Maybe they will be covered by "allow_weak_crypto"?

Thanks
Max


_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Weijun Wang
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).
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Derek Atkins]

Post by Greg Hudson

Post by Weijun Wang
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"?

Post by Greg Hudson
https://mailman.mit.edu/mailman/listinfo/krbdev

-derek

[Benjamin Kaduk]

Post by Derek Atkins

Post by Greg Hudson

Post by Weijun Wang
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)?

-Ben
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

Post by Benjamin Kaduk

Post by Derek Atkins

Post by Greg Hudson

Post by Weijun Wang
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
list.

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.

[Robbie Harwood]

Post by Benjamin Kaduk

Post by Derek Atkins

Post by Greg Hudson

Post by Weijun Wang
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)?

I've started some of this work, but haven't looked at it in a while.
Among other things, srvtab and krb4 support need to go. I don't think
there should be any attachment to any of its dependencies of course,
just that it is more to do.

I would be very happy to see the single-DES code removed.

Thanks,
--Robbie