Re: [skex] Naming: SKEX and DSKE

[Manfred von Willich <[e-mail]>]

> On Wed, Mar 27, 2024 at 6:57 AM Panwei (William) <william.panwei=
[e-mail]> wrote:

> After thinking more, I think SKEX and QKD are somehow connected and have
the possibility of collaboration / integration. Using them together may be
good to provide a solution suitable for more scenarios.

DSKE is an example that would compete with QKD in QKD's use cases, but will
also address a much wider range of use cases.  Your observation about
combining them is valid: we have already found ways in which combining them
makes sense.

> I heard that the plan is to have a BoF in IETF 120. I think there are
still many things need to be prepared before the meeting to make it
successful.

Agreed.  You have pointed some out, but perhaps we should develop (specify
in more detail) this list of objectives of what we want to have ready
before IETF 120.  I get the impression that a draft WG charter would be one
of the first things to write.  Some of the objectives you mention might be
suitable for including in a charter.

> About what should be done in IETF, the first thing I think is to make the
use cases clear. Use cases and problem statement are always the most
important thing. Neither SKEX nor QKD is used to replace PQC, so it’s
necessary to make clear what kind of use cases are suitable for the use of
SKEX.

Agreed.  Let me start with a few overall cases.

   - Symmetric key agreement for assured quantum-safety in point-to-point
   network encryptor links, especially where the session keys may have a short
   cryptoperiod.  This is where QKD fits, but has disadvantages (cost,
   inflexibility, limited range and rate, etc.).  There are diverse industries
   where this applies: corporate, enterprise, governmental, financial, cloud
   infrastructure, etc.  This may be using MACsec keying, IPsec via RFC 8784,
   and others.
   - A symmetric key agreement for zero-trust application networks, either
   alone or in TLS/QUIC via RFC 8784.  This might cover IoT, and communication
   apps such as on mobile devices, for both corporate use and large
   communities.
   - A rather exceptional use case: allowing mutually distrustful
   organizations to communicate securely in a way that cannot be cheated by
   any single organization (negotiations come to mind).

> The second thing is to identify what the characteristics of these use
cases are and what security properties are needed. The purpose is to
identify what part are missing and can be done in IETF.

I tend to work backwards: from a protocol, I deduce what properties are
ensured by it, and then find supported use cases.  However, I agree that
being clear about required security properties for use cases is essential.
I would add to this point that an important part to consider in the SKEX
charter is whether there are interface aspects to be standardized, with a
view to interoperability and interchangeability.  IETF would probably not
deal with specific interfaces, but might more abstractly specify data to be
transferred via an API, sort of abstracting ETSI GS QKD 014 and adapting
it, including security requirements.  I think that this is going to be very
important to users, integrators and vendors, and will positively impact
adoption.

> The third thing is about the solution or protocol part. Firstly,
currently I don’t know whether an architecture is needed, this may depends
on how complex the use cases and solutions are. Secondly, I don’t think
currently it’s the right time to do the comparisons or decisions among
different symmetric key exchange solutions or protocols. I think it’s
better to discuss that after the working group created. I’m curious whether
DSKE is the only one that the proponents want to proceed with. It’s fine to
me if DSKE is the final winner of the competition among solutions. But I’m
not an symmetric key exchange expert. And I’d like to see more people
participate in, bring their solutions to IETF and share their ideas of why
they think their solution is good. At the end, there may be more than one
protocol that people want to standardize, maybe because the need and
appliance of different use cases.

For now, I would like to assume that a SKEX WG could accommodate several
protocols being considered for RFC/standardization.  Any "competition"
between protocols would arise as a result of IETF constraints.  For the
time being, DSKE is the only one I'm aware of that is on the table as a
published protocol, but that need not remain so.  This is for a BoF/WG to
debate.

> There is one more thing that I’m not clear now. If the working group
being successfully created and DSKE being chosen, should DSKE first go
through CFRG for security evaluation?

Before it goes too far in the process, I believe close analysis of any new
protocol is appropriate.  DSKE is new.  So I believe so, yes, as soon as
the SKEX BoF/WG has some consensus on the viability of DSKE.

Manfred


On Wed, Mar 27, 2024 at 6:57 AM Panwei (William) <william.panwei=
[e-mail]> wrote:

> Hi,
>
>
>
> I’ve attended the side meeting and I’m interested in this topic.
>
>
>
> Previously, I only considered counteracting the quantum threat through PQC
> and QKD. I’m actually a fan of QKD.
>
> During the side meeting, I was impressed by listing the Symmetric Key
> Exchange (SKEX) as the third direction. But after the meeting, I feel this
> is reasonable.
>
> After thinking more, I think SKEX and QKD are somehow connected and have
> the possibility of collaboration / integration. Using them together may be
> good to provide a solution suitable for more scenarios.
>
>
>
> I heard that the plan is to have a BoF in IETF 120. I think there are
> still many things need to be prepared before the meeting to make it
> successful.
>
> About what should be done in IETF, the first thing I think is to make the
> use cases clear. Use cases and problem statement are always the most
> important thing. Neither SKEX nor QKD is used to replace PQC, so it’s
> necessary to make clear what kind of use cases are suitable for the use of
> SKEX.
>
> The second thing is to identify what the characteristics of these use
> cases are and what security properties are needed. The purpose is to
> identify what part are missing and can be done in IETF.
>
> The third thing is about the solution or protocol part. Firstly, currently
> I don’t know whether an architecture is needed, this may depends on how
> complex the use cases and solutions are. Secondly, I don’t think currently
> it’s the right time to do the comparisons or decisions among different
> symmetric key exchange solutions or protocols. I think it’s better to
> discuss that after the working group created. I’m curious whether DSKE is
> the only one that the proponents want to proceed with. It’s fine to me if
> DSKE is the final winner of the competition among solutions. But I’m not an
> symmetric key exchange expert. And I’d like to see more people participate
> in, bring their solutions to IETF and share their ideas of why they think
> their solution is good.
>
> At the end, there may be more than one protocol that people want to
> standardize, maybe because the need and appliance of different use cases.
>
>
>
> There is one more thing that I’m not clear now. If the working group being
> successfully created and DSKE being chosen, should DSKE first go through
> CFRG for security evaluation?
>
>
>
> Regards & Thanks！
>
> Wei PAN (潘伟)
>
>
>
> *From:* skex <[e-mail]> *On Behalf Of *Manfred von Willich
> *Sent:* Friday, March 22, 2024 4:34 PM
> *To:* [e-mail]
> *Subject:* [skex] Naming: SKEX and DSKE
>
>
>
> To avoid conflation/confusion, please note the following suggested naming:
>
>
>
> SKEX (Symmetric Key Exchange) refers to this mailing list and is a
> potential working group name.
>
>
>
> DSKE (Distributed Symmetric Key Exchange) is a specific key distribution
> protocol, the one we used as an example at the side meetings at IETF 119.
> This is an implemented protocol, and has a security proof (
> https://arxiv.org/abs/2304.13789).  This is only one of the potential
> RFCs that SKEX could discuss.  The group may choose to adapt this protocol,
> as well as rename it.
>
>
>
> Melchior, Mattia, Manfred
> --
> skex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/skex
>