[saag] Re: [CFRG] [MSEC]Fwd: New Liaison Statement , "LS on PQC transition for RFC 6509"

The cryptography of proof systems you need to do the zkps is very active
thanks to cryptocurrency so plenty of options. I don't think that was the
deployment barrier. That conversation is happening to some extent in
privacy pass.

On Wed, Nov 12, 2025, 11:59 AM John Mattsson <john.mattsson=
[email protected]> wrote:

> I think if would be good if CFRG started discussing quantum-resistant
> replacements for pairing-based cryptography. In addition to IBE and ABE,
> there is a lot of interest in zero-knowledge proofs and anonymous
> credentials with selective disclosure. I would be sceptical to deploy
> pairing-based crypto at the moment as long as it is uncertain if there will
> be PQC replacements before 2035 when most organisations will try to phase
> out all quantum-vulnerable crypto.
>
> John
>
> *From: *Nick Sullivan <[email protected]>
> *Date: *Wednesday, 12 November 2025 at 20:53
> *To: *Russ Housley <[email protected]>
> *Cc: *John Mattsson <[email protected]>, Deb Cooley <
> [email protected]>, IETF SAAG <[email protected]>, IRTF CFRG <[email protected]>,
> [email protected] <[email protected]>, [email protected] <[email protected]>,
> Paul Wouters <[email protected]>, Charles Eckel <[email protected]>
> *Subject: *Re: [CFRG] [MSEC]Fwd: New Liaison Statement, "LS on PQC
> transition for RFC 6509"
>
> My understanding is that there are a few preliminary options for PQC IBE
> systems, including this one (
> https://indico.math.cnrs.fr/event/11948/attachments/5546/9653/5_Julien_Cam.pdf
> <https://indico.math.cnrs.fr/event/11948/attachments/5546/9653/5_Julien_Cam.pdf?utm_source=chatgpt.com>)
> based on ML-KEM, but they are much less mature than the pairing-based
> systems.
>
> I would even consider the non-PQC pairing crypto we do have as
> experimental/new/risky. It’s not yet widely deployed in IETF protocols, and
> the CFRG is still working on a document to specify safe parameters (
> https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-10.html
> ).
>
> If someone in the CFRG wants to tackle the problem of specifying a PQC IBE
> system, I don’t see it as out of scope for the group. There would be some
> leg work and support needed by implementers to specify something, but even
> with that, it’s not clear there’s consensus even in academia about what the
> right approach is. I would consider it too early for the CFRG to make a
> considered recommendation today.
>
> Nick
>
> On Wed, Nov 12, 2025 at 2:31 PM Russ Housley <[email protected]> wrote:
>
> I am unaware of any IBE PQC algorithms.  Is this something that CFRG is
> willing to work on?  Even if they are, I doubt we could give 3GPP a firm
> completion date.
>
> Russ
>
> On Nov 12, 2025, at 1:51 PM, John Mattsson <john.mattsson=
> [email protected]> wrote:
>
> Hi Deb,
>
> Yes, MIKEY (RFC 3830) was updated by three AD sponsored RFCs: MIKEY-TICKET
> (RFC 6043), MIKEY-IBAKE (RFC 6267), and MIKEY-SAKKE (RFC 6509). My reading
> of the LS is that 3GPP specifically asked for MIKEY-SAKKE (RFC 6509) which
> is an optional application layer for use by governments in mission critical 3GPP
> systems, but to my understanding, it is not widely deployed. RFC 6507
> (ECCSI)) and RFC 6508 (SAKKE) are not formally related to MIKEY but are
> used in RFC 6509 (MIKEY-SAKKE).
>
> While 3GPP specifications also refer to RFC 3830 and RFC 6043, 3GPP only
> use symmetric algorithms/modes, which are already quantum-resistant.
>
> (MIKEY-)SAKKE is not using P-256, it uses pairing-based cryptography
> (E(F_p) x E(F_p) -> F_p^2, where p is a 1024 bit prime, and was not
> affected by SexTNSF.) Making the identity-based MIKEY-SAKKE
> quantum-resistant likely involves using not yet standardized lattice-based
> cryptography and is at least not easy. Any updates should likely be done in
> corporation with the governments interested in using them. MIKEY-SAKKE was
> authored by UK NCSC.
>
> For the non-identity-based parts of MIKEY, the symmetric parts are already
> quantum-resistant, and best current practice according to RFC 8862 is to
> mandate support of DTLS-SRTP, which is already being migrated to PQC by TLS
> WG.
>
> Cheers,
> John
>
> *From: *Deb Cooley <[email protected]>
> *Date: *Wednesday, 12 November 2025 at 14:52
> *To: *IETF SAAG <[email protected]>, [email protected] <[email protected]>,
> [email protected] <[email protected]>
> *Cc: *[email protected] <[email protected]>, Charles Eckel
> (eckelcu) <[email protected]>, Paul Wouters <
> [email protected]>
> *Subject: *[MSEC]Fwd: New Liaison Statement, "LS on PQC transition for
> RFC 6509"
>
> SAAG, CFRG and MSEC,
>
> The Sec ADs received the enclosed liaison request from 3GPP.  The subject
> is the PQ transition timeline for MIKEY-SAKKE (MIKEY was originally
> specified in RFC 3830, then updated and expanded in RFCs 6507, 6508, 6509)
> and whether the IETF plans to update this protocol to be PQ secure.
>
> From a quick skim of the RFCs (where the later RFCs are Informational and
> were AD sponsored), it appears that the basis of this protocol/algorithm is
> ECC P256/SHA-256 with a certificate-less Identity Based public key system.
>
> If there is anyone who is planning to do the update work, please speak up
> now.  [I'm not making any comments on how easy/hard this work might be.]
>
> Otherwise, we (IETF) will go back to 3GPP stating that we do not plan to
> update this protocol.
>
> Thanks,
>
> Deb Cooley
> Security Area Director
>
> ---------- Forwarded message ---------
> From: *Liaison Statement Management Tool* <[email protected]>
> Date: Sat, Nov 1, 2025 at 3:21 PM
> Subject: New Liaison Statement, "LS on PQC transition for RFC 6509"
> To: Deb Cooley <[email protected]>, Paul Wouters <[email protected]
> >
> Cc: Charles Eckel <[email protected]>, Deb Cooley <[email protected]>,
> Paul Wouters <[email protected]>, The IETF Chair <[email protected]>, <
> [email protected]>
>
>
> Title: LS on PQC transition for RFC 6509
> Submission Date: 2025-10-30
> URL of the IETF Web page: https://datatracker.ietf.org/liaison/2070/
>
> To: Security Area (sec)
> From: 3GPP TSG SA WG3
> Purpose: For action
> Please reply by 2025-11-14
>
> Email Addresses
> ---------------
> From: Zander Lei <[email protected]>
> To: Paul Wouters <[email protected]>,Deb Cooley <[email protected]>
> Cc: Deb Cooley <[email protected]>,Charles Eckel <[email protected]>,The
> IETF Chair <[email protected]>,Paul Wouters <[email protected]>
> Response Contacts: 3GPP Liaisons Coordinator <[email protected]>
> Peter Schmitt <[email protected]>
> Technical Contacts:
>
>
> Body: 1 Overall description
>
> 3GPP SA3 has started a study on “Transitioning to Post Quantum
> Cryptography (PQC) in 3GPP”. This is to prepare the PQC transition for
> security protocols used in 3GPP systems. 3GPP SA3 has identified that the
> MIKEY-SAKKE protocol, which is used in 3GPP systems to transport
> cryptographic keys securely for Mission Critical Services, is specified in
> the IETF RFC 6509. Since it employs asymmetric cryptography for key
> distribution and may be vulnerable to quantum computing, SA3 would like to
> know whether there is any plan for IETF to update the RFC 6509 using PQC.
> If yes, SA3 appreciate if IETF can provide estimated timeline for the
> protocol update.
>
> 2       Actions
> To IETF SEC Area
> ACTION:         SA3 kindly request IETF to provide feedback on the
> question above.
>
> 3       Dates of next TSG SA WG 3 meetings
> SA3#125 17 – 21 November 2025           Dallas, US
> SA3#126 9 – 13 February 2026            India (TBD)
> Attachments:
>
>     LS on PQC transition for RFC 6509
>
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-10-30-3gpp-tsg-sa-wg3-sec-ls-on-pqc-transition-for-rfc-6509-attachment-1.docx
>
>
> _______________________________________________
> CFRG mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]