Re: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

on From: Scott Fluhrer (sfluhrer) Date: Sunday, 3 March 2024 at 18:40 To: John Mattsson , ipsec@ietf.org Subject: RE: Review of draft-kampanakis-ml-kem-ikev2-02 I agree that it sounds like a good time to start work on postquantum IKEv2 authentication. In addition to the lamps draft you cite

[IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

Review of draft-kampanakis-ml-kem-ikev2-02 Hi, I think IPSECME should adopt this draft asap. This should definitely be a standards track RFC. I really like that IKEv2 register KEMs as separate code points and not hybrid code points like in TLS 1.3. I think the hybrid code points in TLS 1.3

Re: [IPsec] New Liaison Statement, "Quantum Safe Cryptographic Protocol Inventory"

Hi, Even if JOSE WG is not included in the recipients, I looked at this LS and TR 103 619 that the LS refer to. In addition to the requested information, I think IETF should send ETSI CYBER comments on TR 103 619 that the LS is based on. My suggestions: --- IETF kindly suggests

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

Hi Valery, Some quick commments. - If the G-IKEv2 engine is not trusted to access information inside the messages, it should probably not be trusted to modify the keys. Chaning the keys would get however is in control of the G-IKEv2 engine access to information encrypted with the keys. (The

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt

Hi, Not too late to change. According to NIST, 2048-bit MODP Group and 224-bit Random ECP Group are MUST NOT use if the information you are protecting have a lifetime longer than 8 years (2031 - today). 1024-bit MODP is two security levels below that. I think IETF in generally way to slow if

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway

Hi Dan^2 The OCB2 attack clearly states that ”Our attacks do not apply to OCB1 and OCB3”. The attack is only applicable to OCB2 because of the particular way it combines the XE and XEX modes. The technical details of the OCB2 attack should not erode trust in OCB3. Note that OCB3 was chosen

[IPsec] Comments on draft-corcoran-cnsa-ipsec-profile-01

Hi, Thanks for producing this and the other IETF documents profiling the CNSA suite. I think it is very good to have strict profiles specified for a high security level. "The approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180]. However, SHA-512 is

Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv-05

Hi, I think the idea of introducing "implicit IV" also in IPsec is great and something that absolutely should be done. Some comments: - The abstract/introduction/security consideration gives the idea that it defines implicit IV for ENCR_AES_CTR which is does not. I think AES-CTR could be

[IPsec] SHA-1 signatures in IKEv2

One question, currently SHA-1 signature are not only allowed by RFC7296, but even "SHOULD use as default”. 4307bis does not change this. Shouldn’t something be done about this. Right now (and even with 4307bis): RSASSA-PKCS1-v1.5 with SHA-1 is MUST support and everything else (PSS+SHA-2,

[IPsec] Updated 3GPP Profile for IKEv2

Hi, FYI, 3GPP recently updated its IKEv2 profile. The current profiles for IKEv2 and ESP looks like this (only the relevant part of 3GPP TS 33.210 and TS 33.310): https://www.scribd.com/document/332057984/3GPP-IPsec-Profile-Nov-2016 Main changes are: - SHA-1 signatures of all kinds are

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

in the not to distant future. Cheers, John On 19/10/16 09:36, "n.mavrogiannopou...@gmail.com on behalf of Nikos Mavrogiannopoulos" <n.mavrogiannopou...@gmail.com on behalf of n...@gnutls.org> wrote: >On Tue, Oct 18, 2016 at 8:46 PM, John Mattsson ><john.matts...@ericsson.com> wr

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

New paper “Measuring small subgroup attacks against Diffie-Hellman” https://eprint.iacr.org/2016/995.pdf “Cryptographic recommendations from standards committees are often too weak or vague” “However, the tangle of RFCs and standards attempting to define current best practices in key

Re: [IPsec] trapdoor'ed DH (and RFC-5114 again)

> I'm proposing it is time to change this to MUST NOT for 4307bis. +1 On 09/10/16 23:26, "IPsec on behalf of Paul Wouters" wrote: > >Released a few days ago: > > http://eprint.iacr.org/2016/961 > > A kilobit hidden SNFS

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt

Hi, I reread draft-ietf-ipsecme-rfc4307bis-10, I think this is very well written and definatly ready for WGLC. Some comments: - Section 4.1 Given the existing text “Digital Signature [RFC7427] is expected to be promoted”, I think authentication method number 14 should be “SHOULD+” - Section

[IPsec] 3GPP question about ECDSA support

3GPP is currently apopting ECDSA for all uses of IKEv2 (older releases used RSA). My 3GPP SA3 colleagues (cc) have asked me to forward the question below to the IPSec wg. As discussed in Buenos Aires, 3GPP and IETF should coordinate more, I hope the IPSec wg can provide valuable feedback. Cheers,

Re: [IPsec] RFC 4307bis

Hi, -Agree with your comment on “mandatory-to-implement”. I think the Introduction should be changed, and I suggest using something like the text used in RFC7321 “Algorithm Implementation Requirements and Usage Guidance”. RFC7321 also has a more explaining title. - I think 1024-bit MODP

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

point out which of the RFCs that are MTI. Cheers, John ----- John Mattsson MSc Engineering Physics, MSc Business Administration and Economics Ericsson IETF Security Coordinator Senior Researcher, Security ___ IPsec mai

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

On 03/11/15 09:42, "Tero Kivinen" wrote: >>- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is >> used, no algorithm from this table needs to be used.” Shouldn’t this >> be “MUST NOT be used”. > >This document just states the fact, the actual MUST NOT is in the