Re: F30 Self-Contained Change proposal: krb5 crypto modernization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jason L Tibbitts III <tibbs@xxxxxxxxxxx> writes:

>>>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes:
>>>
>>> Well certainly there isn't much you can do to fix old principals on
>>> existing systems.  But the current versions should be complaining
>>> loudly when it has to issue a ticket for a principal that lacks a
>>> modern enctype today, if not six months ago.
>
> RH> For folks running KDCs, we do have existing logging.
>
> The problem is that the principal in question hasn't been touched in
> twelve years (which I guess you can see from the list of etypes.)  That
> coupled with the change (which I don't think was your doing) to
> /etc/crypto-policies/back-ends/krb5.config to remove des3-cbc-sha1
> caused the KDC to fail to issue those tickets.

Ah, I see, you're talking about the case when the enctype is already not
permitted.  That all makes sense then.

> RH> I don't think that putting more messages in here would be useful,
> RH> but I could be persuaded otherwise.
>
> Doesn't technically have to be more messages, even adding more
> information to the existing message would help.  Adding ", Only
> deprecated etypes issued" to the end of the ISSUE lines would sort of be
> in keeping with the existing format.
>
> But really, whether it's in something that gets logged or some separate
> tool I can run or something, it would just be nice to have some
> established procedure to know that that you're going to be hit by
> expiring crypto before you actually get hit by it.

This is good feedback, thanks.  My plan is to try for an external "realm
check" type tool - but I need to make it first :)

>>> Of course, if I'm reading that wrong and this is merely an effect of
>>> moving to version 1.18 then.... the current devel documentation
>>> doesn't seem to say much about deprecation of additional algorithms.
>>> Which I know doesn't mean much, but given how kerberos development
>>> progresses, I would have expected the complete removal of an
>>> encryption type to be telegraphed years in advance.
>
> RH> Arguably, we telegraphed single-DES removal in 2009 (and there have
> RH> been two RFCs about this that I cited), but you're right that
> RH> Kerberos has never been a "move fast and deprecate things" kind of
> RH> situation.
>
> Yes, single-DES removal has been yelled about loudly for a long time.
> There's a section in every release announcement about it.  But isn't the
> current proposal about removing more than just 1DES?

It may help understanding my motivations here to know that upstream
won't consider removal until some distro has done so and they have a
sense of what it entails.  Until then, it's a bit Catch-22: no one wants
to divert from upstream and upstream doesn't want to break
downstreams...  We've yet to remove anything of import from any Kerberos
implementation; MIT still includes Kerberos4 support, for instance.

The MIT-specific telegraphing is single-DES specific.  The RFCs (which
also include RC4 and 3DES) are applicable to the entire ecosystem.  But
ignoring all that, fundamentally I don't want to do this same process
three times - and I can't imagine admins do, either.  Which is to say: I
think that the only telegraphing I can meaningfully do is administrative
(RFCs, release notes, change proposals, etc.), and then try to smooth
the roadbumps.

Thanks,
--Robbie

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux