Roman Danyliw has entered the following ballot position for draft-ietf-emu-aka-pfs-11: 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-emu-aka-pfs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Carl Wallace for the SECDIR review. ** Section 1. Editorial However, the danger of resourceful attackers attempting to gain information about long-term keys is still a concern because many people use the service and these keys are high-value targets. What service? Could this text be clearer? ** Section 1. Editorial. While strong protection of manufacturing and other processes is essential in mitigating the risks, there is one question that we as protocol designers can ask. Is there something that we can do to limit the consequences of attacks, should they occur? I’m not sure what this paragraph adds. Consider if it is really needed. ** Section 1. Editorial. This document specifies an extension that helps defend against one aspect of pervasive surveillance. This is important, given the large number of users such practices may affect. It is also a stated goal of the IETF to ensure that we understand the surveillance concerns related to IETF protocols and take appropriate countermeasures [RFC7258]. This text largely repeats what was said in the paragraph before last (which also cited RFC7258). Consider if it is really needed. ** Section 1. While optional, the use of this extension is strongly recommended. Is this something better left to 3GPP in their profiling of this work? ** Section 1. Editorial Forward secrecy [DOW1992] is on the list of features for the next release of 3GPP (5G Phase 2) -- “Forward Secrecy” has been used multiple times by this point in the text. Why is the referenced introduced here instead on first use? -- Can an informative reference be provided for “5G Phase 2”? ** Section 3. The use of this extension is at the discretion of the authenticating parties. Wasn’t this more strongly worded in Section 1 (i.e., “While optional, the use of this extension is strongly recommended.”). Does it needed to be repeated? ** Section 3. Editorial. It should be noted that FS and defenses against passive attacks do not solve all problems, but they can provide a partial defense that increases the cost and risk associated with pervasive surveillance. Hasn’t this already been said in Section 1 (i.e., “This prevents an attacker who has ...”) ** Section 6.4 The term "support" here means that the group MUST be implemented and MUST be possible to use during a protocol run. What is a “protocol run”? Could it be turned off with configuration? ** Section 7. It is RECOMMENDED that EAP-AKA methods without forward secrecy be phased out in the long term. It is not clear what this means to implementers. What is “long term”? ** Section 7. Typo. s/comprimised/compromised/ ** Section 7. Editorial. In the spirit of more precise and inclusive language, consider if the term “Man in the Middle” can be replaced with another term. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
