On Sep 17, 2025, at 10:29 AM, Jeffrey Haas <jh...@pfrc.org> 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.
