[Emu] Murray Kucherawy's No Objection on draft-ietf-emu-aka-pfs-12: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-emu-aka-pfs-12: 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:
----------------------------------------------------------------------

Thanks for this work.  Thanks also to Sean Turner for the ARTART review.

And thanks for resolving the DISCUSS question around the document's status. 
The rest of my original comment is left here for reference.

===

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.