These and the PR61 updates look pretty good to me. Don't forget Alan's paragraphs about not using ISAAC for anything else, dammit.
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. 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). 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.] 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. 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. Deb On Tue, Oct 14, 2025 at 4:24 PM Jeffrey Haas <[email protected]> wrote: > https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/59 > > > Deb, > > The above pull request attempts to address the issues covered in this > reply. Since the changes are somewhat disruptive, also find attached a > iddiff covering this pull request. > On 10/12/25 14:48, Deb Cooley wrote: > > key management - generation (statement in Sec Consid) and PRNGs (and how > they are used). See my notes in Jeff's last message. > >> > Section 8, para 2: Multiple Secret Keys: If this specification >> doesn't want >> > to explain how they are used, then one should say they are 'out of >> scope'. >> > Please put the 'MUST NOT' sentence second in the paragraph (and remove >> the >> > 'however'. This puts the requirement where it will be more easily seen >> (i.e. >> > don't bury the lead). >> >> Hopefully addressed in the PR. Primarily this section addresses two >> things: The fact that multiple keys can be provisioned and that there is a >> selector for which key is to be used. Also, some clearer text noting that >> we are unable to switch keys without resetting the state machine. >> > > [DC] I don't see anything done here. I'm not going to hold out on this > one, just pointing out that you bury the point of the paragraph. I do > think it could be fixed quite easily, maybe the Editor will do it. [my own > working group authors are now quoting me in advance about 'burying the > lead'. But this isn't my working group, so....] > > I've attempted to "unbury" this. The discussion about the use of one or > two keys is moved to the security considerations and a forward reference is > added. > > > Section 8: How are the per party secret keys generated, distributed, >> > protected? If that is in scope, please describe. If it is out of >> scope, >> > please add appropriate guidance to Security Considerations. >> >> Please check vs. the latest text and see prior discussion. >> > > [DC] I don't actually see this anywhere. > > This PR should address the point. In particular it notes this is done via > provisioning and that the security of this provisioning mechanism is left > out of scope for the document. > > This is a place where the security directorate should consider creating > appropriate boilerplate. > > > >> > 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. >> >> Previously discussed. >> > > [DC] I suspect you could use the short paragraph I gave for the optimized > draft about choosing keys wisely.... > > I've copied and pasted this from the prior document as an appeasement > operation. See again comment about this being something deserving > boilerplate. > > > >> > >> > Section 15.1.2: Are you recommending that the keys used for keyed MD5, >> keyed >> > SHA1, and ISAAC be the same (aka the Secret Key)? Please change this. >> Any >> > leak of any one of these keys (the ISAAC version is specified to be a >> password) >> > would result in the attacker being able to construct any BFD packet, >> for any >> > purpose. >> >> In the current text, there is discussion about what happens if you do or >> do not leverage the same key for the more/less computationally intensive >> mechanism. As we previously discussed, and noted in the document, there is >> a warning that is an operational consideration about issues with >> maintaining two keys and what happens if the less computationally intensive >> key isn't consistently provisioned. >> >> The document permits implementations to use two keys if it desires to do >> so. >> > > [DC] but no discussion about the pitfalls of using the same key for both. > Something similar to what is in my original comment would work. > > Discussion about the pitfall is explicitly added. The text recommends > that implementations permit multiple keys. It leaves the choice as to > whether to use one or two keys to the operator based on their security and > operational stances. > -- Jeff >
