If ISAAC is indeed quick enough, as it is basically just a different stream cipher (i.e. RC4) than the one I suggested. It has been asserted to be, but since there are no implementations, are you sure? [the case you presented stated that AES256 was too slow, but apparently AES128 is not.]
The only other sticking point is reuse of the Secret Key for both ISAAC and the key hashes. Technically, this makes the keyed hashes less robust. Extraction of a Secret Key from ISAAC compromises the keyed hash versions. If ISAAC is literally the only stream cipher that is quick enough, then I'm happy to help construct words to dissuade any other use of that algorithm for other purposes. Deb On Mon, Sep 29, 2025 at 8:11 AM Jeffrey Haas <jh...@pfrc.org> wrote: > [Note, I'm back from travel and should be able to close out many dangling > threads early this week. One quick response to move a critical bit of the > conversation forward.] > > On Sep 29, 2025, at 7:14 AM, Deb Cooley <debcool...@gmail.com> wrote: > For any ISAAC comments, I'm waiting for Alan to confirm with some authority > that the line cards do not have AES in hardware. > > > Which line cards? At what forwarding rate? With or without acceleration? > > He can't confirm that because there exist network processors that have > in-line AES implementation. I even provided one example of a vendor ticket > about such built-in implementations being slow, although that NPU was > chosen for a lower end device. > > Which really is why we're even having this conversation. > > Encryption burns CPU. This isn't a surprise to anyone. In many > circumstances, it's been optimized to be an on-chip behavior that minimizes > its cost vs. a software-based implementation. When such things exist, > great! For mechanisms where we can take a shared secret and say "go > 'sign' this", the entirety of the implementation complexity for BFD will be > to allocate a code point and describe any caveats leveraging that mechanism > requires - such as key length and how long of an authentication field is > needed in the PDU for that code point. > > However, once you push the strength of a given mechanism to a certain > point, or ask for something without acceleration, it's not going to scale. > The optimized draft at least lets us get the protocol out of the business > of needing to use strong cryptography that doesn't scale on every single > packet. But, it only works if we have something "good enough" for the rest. > > This brings us to your other point here: > > Also to point out that > while one can use a bespoke algorithm like ISAAC, one can also use a stream > cipher (or a block cipher in stream mode - i.e. AES in OFB mode) for the > same purpose. > > > In the presence of locally scalable other mechanisms, we could use that > too. For the procedures for optimized BFD, we'd allocate new pair-wise > code points for strong mechanism plus the new less strong mechanism - AES > in the above case. > > Will AES scale similar to ISAAC without acceleration? If not, are you > telling us you're willing to only advance the spec with a profile that > requires a hardware accelerated mechanism? If so, we're possibly back to a > different form of the original problem and we should just end this effort > and let it rot. As I mentioned, IETF telling hardware engineers "stronger > crypto here" will results in implementers to tell IETF to pound sand in > many circumstances when hardware acceleration doesn't exist - or is too > expensive to use when it does. > > This isn't to try to convince you to change your mind on the other portion > of the work that needs security diligence. If you're unconvinced that > ISAAC meets the "good enough" criteria even with the periodic > re-authentication mechanism in the optimization mechanism, I understand not > wanting to put any sort of IETF seal of approval on it. > > For my part, closing out the lingering threads is intended to instead try > to convince the IESG that we had gone down the path for this optimized > mechanism with NO encryption involved (no authentication, and the new NULL > authentication were evaluated) and that we're not looking for any deep > claim of cryptographic strength for the Up packets that don't require > strong authentication. More later. > > > -- Jeff > > > > > Deb > > On Wed, Sep 17, 2025 at 10:29 AM Jeffrey Haas <jh...@pfrc.org> wrote: > > Deb, thanks for your review. > > 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. > > > On Sep 17, 2025, at 8:59 AM, Deb Cooley via Datatracker < > > nore...@ietf.org> wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Discuss: A discuss is merely the start of a conversation. The > > terseness of > > this review reflects on my history (37 years as a security evaluator). I > believe it is possible to get this draft to publication, but it will > > take real > > work (I'm happy to help). This is a list of the areas that I believe are > > poorly > > specified: > > 1. operating situation: Fast networks speeds combined with > > inadequate > > CPU capability will drive the solution which is practical. Please > explain this. > > > Note that this completely overlaps with the similar discuss on the > optimizing bfd draft. We'll want to choose a single set of text for both > sets of documents. > > > [DC] indeed. And this is a fine suggestion. > > > 3. key management: There is very little information in this > > draft > > that outlines how various keys (per party Secret keys, per session > seeds, initial sequence numbers) are handled. This includes > generation, distribution, storage, and removal. While there are > > many > > references to a 'cryptographically strong pseudo-number > > generator', it > > is never defined. The test data in Section 10 apparently > > encourages > > operators to use a password as a Secret Key without any further > processing (no pbkdf required, apparently). There is no mention > > in the > > Security Considerations to caution the implementer on what care > > needs > > to be taken with respect to these values, and their handling. > > > Partially discussed in the other document, but pre-shared secrets are the > common practice for the majority of IETF routing protocols. I'd suggest we > find text that makes you and the other security reviewers satisfied that's > what we're saying is done. Anything beyond that is overreach. > > > [DC] happy to help with these words. > > > Discussion of the BFD security properties for the protocol's > discriminators is covered in RFC 5880's security considerations. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Section 4.1, sequence number and Section 6, para 1: It is unclear to me > > how an > > unprotected sequence number prevents a replay attack. Certainly the > > attacker > > can change the sequence number, or replay a packet with a modified > > sequence > > number. The only protection against replay attacks for this system is > > via the > > Auth Key. The sequence number is merely helpful for the recipient to > > attempt > > to determine the place on the table (and that only works if the packet > > hasn't > > been replayed). > > > You're correct that in respect to the ISAAC portion of the mechanism that > it's used for the index operation into the generated ISAAC output for > validation. > > From section 6: > "The receiving system accepts the packet if the key ID matches one of the > configured Keys, and the Auth Key derived from the selected Key, Seed, and > Sequence Number matches the Auth Key carried in the packet, and the > sequence number is strictly greater than the last sequence number received > (modulo wrap at 2^32)." > > also: > > "If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For > Meticulous keyed ISAAC, if the sequence number lies outside of the range of > bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated > as an unsigned 32-bit circular number space) the received packet MUST be > discarded." > > The first citation is a requirement for the sequence number to be > monotonically increasing when accepted. > > The second citation provides for a limited window under which a packet > could be accepted. It requires the implementation to only accept at least > the next sequence number (with the expectation that sequence numbers are > meticulously increasing by one on each packet sent) and tolerates packet > loss within a window under which the protocol will stay in the Up state and > not take the session down due to packet loss. > > Together, this means replays of prior valid packets are not considered > valid Up packets for purposes of keeping the session in the Up state when > it might otherwise be in a different state. > > This is in contrast with non-meticulous modes in RFC 5880 wherein > duplicate sequence numbers are permitted to keep the session in the Up > state. > > > [DC] right, so replay is not merely the inclusion of a sequence number. > Especially one that isn't hashed. > > > Section 4.2 and 4.3: These sections are merely repeats of sections in > draft-ietf-bfd-optimizing-authentication? > > > (Deep breath. Of course this was going to come up.) > > Not quite. > > While it's correct that the draft-ietf-bfd-optimizing-authentication-33 §7 > Figure 1 is present, the differentiator for each section is the contents of > the Auth Key/Digest field. > > If one were to observe "this seems highly redundant, just say that you're > putting that data in this portion of the common header"... that's what we > had. And were strongly encouraged to make it crystal clear what goes in > the entire authentication section and not just the one field of the common > header. > > It also gives us a spot to absolutely clearly indicate the required auth > len for this type. > > > [DC] ok, that's fine. Just remember you did that when whatever .bis draft > comes around. > > > > Section 10, para 1: This is the very first mention of 'Your > > Discriminator' > > field. No where in the previous sections is this field discussed, > > defined. In > > addition My Discriminator and Your Discriminator changes depending on > perspective. Does the sending and receiving systems use the same field > (presumably with different values)? > > > This draft extends RFC 5880 and they are defined there. > > [DC] fine. > > > > Section 11.2, para 1: This paragraph is not about multiple keys, but > > about key > > distribution. Please rename this to 'Secret Key Distribution' (if indeed > > this > > section is about Secret Keys). What keys are being discussed here? The > > Secret > > Key? Are you saying that distribution of the Secret Key (aka password) > > is out > > of scope? > > Section 11.2, para 2: The discussion of multiple keys needs to be > > defined to > > be out of scope too (again?). > > > RFC 5880 §6.7.1. mostly talks about not regularly changing authentication > modes. It's possible that the best answer for these paragraphs is to > simply delete them. > > > [DC] I'm not opposed to that idea. > > > > Section 12: I thought that draft-ietf-optimizing-authentication > > required that > > 'strong' authentication was used periodically, see Section 5. > > 'Thousands of > > packets' doesn't seem to be what was being proposed in that draft. > > Please make > > these estimation of number of packets (currently thousands and hundreds) > > more > > realistic. > > > Or perhaps simply drop the "thousands of packets". A general approximate > bound on the number of packets exchanged, including jittering of the > timers, across a given interval for a stable set of BFD timers could be > calculated... and isn't really helpful here. > > > [DC] and those calculations might change over time. I'm fine w/ dropping > 'thousands of packets'. > > > Section 15: If the Secret Key is basically a password (see Section 10 > > test > > vectors) please explain how that generation should be accomplished. Also > please explain why a PBKDF isn't used to distribute what little entropy > > is in > > that password. Or alternatively, explain how a PBKDF could be used. > > Note: > > since this is virtually the only value not transmitted across the > > network in > > the clear, it is the only unknown value to the attacker on the network. > > > While I find your cryptographic heart to be in the right place relating > the desire for PBKDF to be part of the process, this is not a common > practice for routing protocols including existing RFC 5880 mechanisms. > Requiring one would be overreach, IMO. Certainly commenting on best > password practices with regard to entropy is appropriate. > > > [DC] Thanks for acknowledging that I might have a heart. LOL... The > PBKDF was merely a whim, but it would help spread what little entropy a > password/shared key contains across the space of the Secret Key. I do > think that there should be something that explains the limitations and > issues with entropy here. > > > > I suspect Alan will partially respond to this as part of the update that > ISAAC+ added to the original ISAAC mechanism. > > > Section 15.1, last paragraph: [...] > I'm also curious about the perceived ineffectiveness of AES > (which is commonly a standard cell in most CPUs). The choice of AES in a > stream cipher mode might have been just as quick, and certainly has > > almost 3 > > decades of real analysis. > > > Note to all concerned: The following is pasted as an example and without > negative connotations about the vendor in question. > > > https://knowledge.broadcom.com/external/article/72584/aes-256bit-encryption-and-cpu-in-top-sec.html > > 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 > > >