On Sun, Mar 03, 2024 at 09:14:57PM -0500, Paul Wouters wrote:
>
> I agreed to write up a draft to discuss the issue regarding rekeying
> the initial Child SA and KE/PFS settings.
>
> Previous discussion/presentation at IETF118:
> https://datatracker.ietf.org/meeting/118/materials/slides-118-ips
, 28 Mar 2019, Tobias Heider wrote:
>
>> On 3/28/19 5:18 PM, Tero Kivinen wrote:
>>> Tobias Heider: ??
>> The question I asked was:
>> The draft already says that INTERMEDIATE can not be used without another
>> document
>> that specifies what payloads
wants to join, feel free to contact me.
Regards,
Tobias
On 3/27/19 6:29 PM, Tobias Heider wrote:
> Hi,
>
> we had a side meeting today where some of us shared our experiences
> implementing this
> draft and we had the chance to discuss the future of this draft with
> the authors
On 3/28/19 5:18 PM, Tero Kivinen wrote:
> Tobias Heider: ??
The question I asked was:
The draft already says that INTERMEDIATE can not be used without another
document
that specifies what payloads are sent in INTERMEDIATE. Why can't that
additional
document also define it's own ex
On 3/28/19 2:19 PM, Panos Kampanakis (pkampana) wrote:
> Thanks Tobias, Valery and Stefan.
>
> Imo Classic McEliece is impractical for use in live key negotiations in
> protocols like TLS, IKE, SSH etc. NIST will standardize more practical and
> secure postquantum KEMs and the added complexity f
Hi,
we had a side meeting today where some of us shared our experiences
implementing this
draft and we had the chance to discuss the future of this draft with the
authors.
Here's what we have talked about and our results:
#1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:
The current draft pr
>>> I would think it quite differently. Each protocol extension just puts
>>> payloads in the IKE_SA_INIT and once that one becomes too big, the
>>> IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
>>> This document defines what goes into IKE_SA_INIT, so the rest (eg new
>>>
>> It's a good question. My idea is that each application document
>> must define this, as well as the order of INTERMEDIATE exchanges,
>> if it matters. So, I assume that by default each application
>> will utilize its own INTERMEDIATE , but some applications could
>> benefit from piggybacking. Bu
If there is a chance that this is a potential thread (and I fear
it'll be impossible to proof the opposite), my feeling is
that the document should say that IKE_INTERMEDIATE MUST NOT be
supported without the support of at least one document defining the
payload. >>> T
Hi Valery,
>> If there is a chance that this is a potential thread (and I fear
>> it'll be impossible to proof the opposite), my
>> feeling is that the document should say that IKE_INTERMEDIATE MUST
>> NOT be supported without the
>> support of at least one document defining the payload.
> That is
10 matches
Mail list logo
