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

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]