I have updated my ballot. TYVM for the hard work. Deb
On Wed, Oct 15, 2025 at 9:12 AM Jeffrey Haas <[email protected]> wrote: > 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 > >
