[saag] Re: [skex] Initial thoughts on SKEX

Hi Eric,

I share your concerns. The BOF request does not state what the problem with existing frameworks and protocols to establish symmetric keys is. It does also not state what the high-level requirements on the new framework and protocols should be.
https://datatracker.ietf.org/doc/bofreq-aelmans-skex-symmetric-key-establishment-and-exchange/

Cheers,
John

From: Eric Rescorla <[email protected]>
Date: Sunday, 16 March 2025 at 06:25
To: Manfred von Willich <[email protected]>
Cc: [email protected] <[email protected]>, IETF SAAG <[email protected]>
Subject: [saag] Re: [skex] Initial thoughts on SKEX
> Some responses.  I will be very selective so as to avoid an overlong
> reply, but the TL;DR is that you seem to be thinking of SKEX as being
> proposed as a drop-in proposal for existing established protocols for
> primary uses cases only, which misses the point: SKEX tries to solve
> problems that PKI and PQC do not solve well.

Perhaps, but I don't think either your email or the draft makes
a particularly persuasive case that it does so. I've responded in
detail below, but I think if you want to make this case you need
to really describe those use cases in some detail under the assumption
that we have quantum-resistant asymmetric protocols, which the
existing draft does not do.


Before we get into the details of SKEX, I think it's worth looking at
the higher level first. ISTM that one could imagine two arguments
for SKEX or something like it:

- That it's better for deployment reasons in some settings.
- That it's resistant to quantum computers and so worth it
  even if deployment is inconvenient.

I don't find either of these super persuasive, but the first
seems especially weak.


## Deployment

SKEX (or at least DSKE) is really two things:

1. A system for provisioning shared symmetric keys between endpoints
   using security hubs.
2. A protocol for talking to security hubs based on endpoints
   sharing a pre-provisioned symmetric key with the hub.

My broader point is that (1) is not really that useful for deployment
reasons and even if we believe (1) is useful, there's no reason to
deploy it over a channel protected with a pre-provisioned symmetric
key as in (2) unless you are worried about quantum computers (see
below).

As a general matter, asymmetric key protocols are more flexible than
symmetric key protocols because they rely just on establishing
authenticity of information, not on exchanging secrets. Note that
asymmetric protocols do not require PKI; you can just exchange key
hashes as in SSH.  In general if you *do* have a channel you can use
to exchange secrets, you can also use it to exchange asymmetric keying
material, so to a first order any symmetric-only topology can be
converted into an asymmetric one.

The typical cases where people want to use symmetric-key only
protocols fall into a number of categories:

- Performance (e.g., TLS w/ PSK) because asymmetric protocols
  are slower and consume more bandwidth.

- Manual configuration, because you can provision one key
  that is shared rather than one key in each direction
  (though note that even in mostly manual settings like SSH
  asymmetric protocols are in wide use).

I'm leaving aside PQC for the moment, but will get back to this later.

In the majority of cases, it is most convenient to use asymmetric key
based key establishment protocols, which is why they are in such wide
use in IETF. DSKE isn't useful in that setting.

It's true that there are cases where people are provisioning symmetric
keys (often manaully). As noted above, one major draw here is that
it's lightweight, which is at odds with having to implement something
like DSKE, which is anything but lightweight. I'm sure there are cases
where people want to provision a lot of keys. You mention below the
example of enterprise key provisioning, which is an example of part
(1) of DSKE, but in these contexts the natural way to do this would be
via some existing provisioning system (e.g., YANG). So, again, I don't
really see that DSKE is useful here.

This brings us to the case where the endpoints are not centrally
managed (e.g., they are operated by different entities), but you still
need provisioning at scale. At the moment, these use cases are
typically handled with asymetric systems, and I don't see much
evidence that it makes more sense to move to a system which
distributes symmetric keys as in part (1). But even if this is the
case, the natural way to do this is with existing security protocols,
e.g., connect to the hub over TLS and ask it for a PSK share suitable
for the recipient. This is far easier than having to manually
establish shared keying material with the hubs, so I don't see how it
motivates part (2) of DSKE.


## Quantum Computers

The main motivation your draft offers for an all symmetric system is
resistance to quantum computers. However, we already have
cryptographic algorithms which are intended to be resistant to quantum
computers but which otherwise behave much like our existing asymmetric
algorithms. At least in the case of key establishment [0] these
algoriths are being rapidly deployed in IETF protocols, and it's
proven to be reasonably non-disruptive. By contrast, DSKE would be
hugely disruptive. It's perfectly fair to make the argument that you
don't trust PQC algorithms and so people should do DSKE, now matter
how disruptive, but absent that, it's hard to understand what the case
for DSKE is for of protection against quantum computers in the
majority of cases.


> >  # DEPLOYMENT MODEL
> > At a high level, the cryptographic protocols established by IETF
> > mostly operate with two main key management models:
>
> Is this not making the mistake of saying that it is not the solution
> of choice for "most IETF protocol uses"?  Isn't the more appropriate
> framing that SKEX might address cases where the existing protocols do
> not do well?
>
> You also say that IETF includes PSKs, and that this is clunky, but
> seem to imply that SKEX does not make this work better.  You have not
> justified this. It can, for example with some enterprise networks,
> lead to 1000-fold cost-, convenience-, and setup latency improvements
> over naive manual PSK distribution, while solving some real problems
> with manual PSK distribution (e.g. scaling limitations, slow cycling,
> forgotten keys, forward secrecy).  Aside from isolated point-to-point
> connections (without scope for extension to a mesh topology), SKEX
> protocols are likely to be superior to "existing" protocols in
> multiple dimensions: complexity. maintainability, security, ...

Well, it's really your burden to show that SKEX does, not mine to show
that it doesn't, and I'd have to hear more about the use cases you
propose. However, as I said above, even if it is the case that
widespread distribution of symmetric keys is better than normal
asymmetric key establishment, I don't think this motivates the design
you've proposed here; just provision those keys using protocols that
run over our normal security mechanisms.


> > ## Asymmetric Key Management
>
> You are evidently thinking of a deployment of TLS being in the
> anonymous client-to-server communication model that anyone can join.

Well, that in fact is the dominant mode of TLS. But it's also the
case when the client and server mutually authenticate with certificates.


> This is not a fair case, as this is a specific model in which PKI
> excels and to which SKEX might not be well-suited.  TLS can be
> deployed in many other scenarios, and can consume PSKs, but in this
> context is just an example; IPsec is often used with PSKs and presents
> a clearer example of a SKEX use case.  The scenarios that we are most
> interested in is where the existing protocols are not adequate.

See above.


> > ## Manual Key Management
> > However, it's not clear to me why SKEX is the
> > right answer here: presumably in those cases someone has already
> > worked out how to provision the keys using existing protocols
>
> Such a presumption needs justification.  There may be patchwork
> solutions, but just because we might assume that in each case someone
> might have devised a workaround, is no reason to say that establishing
> a standardized solution is not needed.  That is like saying that just
> because presumably people must have worked out how to transfer files
> over modems that we did not need IP protocols or file transfer
> protocols.

I addressed this in detail above.


> > # Information Theoretic Security
> > For example, if you use DSKE to establish a 256-bit
> > key which you then feed into the TLS key schedule and then use TLS to
> > encrypt 8K of data, this doesn't provide information theoretic
> > security
>
> Well, yes, the DSKE key is information-theoretically secure when
> considered in isolation, but it is not used in an
> information-theoretically secure manner.  If information-theoretic
> security is desired, one need only use 8 kilobyte of key to
> OTP-encrypt an 8 kilobyte plaintext, and a further 32 bytes of DSKE
> key for an information-theoretically secure authentication of the
> message.  DSKE can, on demand, readily provide megabytes or gigabytes
> of key material for one-time use.  I don't expect anyone to be
> interested in information-theoretic security at IETF, however.

Interested or not, it's irrelevant because none of the settings
under discussion are going to use DSKE in an information-theoretic
secure fashion.

-Ekr


[0] Signature is obviously lagging because ML-DSA is not a great
replacement for EC signature algorithms in many cases; however the
deployment problems for DSKE far exceed those of ML-DSA.

On Sat, Mar 15, 2025 at 7:41 AM Manfred von Willich <[email protected]<mailto:[email protected]>> wrote:
Eric:

