Summary

  • The Datatracker moved draft-ietf-lake-edhoc-psk to WG Consensus: Waiting for Write-Up on 8 September 2026; revision 09 was posted later that day. It remains an Internet-Draft, not an RFC or IESG-approved standard.
  • Revision 09 says one ID_CRED_PSK value may retrieve more than one candidate PSK and associated credential set. The responder tries candidates until authenticated decryption succeeds or the set is exhausted.
  • Compactness and key overlap are easier, but a log containing only the received identifier can no longer establish which credential context authenticated the peer.
  • Daniel Kade proposes recording a non-secret candidate-set version, selected credential version and attempt outcome. That is editorial analysis, not a requirement in the draft.

On the wire, nothing needs to look like a list. The initiator places ID_CRED_PSK in the protected part of EDHOC message 3. It may be as small as a COSE kid. The responder receives that value and uses it as a local retrieval key. The list appears only after the lookup.

That distinction became explicit in revision 09. The new text says the identifier can retrieve one or more PSKs and the information required to process EDHOC. One value may correspond to several candidate PSKs and associated credentials. In message-3 processing, the responder selects the first candidate, derives K_3 and IV_3, and attempts authenticated decryption of CIPHERTEXT_3B. If verification fails, it tries another candidate. Exhausting the set produces the failure; a successful check establishes possession of the PSK in the selected candidate.

This is a material change from revision 08. The earlier version described the field as a way to retrieve “the correct PSK” and recommended unique or stochastic identification partly to avoid ambiguity and the need to try several keys. The official comparison turns that previously avoided condition into specified processing. The recommendation for a unique or stochastic PSK context remains; uniqueness is now the efficient case, not the only conforming lookup shape.

The lookup result is a credential context

Calling the candidates “keys” is convenient but incomplete. The draft says the retrieval result includes the PSK, CRED_I, CRED_R and associated processing information. Those credentials carry the identifying context for the initiator and responder. They must be distinct, a rule connected to reflection and misbinding protection. The candidate also has to fit the hash algorithm of the selected cipher suite. A responder is therefore not merely cycling through interchangeable byte strings. It is testing complete authentication contexts against one protected message.

The base EDHOC specification, RFC 9528, already separates compact credential references from the credentials they retrieve. The PSK extension makes that separation more consequential because several local contexts can now stand behind the same received reference. COSE, RFC 9052, deliberately treats kid as an identifier rather than a globally unique name. CWT, RFC 8392, supplies one possible representation for the associated claims. None of those layers makes the short identifier a proof of identity by itself.

The security boundary also excludes a tempting but false analogy. Candidate trial is not permission to search a password dictionary. Revision 09 requires an external PSK to contain at least 128 bits of entropy and be at least 128 bits long; it says a password or other low-entropy source is not secure. The candidates are provisioned authentication contexts that happen to share a lookup handle.

The obvious benefit is controlled overlap

The draft does not prescribe why an implementation would keep several candidates. The operational uses are easy to infer but must remain labelled as inference. A fleet may be crossing a key-rotation boundary. Two provisioning systems may briefly disagree about which version is current. A compact identifier space may be reused within partitions that the responder joins. A recovery process may retain an older context while a replacement is being confirmed.

These arrangements can preserve availability without putting a larger identity object on a constrained link. They also move policy into the responder’s table. Candidate membership, order, retirement and maximum set size are invisible to the initiator. Two responders can accept the same message under the same wire identifier while reaching the successful candidate at different positions. If both log only ID_CRED_PSK, their records look identical even though their credential state is not.

That is the governance issue. The protocol result—authenticated or rejected—is real. The identifier is real. But neither record alone describes the local selection that joined them. Treating the short identifier as if it uniquely named the accepted credential would turn a retrieval hint into a stronger fact than the draft gives it.

Last Call closed; publication did not

The process state needs the same discipline. The Working Group Last Call notice and review thread set a 1–15 July review window for revision 08. In the archived discussion, reviewers proposed the candidate-selection steps that appear in revision 09, including trying a new candidate after failed AEAD verification. On 8 September, the Datatracker history records the transition from Last Call to WG Consensus: Waiting for Write-Up, the appointment of a document shepherd and the posting of revision 09.

That is progress, not finality. The current document record identifies an active LAKE Working Group draft intended for the Standards Track. A shepherd write-up, IESG review, possible further revisions, approval and RFC publication remain separate states. Implementers can test revision 09 now; they should not report an RFC number or settled IETF requirement that does not exist.

Record the selection without exposing the secret

A proportionate operational record does not need PSK bytes or a public identity. It needs enough non-secret state to answer a later question: which local credential context did this responder accept for this lookup?

For an accepted exchange, that could mean a fingerprint of the received ID_CRED_PSK, a version or digest for the candidate set, the candidate count, the selected non-secret credential version, the EDHOC suite and hash context, the number of attempts, the outcome, a policy version and a timestamp. For an exhausted lookup, the same shape should show that no candidate verified without revealing the candidates. Operators can aggregate latency and exhaustion by candidate-count band rather than publishing per-device identity.

This record would also make rotation safer to reverse. If success begins moving from candidate one to candidate two, the operator can see whether a rollout is progressing or whether stale state is becoming permanent. If different responders expected to share policy report different set versions, the inconsistency is visible before an incident is reconstructed from vague “PSK failed” messages.

The proposal is not part of revision 09. The draft specifies the cryptographic processing, not this audit schema. That division is reasonable. The mistake would be to let a newly plural lookup keep being logged as though it were singular.

Sources