Deb,
> On Oct 14, 2025, at 6:30 PM, Deb Cooley <[email protected]> wrote: > > These and the PR61 updates look pretty good to me. Don't forget Alan's > paragraphs about not using ISAAC for anything else, dammit. The changes are being reviewed in separate pull requests, but will be integrated before the next publish to the datatracker. > > WRT boilerplate that the Security Area should provide... think hard about > whether you really want that. In general, the protocols that come from > working groups in the security area don't typically allow an operator to pick > a value, distribute it somehow (phone call anyone?) with no intention of ever > changing those values. It's absolutely worth the conversation, including how to accommodate operational practicalities. A significant amount of the churn we see in the out-of-area comments on our drafts (at least from a routing perspective) come from "your'e not doing the Thing the way we like". Little surprise, most of these tend to come from security, transport, and operations. The goal isn't a burdensome RFC saying "you need to include this operations template that is larger than the protocol extension" (an intentional dig at current work). Rather, it's to point out that there are common patterns that being able to choose from a catalog would reduce iteration time. > > For key variable generation, I would start with one of the new password > authenticated key exchanges (PAKE - where OPAQUE is one of the newest). Even > if I started with a simpler pbkdf (password based key development function), > I suspect there would be dismay. > > Reuse of keys for multiple purposes is a well known issue. We might be able > to wrangle boilerplate for that (and it may already exist). Understood, and agreed. And, also overreach for the current matter at hand. Operators significantly live in an environment of provisioned secrets and much of our routing infrastructure uses these practices. The conversation you're alluding to above is "if you wanted to swap out your key mechanisms for authentication, here's what we'd do". Finding the broad desire in routing to do that work without other industry motivation would be problematic. It's a good IAB conversation. > For CSPRNGs or just plain PRNG, the point about RFC 4086 is well taken. In > this particular case, w/out a previously vetted PRNG at hand, RFC 4086 is > still fit for purpose. [Adding the CS to the front of a pseudo random number > generator is a TLS thing, I think.] Primarily, such things are a call to not ask a document fit for one purpose (BFD in this case) to try to stake out ground for writing considerations that are addressing broader IETF issues. A level of indirection to best practice documents is what we're looking for. > Using the output of a CSPRNG for transmitted and non-transmitted values > doesn't come up that much, honestly. It is something I used to deal with > when I had a day job. Even then it was definitely a low probability issue > when a decent RNG was at hand. Unfortunately, in this case, I wonder at the > quality of a RNG, which makes the probability of it being an issue higher. A common security area feedback in routing mechanisms overlaps the need for nonces. So, it's not completely unknown. > > And none of us is young - you, me (most certainly), AES, SHA-1, MD5, ISAAC, > the whole lot. > > Thanks for doing all this work. I, personally, think the specifications are > better for it. Thanks for the slog. I think we're almost done. -- Jeff