Some responses.  I will be very selective so as to avoid an overlong reply, but the TL;DR is that you seem to be thinking of SKEX as being proposed as a drop-in proposal for existing established protocols for primary uses cases only, which misses the point: SKEX tries to solve problems that PKI and PQC do not solve well.


>  # DEPLOYMENT MODEL
> At a high level, the cryptographic protocols established by IETF
> mostly operate with two main key management models:

Is this not making the mistake of saying that it is not the solution of choice for "most IETF protocol uses"?  Isn't the more appropriate framing that SKEX might address cases where the existing protocols do not do well?

You also say that IETF includes PSKs, and that this is clunky, but seem to imply that SKEX does not make this work better.  You have not justified this.  It can, for example with some enterprise networks, lead to 1000-fold cost-, convenience-, and setup latency improvements over naive manual PSK distribution, while solving some real problems with manual PSK distribution (e.g. scaling limitations, slow cycling, forgotten keys, forward secrecy).  Aside from isolated point-to-point connections (without scope for extension to a mesh topology), SKEX protocols are likely to be superior to "existing" protocols in multiple dimensions: complexity. maintainability, security, ...


> ## Asymmetric Key Management

You are evidently thinking of a deployment of TLS being in the anonymous client-to-server communication model that anyone can join.  This is not a fair case, as this is a specific model in which PKI excels and to which SKEX might not be well-suited.  TLS can be deployed in many other scenarios, and can consume PSKs, but in this context is just an example; IPsec is often used with PSKs and presents a clearer example of a SKEX use case.  The scenarios that we are most interested in is where the existing protocols are not adequate.


> ## Manual Key Management
> However, it's not clear to me why SKEX is the
> right answer here: presumably in those cases someone has already
> worked out how to provision the keys using existing protocols

Such a presumption needs justification.  There may be patchwork solutions, but just because we might assume that in each case someone might have devised a workaround, is no reason to say that establishing a standardized solution is not needed.  That is like saying that just because presumably people must have worked out how to transfer files over modems that we did not need IP protocols or file transfer protocols.


> # Information Theoretic Security
> For example, if you use DSKE to establish a 256-bit
> key which you then feed into the TLS key schedule and then use TLS to
> encrypt 8K of data, this doesn't provide information theoretic
> security

Well, yes, the DSKE key is information-theoretically secure when considered in isolation, but it is not used in an information-theoretically secure manner.  If information-theoretic security is desired, one need only use 8 kilobyte of key to OTP-encrypt an 8 kilobyte plaintext, and a further 32 bytes of DSKE key for an information-theoretically secure authentication of the message.  DSKE can, on demand, readily provide megabytes or gigabytes of key material for one-time use.  I don't expect anyone to be interested in information-theoretic security at IETF, however.  Highlighting that it is is just a way of saying that the cryptography is not something to be concerned about in our discussions.  That this assurance extends to the future, regardless of classical or quantum computer advancements, is a bonus, and is of particular value for long-life data and critical infrastructure, since it is not guaranteed with PQC only.

Manfred


On Fri, Mar 14, 2025 at 12:49 PM Eric Rescorla <[email protected]<mailto:[email protected]>> wrote:
In preparation for the SKEX box, I've reviewed the charter for SKEX as
well as both draft-mwag-dske-01 and draft-dkls-ukse. These leave me
with a number of concerns about deployment model and practical
viability.


# DEPLOYMENT INTEREST
My first concern is about actual level of interest. SKEX is a protocol
that allows for the establishment of symmetric keys which then are to
be used by other protocols (in this respect it is conceptually like a
cryptographic algorithm). I'm not seeing a lot of evidence of that,
and I think there are technical reasons to be concerned about SKEX's
suitability for these applications (see below). In the case of this
kind of protocol, it's really not sufficient for there to be interest
by the developers in standardizing it, because it's not useful in
isolation.

Thus, I think a threshold question to any consideration of WG
formation should be to establish that there is real interest in
deploying SKEX from the community of protocols which would consume it.


# DEPLOYMENT MODEL
At a high level, the cryptographic protocols established by IETF
mostly operate with two main key management models:

- Asymmetric key agreement, with authentication supplied by one
  or more of the following mechanisms:
  - Some trust hierarchy such as the WebPKI or DNSSEC/DANE
  - Automatic or manual out of band exchange of public keys (e.g.,
    WebRTC, PGP)
  - Trust on first use (e.g., SSH)
