Is it possible to create a ciphersuite for TLS 1.3 using only the Keccak-sponge/duplex?

Question

Now that Keccak has been chosen as SHA-3 we see that there have been defined quite a few related modes, including authenticated cipher modes, the KMAC message authentication mode, XOF's and whatnot. However, it is unclear to me how much this fills all the gaps for symmetric cryptography. Could we for instance define and implement a TLS 1.3 cipher suite to use just constructions solely based on the Keccak-sponge/duplex as primitive? Simple bit operations and loops are of course permitted to tie everything together.

So besides KMAC we'd likely need to have a well defined and preferably standardized KDF and a secure random number generator (preferably one that can be reseeded). Additional points go to the answer that also manages to indicate a method of authentication (hash-based signatures?) and, possibly more tricky, a key agreement scheme to replace (EC)DH.

Answer 1

First for the scope of such a ciphersuite, to quote RFC 8446 Section B.4:

A symmetric cipher suite defines the pair of the AEAD algorithm and hash algorithm to be used with HKDF.

Now to the first question:

Could we for instance define and implement a TLS 1.3 cipher suite to use just constructions solely based on the Keccak-sponge as primitive?

With the above definition of what a cipher suite is, this seems easy enough, we just pair either of Keyak or Ketje with SHA-3 or KangarooTwelve. One of the first two mentioned AEAD schemes would be mostly used for bulk encryption and one of the latter two hash functions via HKDF for key derivation. I'm not sure how much customization TLS 1.3 allows but it might also be possible for an RFC to define Keccak based ciphersuites to use a different KDF than HKDF, though this would most likely lower acceptance.

Additional points go to the answer that also manages to indicate a method of authentication (hash-based signatures?)

Indeed it would be possible to use either of the hash-based NIST PQC Round 3 Alternative candidates for this. In fact Picnic is already based on Keccak (and LowMC to build a MPC-based signature scheme). Additionally SPHINCS⁺ is also specified for SHAKE-256 for the NIST PQC.

and, possibly more tricky, a key agreement scheme to replace (EC)DH.

Constructing key agreement (or public-key encryption) from hash functions is very unlikely even for theoretical constructions (assuming collision-resistance). It is very much impossible to do so generically only assuming the existence of black-box One-Way-Functions as shown by Rudich and Impaglazzio in STOCS 1989's "Limits on Provable Consequences of One-way Permutations" (PDF).

Answer 2

I'm personally optimistic that in the future, once we found a wide permutation of sufficient efficiency, we'll be more motivated to define internet protocols (for example, TLS 1.4 or 1.5) to be parameterized exclusively by the permutation it uses.

Following the format of the answer by SEJPM,

A symmetric cipher suite defines the the pair of the AEAD algorithm and hash algorithm to be used with HKDF.

First, the AEAD algorithm can and have already had been defined in terms of a mode of operation of a permutation.

Secondly for key derivation, it's the hash algorithm to be used with HMAC for instantiating HKDF. As already noted in the OP, there's already KMAC. HMAC requires at least 2 invocations of the hash function, so it's plausible we may want to replace it with special designs that're specific to the underlying primitive to obtain more efficiency - for example, KMAC as in the case of Keccak, or Keyed BLAKE2 in the case of ChaCha (the latter of which is unlikely since the ChaCha function is slightly different for the cipher and for the hash).

Thirdly, we may not need dedicated MAC if we can prove the tag of the AEAD algorithm is computationally random, and can obtain arbitrary-length tag from it. In this case, even the HKDF construction is partially redundent, as in the extract and expand steps are preserved, but they no longer rely on MACs.

Additional points go to the answer that also manages to indicate a method of authentication (hash-based signatures?)

Of course hash-based signatures. As already mentioned by SEJPM, Keccak-based hash functions had already been proposed to instantiate the SPHINCS+ signature. What I'd like to add, is that the actual SPHINCS+ and its underlying XMSS and WOTS signatures rely on randomized and parameterized hashing to reduce the size of the signature, these signature schemes may benefit from hash functions instantiated from e.g. TupleHash as specified in NIST SP-800-185 in terms of performance and bandwidth efficiency.

Also, there's the stateful hash function that are slightly more efficient than the stateless ones. According to NIST, they intend to approve stateful hash signatures in some applications, including for example: code signing. Similar applications could potentially include OCSP the Online Certificate Status Protocol, and CRL the Certificate Revocation Listing, as these data change much slower than ephemeral key-exchange public keys.

and, possibly more tricky, a key agreement scheme to replace (EC)DH.

I agree with SEJPM in that asymmetric key exchange is improbable with hash functions, or symmetric-key primitives in general.

While TLS do have the option to use Kerberos for handshake, after quickly going through RFC 4120 and IANA registery for Kerberos 5, I realize that Kerberos is a protocol with so many legacy artifacts that, if we were to advocate Keccak for the protocol, it would cause massive incompatibility and interoperability problems with existing implementations.

The idea of Kerberos is still applicable, in that in a large network, KDC can maintain a database of keys for the nodes in the network, and lifts from each node the burdon of maintaining PSKs for all peers.