IETF conflict review for draft-irtf-cfrg-hpke
conflict-review-irtf-cfrg-hpke-00

The following approval message was sent
From: The IESG
To: Colin Perkins ,
    Internet Research Steering Group ,
    Stanislav Smyshlyaev ,
    cfrg-chairs@ietf.org,
    draft-irtf-cfrg-hpke@ietf.org,
    irtf-chair@irtf.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-irtf-cfrg-hpke-12

The IESG has completed a review of draft-irtf-cfrg-hpke-12 consistent with
RFC5742.

The IESG has no problem with the publication of 'Hybrid Public Key
Encryption'  as an Informational RFC.

The IESG has concluded that there is no conflict between this document and
IETF work.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-hpke/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
It's unfortunate that there is no RFC 5742 "yes, please!" response, so
"no conflict" will have to do.


It may be worth discussing the security considerations when a given
private key is shared/used by a cooperating group of servers rather than
a single one, especially if there is any chance that a given KEM
key might be used in both "sender" and "recipient" roles (which is
stated to be a valid scenario in the discussion of the security goals).
To some extent this resembles the Key-Compromise Impersonation scenario,
but might be worth mentioning directly as a route by which key
compromise could occur even without compromise of a given endpoint
itself.

[Ballot comment]
To be clear, existing IETF work does normatively reference this document -- draft-ietf-tls-esni-13 (TLS WG) and draft-ietf-mls-protocol-11 (MLS WG).  However, I'm recommending the proposed conflict review text because these are not complimentary relationships.  The IETF is building upon the cryptographic mechanisms described here.  This approach continues the long standing practice of IRTF defining and publishing the new cryptography, and the IETF standardizing protocols that use it.