- Shared symmetric keys established in some out of band fashion,
  typically manually.

Obviously, manually shared symmetric keys are clunky, which is why the
vast majority of IETF crypto uses some form of asymmetric key
management, even in unauthenticated settings.

The charter text seems to propose two theories about what SKEX is
for:

- Adding quantum resistance to protocols which already use
  asymmetric encryption (e.g., for TLS)
- Making manual key management work better (it mentions TCP-AO)

Unfortunately, SKEX, as described, doesn't seem to me to fit neatly
into either setting.


## Asymmetric Key Management

As noted above, the basic design of SKEX is that it establishes an
out-of-band pairwise key between A and B. The idea seems to be that
that key can then be used in the existing PSK modes of protocols such
as TLS. This can probably work in some technical sense, but I don't
think is compatible with deployment reality, at least for TLS, for
several reasons:

1. In practice, TLS authentication is generally tied to the domain
   name of the server via the WebPKI, so as a practical matter what
   you're doing is standing up the security hubs as some sort of
   alternate PKI. This would in practice require an enormous amount of
   governance work to determine how that new PKI operates (e.g., what
   does audit look like, does it do transparency?). I am skeptical
   that CABF or anyone else is going to want to do that.

2. In the majority of uses of TLS, the server is authenticated via
   some global credential (e.g., a certificate) but the client is
   anonymous at the TLS layer. This enables clients to spontaneously
   talk to any server. A protocol like SKEX would require every client
   (user) to get out of band keying material with Security Hubs prior
   to being able to use it.  This is a huge regression from being able
   to download a browser and just connect.

3. A production TLS installation will have a large number of servers
   spread across geographic regions. Having a single key that the
   client shares with all of those servers is an extremely challenging
   proposition. Operational uses of PSKs for TLS tickets take this
   into account by allowing for the server to forget the ticket, but
   that won't work with the way SKEX seems to be specified, because a
   forgotten key means you're not getting CRQC resistance. I could
   imagine addressing this with some kind of Kerberos-style integration
   where the CH contained enough information to establish the key,
   but that's different from what seems to be contemplated
   in S 11.4.

I know less about the deployment practices of other protocols than
TLS, but my sense is that the situation is broadly similar in many
respects.

I think there's wide agreement that resistance to quantum computers is
an important objective, but the primary alternative to SKEX is to
replace existing (largely EC-based) key establishment mechanims with
PQC algorithms. This is far more technically straightforward than
something like SKEX and is already underway for many of our
protocols. Moreover, it has superior security properties because
compromise of the CA does not allow for passive traffic decryption and
there are mechanisms like CT that assist in detecting misissuance.
For these reasons, I am skeptical that SKEX is a viable method for
adding CRQC resistance to IETF protocols.


## Manual Key Management

As a general matter, manual key management has a variety of
operational and scaling issues, which is why its use is limited to
settings where it's relatively straightforward to provision the keys.

It's possible that there are protocols which for some reason
(performance?)  don't do asymmetric key management, and in some
settings it might make sense to have a protocol of some kind to
provision the keys. However, it's not clear to me why SKEX is the
right answer here: presumably in those cases someone has already
worked out how to provision the keys using existing protocols (TLS,
SSH, etc.). And if you want CRQC-resistant provisioning, the natural
thing to do is to make those protocols use PQC, as noted above.



# Information Theoretic Security

As an aside, the DSKE document makes a number of claims about
information theoretic security:

   DSKE can be proved to achieve information-theoretical security, and a
   very high level of scalability, both discussed in detail in this
   document.  Other advantages include computational efficiency and
   potentially the limited amount of code needed to implement DSKE,
   reducing the surface attack.

This document does't provide a sufficiently complete description of
DSKE for me to evaluate this, however, it's not clear to me how
helpful this is. For example, if you use DSKE to establish a 256-bit
key which you then feed into the TLS key schedule and then use TLS to
encrypt 8K of data, this doesn't provide information theoretic
security because the attacker can exhaustively search the key space
until they find a key which correctly deprotects the traffic (where
correctly is defined as AEAD succeeds).

-Ekr



















--
skex mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]