Hi Quynh,
> An obvious question is that what is the performance impact from this large
KEM using the approaches above when compared with a KEM (if its public key
and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq
signature algorithm has a small signature and a small public
Hello,
This iteration addresses all feedback received in the IESG Review.
Thanks to Alissa, Adam, Barry, Alexey, Mijra, Roman, Martin and Eric for
their reviews.
Rgs,
Panos
-Original Message-
From: IPsec On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, January 15, 2020 12:17 AM
Hi Roman,
Two more comments in addition to Valery's.
> > ** Section 1. Per “Recent achievements in developing quantum computers …”,
> > is there a citation?
[I-D.hoffman-c2pq] is a good citation which we use already that talks about the
QC concern and Grover and Shor's algorithms. So we
Hi Mirja,
To try to answer your questions
1) You are right. This is mentioned in a paragraph below that reads
[...] or continue without using the
PPK (if the PPK was not configured as mandatory and the initiator
included the NO_PPK_AUTH notification in the request).
But for clarity
Thanks Alexey. The text will now read
[...] both the PPK and the PPK_ID strings be limited
to the base64 character set, namely the 64 ASCII [RFC0020]
characters 0-9, A-Z, a-z, + and /.
-Original Message-
From: IPsec On Behalf Of Alexey Melnikov via
Datatracker
Sent:
Hi Alissa,
Just adding a couple more responses:
>> I think the citation for [NISTPQCFP] should link to the actual call for
proposals.
We will add a link to the CFP pointing to
https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/document
s/call-for-proposals-final-dec-2016.pdf
Hi Éric,
To improve the IANA section a bit we followed the guidelines in RFC8126 more
religiously and I am attaching the diff here.
Let me know if there are more changes you would like to suggest for the IANA
section.
Rgs,
Panos
-Original Message-
From: IPsec On Behalf Of Éric
To make sure we mention the NIST PQ Level categorization (that will not
change as the NIST PQ Project progresses), I was thinking we could add
something in the Sec Considerations section like
[...] Because of
this, the user SHOULD ensure that the post-quantum preshared key used
has at
+1 on adopting draft-tjhai-ipsecme-hybrid-qske-ikev2
draft-tjhai-ipsecme-hybrid-qske-ikev2 and draft-ietf-ipsecme-ikev2-intermediate
are essential for enabling PQ Key Exchange in IKEv2.
From: IPsec On Behalf Of Jonathan Hammell
Sent: Sunday, November 10, 2019 7:51 PM
To: ipsec@ietf.org
want McEliece because they trust it more. In
that case, I suggest the mechanism described in #6 to be a "MAY" in the draft.
Panos
-Original Message-
From: Tobias Guggemos
Sent: Thursday, March 28, 2019 4:37 AM
To: Panos Kampanakis (pkampana) ; Tobias Heider
; IPsecME WG
> #4 Big Keys (e.G. Classic McEliece)
> In general there was consensus that we should find a way to enable the use of
> McEliece keys.
> The problem is that McEliece keys are >1MB in size and thus can not fit into
> the KE payload
> (which has a 16 bit size field).
Exchanging such big keys
+1 on adopting this draft.
-Original Message-
From: IPsec On Behalf Of Valery Smyslov
Sent: Thursday, March 14, 2019 4:38 AM
To: 'Tero Kivinen' ; ipsec@ietf.org
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
Hi,
as author of the document I (obviously)
Thanks for the detailed reviews Paul. I don't think the new text is changing
the meaning of the text that is already there. Anyone reading either of the
two, would be able to understand the point. Thus, I feel there is no need to
make the new change this late in WGLC process.
Panos
Hi Hammell,
This is interesting. Thank you for doing this work to systematically confirm
the logic and the state machine of the protocol update.
You assumptions are correct.
- The Have_PPK indeed means we have a PPK configured for the PPK_ID sent in the
initiator's notification.
- The PPK
This draft incorporates some minor text fixes, nits, small updates and
PPK_SUPPORT notification is changed to USE_PPK to better reflect its purpose.
It also includes two more important changes
- Clarified using PPK in case of EAP authentication. It follow the same
rational as IKE_AUTH in the
Hi Paul,
This draft merges all suggestions and addresses all issues brought up for the
previously draft-fluhrer-qr-ikev2 draft. It includes many changes for
readability and some new insightful Security Considerations. It does include
the optional NO_PPK_AUTH Valery brought up to solve the
Thank you Derrel.
Getting to this a little late.
All your comments will be addressed in the next iteration.
We will add some clarification text to clear up your points about rfc6023.
About rfc6030 we will make clear that this out of scope of this doc or IKE, but
it will just be an
Valery,
It is a good idea. A new optional notification that includes the auth_data as
it would be calculated without the PPK would work. With that, the corner case
of ' PPK_id configured on initiator but missing on the responder' is addressed.
There is an additional cost of the extra
Good point Paul. The issue will also hold for an initiator. The initiator might
have PPK enabled with other peers but not have a PPK_id configured for a
responder after he gets her IKE_INIT response with N(PPK_SUPPORT) included.
Practically the N(PPK_SUPPORT) is dictated by a global PPK support
is not recommended and that the caveats of using group PPKs.
Panos
-Original Message-
From: Valery Smyslov [mailto:sva...@gmail.com]
Sent: Thursday, July 27, 2017 10:39 AM
To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; David McGrew (mcgrew)
<mcg...@cisco.com>; Panos Kampanak
+1
Tero,
Waiting for your IKEv2 quantum resistance slides to become available, as a
great summary of the potential requirements.
-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
Sent: Wednesday, July 20, 2016 12:56 PM
To: Valery Smyslov
Hi Ray,
Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first
take of QC resistant IKEv2. It is still in its early stages and has not been
adopted as any WG's item yet.
Feedback is welcome.
Rgs,
Panos
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Perlner,
22 matches
Mail list logo
