Deb Cooley has entered the following ballot position for draft-ietf-bfd-optimizing-authentication-35: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: Many thanks for the hard work to resolve my discuss. I will be interested in seeing the results of the experiment! [Note: I'm leaving my original comments below, just for the record.] Thanks to Stephen Farrell for their secdir review. His comments are relevant. General: Please change 'strong authentication' to 'authentication' throughout the specification. One can hardly call MD5 and SHA1 keyed hashes 'strong'. [Note: while SHA-1 keyed hashes might not be currently deprecated, they are definitely on NIST's list to deprecate.] Intro: There is a link to MD5, but not to SHA-1? I suggest: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf. Intro: Please add a little bit more explanation to remind the reader why these normally fast hashes are too slow/hard. Please address both speed of the transmission and capability of the device performing the hashes. Section 3, para 1: Would one characterize 'Simple Password Authentication' as 'strong'? or even 'adequate'? Is there a reason it was left off the list of examples? [Given there are only three options, it seems strange to use examples here.] Section 3, para 4: 'as defined later in this document', which section is that? Section 3, last para: please ref which section in the specification this will be described. Section 4, bullet list: Why not list 'Simple Password Authentication', or 'NULL Auth'? Are these not also less computationally intensive? [assuming 'Simple Password Auth' was not listed because it isn't even 'adequate'. And if NULL Authentication is ONLY suitable when the CPUs aren't capable of any processing, then that needs to be stated much more clearly in the stability draft.] Section 4: Please add a sentence about how other mechanisms might be added. [since this specification is not meant to be prescriptive with respect to the use of ISAAC.] Section 5: Do both sides (sender/receiver) calculate the timing of the Poll sequence? [to prevent the ability of the adversary to corrupt/block the Poll sequence messages] Section 7: Is the 'authentication present (A)' bit transmitted? If so, where in Figure 1 is it? Perhaps in the Opt. Mode? If so, it would be easier to see if the same words were used in Para 1 as in the numbered list for Opt. Mode/Optimized Authentication Mode. Section 7.2, para 2, Section 10.1, para 1: If the goal is to allow other mechanisms, then the links to the ISAAC specification can be removed. [Note: there may be other places in the specification where this needs to be done.] Section 7.2, para 3: Do I understand this correctly? If there is an issue switching from the original authentication mode to a 'computationally less intensive' mode, then the session is torn down? That seems unfortunate. If that isn't what this means, then perhaps revise. Section 10: Designating any of these mechanisms as 'strong' is disingenuous at best. Please remove the word 'strong' from this specification. Para 2 points out why this is true. Section 10: Please add a sentence here which explains (justifies?) the level of authentication that is possible/practical for these systems. Please address both speed of transmission and CPU capabilities. Section 10: Normally I would expect to see how the provision of symmetric keys (for keyed hashes, etc.) is accomplished. According to RFC 5880, keys are shipped across the network in the clear via the local/remote discriminator field. This helps the attacker. Please address this issue here, or point back to the relevant section in RFC 5880 where the mitigation is outlined.
