Dave, Better do this quickly, cleanly and with minimum wiggle room. Otherwise, somebody who doesn't know anything will call it a security flaw, call the CERT and create an Incident. This has happened before when somebody claimed a stack vulnerability which in fact was true in a most unlikely case. Although the reporter submitted a script allegedly proving this could occur, the script was defective and nobody was able to verify it. I'd like this not to happen again.
My point being, fix the bug, put in a conditional to temporarily revert to past behavior and leave it be. Dave Hart wrote: >On Fri, Sep 11, 2009 at 1:37 PM, Ryan Malayter wrote: > > >>I don't use autokey in production, but I would also suggest that if >>the issue causes the reference implementation to violate RFCs and also >>creates a security issue with key shortening, it should be fixed >>without any options to go back to the bad behavior. Actually, the >>security issue might in fact be major, if the a zero is randomly >>generated in the first few bytes of the key, correct? >> >> > >Incorrect. While the behavior violates the Autokey spec, I doubt >there is any security issue. The session keys are each used once, in >a sequence that is predictable only to the two parties involved, >thanks to a seed securely negotiated using a higher level of Autokey, >and to using the generated key list backwards. Shortened individual >session keys can not be reused even if correctly guessed by a 3rd >party listener. The session keys are used to sign traffic, not >encrypt it, FYI. > > > >>Please don't take the Microsoft route, where praying to the altar of >>backwards compatibility means you are stuck with ugly hacks for >>decades. >> >> >[...] > >Even if a runtime workaround were used to allow a single ntpd to >Autokey with both corrected and uncorrected ntpd peers simultaneously, >the "ugly hack" would not mean ntpd is stuck with it -- unless you >intend to use Autokey with uncorrected ntpd forever. The workaround >could be disabled from the start, even when enabled was used only when >necessary. Even when it was used with a configured peer, where ntpd >remembered that the peer needed shortened session keys, it would be >disabled on receipt of the first traffic signed by a complete key >subject to shortening, meaning the remote ntpd could be upgraded to a >corrected version while the local one stayed up without perpetuating >workaround's use any more than necessary. > >It seems likely the runtime workaround will not be in ntpd because the >added complexity is not worth the benefit. Instead, a configure knob >will allow building a new ntpd with the old behavior. It may never be >used, and as with the runtime workaround option, it can be excised at >any time -- there is no reason ntpd would be stuck with it. > >Cheers, >Dave Hart > >Cheers, >Dave Hart > >_______________________________________________ >questions mailing list >questions@lists.ntp.org >https://lists.ntp.org/mailman/listinfo/questions > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
