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 remov
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 recommended
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 for
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 de
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 G-IK
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 that
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 migh
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, my li
I agree that there not any known security problems with HMAC-SHA1 or the 96-bit
truncation. Note that GCM with 128-bit tags and maximum length plaintext also
only provides a forgery probability of 2^-96.
I do however think IETF should deprecate SHA-1 everywhere asap. IETF refers to
NIST for the
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
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
>RFC5282, and I do no
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 should
Good point!
On 10/12/15 15:00, "IPsec on behalf of Tero Kivinen"
wrote:
>During the draft-ietf-lwig-ikev2-minimal Stephen pointed out that in
>my draft I have copied requirements from the RFC7296:
>
>--
>...
> For an implemen
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,
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 4
> 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 discrete logarithm computation
> Joshua Fried and Pier
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 generation
to distant future.
Cheers,
John
On 19/10/16 09:36, "n.mavrogiannopou...@gmail.com on behalf of Nikos
Mavrogiannopoulos" wrote:
>On Tue, Oct 18, 2016 at 8:46 PM, John Mattsson
> wrote:
>> New paper “Measuring small subgroup attacks against Diffie-Hellman”
>> https://
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 forbidd
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, ECSDA+SHA
>I would like to second the request to make this a working group item.
+1
From: Scott Fluhrer (sfluhrer)
Date: Monday, 4 November 2024 at 18:23
To: Kampanakis, Panos , ipsec@ietf.org
Subject: [IPsec] Re: New Version Notification for
draft-kampanakis-ml-kem-ikev2-09.txt
I would like to second
I think draft-reddy-ipsecme-ikev2-pqc-auth is ready for WG adoption.
Cheers,
John
From: tirumal reddy
Date: Monday, 28 October 2024 at 06:47
To: ipsec@ietf.org
Subject: [IPsec] Fwd: New Version Notification for
draft-reddy-ipsecme-ikev2-pqc-auth-02.txt
Hi all,
The draft https://datatracker.ie
I like Type 2. Type 2 allows you to transition to quantum-resistant
authentication while continue using your existing roots. Type 2 also allows
transition from hybrid to pure quantum-resistant authentication.
At least ANSSI has the idea that hybrid is a MUST for a short time and then
pure PQ ca
Hi,
I was extremely suprised that this draft claimed to have anything to do with
mobile networks. 3GPP specifications has _always_ mandated replay protection
for all 3GPP uses of IPsec, without exceptions. This has been a very clear
choice by 3GPP. I have been actively (as a delegate or backoff
update/obsolete RFC 8247
From: John Mattsson
Date: Saturday, 7 December 2024 at 09:55
To: Rebecca Guthrie , Scott Fluhrer (sfluhrer)
, ipsec@ietf.org
Cc: Kampanakis, Panos , Tero Kivinen
Subject: Re: New Version Notification for draft-kampanakis-ml-kem-ikev2-09.txt
Rebecca Guthrie wrote:
&g
rer) ,
ipsec@ietf.org
Cc: John Mattsson , Kampanakis, Panos
, Tero Kivinen
Subject: RE: New Version Notification for draft-kampanakis-ml-kem-ikev2-09.txt
You don't often get email from rmgu...@uwe.nsa.gov. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
+1;
Hi,
I think IKEv2 should register code points for FrodoKEM and BIKE/HQC (depending
on which one NIST standardizes). I think it is important with backups to
ML-KEM. The importance of cryptographic agility has been emphasized by several
US agencies. A necessity for cryptographic agility is to hav
could speak up so we don’t have to speculate. They are
probably all on this list…
Cheers,
John
From: Michael Osborne
Date: Thursday, 23 January 2025 at 09:25
To: John Mattsson , Loganaden Velvindron
Cc: Wang Guilin , ipsec , cfrg
Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM a
hen before asking >for official code points.
Yes, code points after FIPS or SP is published.
Cheers,
John
From: Scott Fluhrer (sfluhrer)
Date: Wednesday, 22 January 2025 at 18:26
To: Watson Ladd , John Mattsson
Cc: Wang Guilin , ipsec , cfrg
, Wang Guilin
Subject: RE: [CFRG] Re: [IPsec]:
draft is needed.
Cheers,
John
From: Loganaden Velvindron
Date: Wednesday, 22 January 2025 at 20:53
To: Michael Osborne
Cc: John Mattsson , Wang Guilin
, ipsec , cfrg , Wang
Guilin
Subject: Re: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2
Thanks. I can also see that Classic
https://cyber.gouv.fr/sites/default/files/document/pqc-transition-in-france.pdf
http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf
John
From: Michael Osborne
Date: Wednesday, 22 January 2025 at 20:39
To: Loganaden Velvindron , John Mattsson
Cc: Wang Guilin , ipsec , cfrg
, Wang
Hi,
There was significant interest from several countries to have a side-meeting on
PQC at IETF 122 Bangkok, so Ericsson will organize such a meeting on Monday 17
March 15.15 - 16.45 Bangkok time in Meeting Room 2 [40 seats] (overlapping with
Monday Session III). It is possible to attend remote
Hi,
There was significant interest from several countries to have a side-meeting on
PQC at IETF 122 Bangkok, so Ericsson will organize such a meeting on Monday 17
March 15.15 - 16.45 Bangkok time in Meeting Room 2 [40 seats] (overlapping with
Monday Session III). It is possible to attend remote
increased understanding between IETF people and
government officials. The plan is not to have long presentations, but if
_anybody_ want to show a few slides to foster discussion they are very welcome
to do so.
Cheers,
John
From: John Mattsson
Date: Friday, 28 February 2025 at 08:06
To: sp
Hi Uri,
Thanks for sharing. I think it is good to discuss the use of KEMs for
authentication, but one additional complexity of not using signatures is that
you also need changes to your PKI to support for proof-of-possesion of KEM
keys. The deployments of KEM authentication so far, e.g., Rosenp
If you make a KEM authenticated method for EDHOC, you get an EAP method
(EAP-EDHOC) with very little overhead for free, and can use that in IKEv2 :)
Sent from Commodore VIC-20
From: Blumenthal, Uri - 0553 - MITLL
Sent: Monday, June 30, 2025 9:06:19 PM
To: Valery
36 matches
Mail list logo
