The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Postquantum
Preshared Keys for IKEv2'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. P
I'm glad to see this document finally make it towards standardization.
Just a minor editorial note: capitalizing "Quantum Computers" is
incorrect and should be fixed before it goes to the RFC Editor.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.o
We are seeing a flurry of these kind of “post quantum protection” things. This
is premature. The co-chair of the CFRG, Kenny Paterson, said so awhile back.
At best, this should be EXPERIMENTAL.
I would like to see an IESG policy that makes all drafts on this topic be
EXPERIMENTAL.
_
Did Kenny make this statement in the context of postquantum cryptography (that
is, public key algorithms that are believed to be secure even if the adversary
has a quantum computer)?
That would certainly be a reasonable statement (as most postquantum algorithms
are fairly new, and are still bei
Slides:
https://datatracker.ietf.org/meeting/99/materials/slides-99-saag-post-quantum-cryptography
Video: https://www.youtube.com/watch?v=abmd1n5WUvc&t=1451s
On 12/11/19, 11:36 AM, "Scott Fluhrer (sfluhrer)" wrote:
Did Kenny make this statement in the context of postquantum cryptography
Hi Rich,
I strongly disagree with your statement that “this is premature”, and the
slides that you cite do not support that claim. I totally agree with the
points in Kenny’s slides, especially as they pertain to QKD and SDO-shopping,
but they say nothing about improvements to security protocol
On 11 Dec 2019, at 8:23, Salz, Rich wrote:
We are seeing a flurry of these kind of “post quantum protection”
things.
This is the only one I have seen that is a method, not a new key
exchange algorithm. It is understandable that you could have missed this
from the title which misstates the to
> A much better title would be
"Mixing Preshared Keys in IKEv2 for Postquantum Resistance".
That's better.
I misunderstood the document as both you and David Mcgrew kindly explained. I
withdraw my concerns and hope the title is changed.
___
IP
Hi Rich,
I think that Kenny's slides only support the idea, that the draft should be
Standards Track.
In particular, the slide "The Coming Crypt-Apocalypse?" has a bullet:
* And traffic captured now could be broken later, so it’s a problem
*today* if you
have data that needs to
+1 for option4, +0.5 for option3
One factor to consider is the granularity of label, for me it is per CHILD_SA;
option1 is per TS (e.g TS with label and TS without label could be mixed in the
same payload), option2 is per TS payload (e.g. you could have TSi with label,
TSr without label)
Optio
Hi, Paul
> On 11 Dec 2019, at 20:03, Paul Hoffman wrote:
>
> On 11 Dec 2019, at 8:23, Salz, Rich wrote:
>
>> We are seeing a flurry of these kind of “post quantum protection” things.
>
> This is the only one I have seen that is a method, not a new key exchange
> algorithm. It is understandabl
On 11 Dec 2019, at 11:11, Yoav Nir wrote:
Hi, Paul
On 11 Dec 2019, at 20:03, Paul Hoffman wrote:
On 11 Dec 2019, at 8:23, Salz, Rich wrote:
We are seeing a flurry of these kind of “post quantum
protection” things.
This is the only one I have seen that is a method, not a new key
exchange
Hi Paul,
I don't think option 4 is a good idea. If old responder
encounters an unknown payload with Critical bit set in IKE_AUTH, it will
return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up.
See section 2.21.2 of RFC7296. This would require initiator to retry from
IKE_SA_INIT, dou
13 matches
Mail list logo
