[saag] Initial thoughts on SKEX

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

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