[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]> 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]> 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]
>> To unsubscribe send an email to [email protected]
>>
>

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