A couple of notes: I have no earthly idea why one would propose a protocol, TLS, for a function such as this. I wouldn't imagine that TLS would be fit for purpose in this use case.
The question is how to generate bits in a way that is only known to the two endpoints, and do that fast enough to provide a reasonably unguessable value to shove into packets. Classically, a stream cipher (AES in OFB mode for example) is much faster than normal block cipher modes (the normal AES GCM). If the CPUs in question have the AES standard cell in hardware, it should be fast and require less implementation to get wrong. CHA-CHA is also a stream cipher, but it is normally implemented in S/W, so I'm not sure how fast it is. If there is an instance of using ISAAC in this use case, there will be gigantic warnings about how this is NOT a general purpose option. I'm not a fan, nor is any other Sec AD I've ever met, of picking an algorithm out of the blue and using it without evaluation, no matter how old it is. Before I answer the other comments, I have some homework to do (where does RFC5880 get/generate/negotiate keys since apparently I read something wrong). Deb On Wed, Sep 17, 2025 at 3:43 PM Alan DeKok <[email protected]> wrote: > On Sep 17, 2025, at 10:29 AM, Jeffrey Haas <[email protected]> wrote: > > Note that I'll be letting the other authors comment on the majority of > the security claims about ISAAC. Here's a few comments on the procedural > usage of the mechanism with BFD. > > Given the limited use-case and security requirements for this, I think > we shouldn't get into the details of ISAAC. The discussion has circled > around a few related topics, which have come up repeatedly. > > We can instead take a step back, and the question of whether we want to > do this at all. > > i.e. Is this approach so terrible that the IESG pushes back, and says > "not approved, do something else"? > > Or, is this approach ugly but "good enough", and therefore can be > published with an IESG note of "here be dragons" ? > > > The conversation point becomes whether the mechanism has, or does not > have, hardware support between the two systems and what the amortized cost > of generating N outputs is within a constrained time window to keep the > protocol running at speed. Seeing such a comparison would be interesting. > > Any design is strongly limited by the low resources available. Any real > security such as TLS is therefore out of scope here. > > Since TLS is out of scope, then the questions for this document fall > back to the ones I posed above. > > Alan DeKok. > >
