Thanks, Roman. Inline: > 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.
We will take a look at all of these and consider modifications. > > ** 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”? As above. > ** 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? We will attempt to avoid repetition. The recommendation was for those who deploy. Once protocol entities are configured and interacting with each other, the use of the extension is indeed subject to the discretion of the two communicating peers. > > ** 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? We will take a look at this, thanks. > ** 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”? It was a recommendation for those who deploy, not a technical thing that an implementer will encode in a product. > ** 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. Ack. Thank you! Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
