Much, much better. I'm deleting the things I think we agree are resolved. The rest I've prefaced with [DC]
What is left is: key management - generation (statement in Sec Consid) and PRNGs (and how they are used). See my notes in Jeff's last message. I also think we are still missing the statement in Sec Consid. that basically says, ISAAC is ok for this particular use case, and no other. I'd add that to the last paragraph of 15.1. I'd like it to be unsubtle and a little in your face. The last thing I said I would help with was a statement about future methods. Since this is an experiment, is it possible to have a 'future work' section (I've never seen one). Other options might be the Introduction, or Sec Considerations (I guess). Something like: More secure methods may be an option as CPUs get faster and memory more plentiful. Options could be using AES w/ hardware acceleration in OFB mode (FIPS 197, SP 800-38A, Output Feedback Mode), CHACHA in S/W (a stream cipher, RFC 7539), or other well understood techniques. Deb > > > 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. > > Hopefully in better shape in the PR. > > > ---------------------------------------------------------------------- > > COMMENT: > > --------------------------------------------------------------------- > > > > > 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....] > > > > > 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. > > > > Section 10: In addition to ISAAC, a system is required to have a second > CSPRNG > > to generate session seeds? > > "Insert random number here, your choice of how it's random." > [DC] so here's the rub... if you use the same CSPRNG for both values not transmitted (seeds, secret keys) and for fields that are transmitted (sequence numbers, discriminators) you give away RNG state, in the transmitted fields. For example a failed noisy diode (commonly used as a RNG) will have long strings, which the attacker can see in sequence numbers and thus use to more easily guess the values not transmitted. This is why I make the comment about a second CSPRNG. At the very minimum this has to be acknowledged in the Sec Consid section or one has to require the use of two CSPRNGs (which I can't quite imagine). > > > > > Section 15: Please add a section about CSPRNGs. Describe the > requirements for > > strength and assurance. There are multiple mentions of CSPRNG for all > the > > various fields used in BFD (Session Seeds, Secret Keys, Sequence > Numbers). > > What are the consequences of using a sub par PRNG? What are the > mitigations? > > No text has been added - perhaps Alan has something in mind. > > That said, this seems like a generic issue for IETF standard documents. > Is there not a general bit of recommendation about such things already? If > not, you're surely not asking BFD authors to create that? > [DC] It is a generic issue, and normally, I would have pointed to RFC 4086. But that RFC is pretty long in the tooth (old - 2005 vintage). In this case, in the absence of an O/S and easily accessible things like 'cryptgenrand' or /dev/random (or /dev/urandom), it might still be appropriate. > > > > > 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.... > > > > > 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. > > -- Jeff > >
