Murray Kucherawy has entered the following ballot position for draft-ietf-emu-aka-pfs-11: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [For the IESG to discuss] Further to Eric's point, I don't follow why this document, which specifies a protocol with interoperability properties, isn't a Proposed Standard. I get that it's updating/based on previous Informational documents, but it seems to me the fact that the original documents were Informational was done in error because they're a Technical Specification as defined by BCP 9. The fact that it describes an optional extension also doesn't mean it's not a Technical Specification. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. Thanks also to Sean Turner for the ARTART review. Section 7: The use of "RECOMMENDED" in Section 7 is peculiar. As prescriptive interoperability or security advice, to whom does it apply? Section 8: BCP 26 strongly urges that a Specification Required registry has advice for the Designated Experts, but this document contains none. Is there nothing to say here? Francesca's point also needs attention. === Additional comments from incoming ART AD, Orie Steele: 6.5.2 > The peer identifier SHALL comply with the privacy-friendly requirements of [RFC9190]. ought to be a MUST? Section 7 > As discussed earlier (see Section 1 and Section 4.3, forward secrecy is an important countermeasure against well-resourced adversaries that who may get access to the long-term keys, see Section 1. Many of the attacks against these keys can be best dealt [mitigated] with improved processes, e.g., [restricting] limiting the access to the key material within the [a] factory or personnel, etc. But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are. And the likelihood of practically feasible attacks has increased. To assume that a breach is inevitable or has likely already occurred [NSA-ZT], and to minimize impact when breaches occur [NIST-ZT] are essential zero trust principles. One type of breach is key compromise or key exfiltration. I'd recommend rewording much of this section. 7.1 Perhaps there is a better word than "forget", consider "destroy", possibly with a call out defense against forensic analysis. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
