Summary

  • draft-ietf-tls-pake-02 allows a server to send a plausible PAKE response even when no registration record exists, so ServerHello proves neither account existence nor successful password authentication.
  • Client authentication completes only when the server validates the client's Finished; certificate identity, application authorization and protection of a long-lived password against future quantum recovery remain separate questions.

The client named an account that had never been registered. The server still selected a password-authenticated key-exchange scheme, returned a well-formed share and continued the TLS handshake.

That was not a database error. It was the privacy feature.

draft-ietf-tls-pake-02 proposes a generic extension for using low-entropy secrets such as human-entered passwords with TLS 1.3. Revision 02 was published on 6 July 2026 and expires on 7 January 2027. It is an active TLS Working Group Internet-Draft labelled Informational, not an RFC, completed IANA registry, deployment report or security certification. Its introduction says the work has not yet seen significant security analysis. Those boundaries matter because the draft changes what familiar TLS milestones can be allowed to mean.

A password is not an ordinary PSK

TLS 1.3 already supports pre-shared keys, but its binder exposes a test that assumes the key has full entropy. A human password placed directly into that mechanism gives an observer material for dictionary testing. The proposed pake extension instead carries messages from a password-authenticated key exchange, derives a strong shared secret and joins that secret to the ordinary TLS key schedule.

The design still requires supported_groups and key_share. Password knowledge is not used as a substitute for forward-secret key exchange. A client can offer several PAKE schemes, but the shares must be distinct and sorted. The same client and server identity pair applies to every offered share, reducing scheme-dependent identity probes.

This makes “PAKE supported” an incomplete operational label. Support has at least four dimensions: which scheme was offered, which scheme was selected, which registration form that scheme requires, and which authentication mode the server chose. A common algorithm does not imply a common record.

The server may answer without a record

After selecting a mutually supported scheme, the server uses the PAKE client_identity and server_identity to locate registration material. If no legitimate record exists, the draft permits a simulated response. The server chooses a plausible share, sends it in ServerHello and proceeds as though the lookup had succeeded.

The client cannot derive the same secret, so its Finished will fail with overwhelming probability. The goal is to prevent a probe from learning account existence merely by comparing the server's first response for a known and unknown identity.

That design reverses a common observability assumption. In many handshakes, a negotiated extension and server share are logged as proof that a feature and credential path were accepted. Here the server intentionally creates that appearance for a nonexistent account. The ServerHello is evidence of a selected protocol branch, not a registration receipt.

Simulation also shifts the security burden into implementation details the wire format cannot prove. Timing, alerts, packet sizes, CPU work, rate limits, audit events and backend calls must not quietly distinguish “unknown identity” from “wrong password.” A syntactically identical response does not establish indistinguishable side effects.

Finished is the client-authentication boundary

The PAKE secret feeds the TLS 1.3 key schedule alongside the ordinary ephemeral key exchange. Server and client then confirm the transcript through Finished messages. From the server's perspective, the client is not authenticated until the client's Finished validates.

The draft consequently says the server should not send application data before receiving that message. A system that releases an account profile, authorization hint or secret configuration after its own ServerHello has confused cryptographic progress with authenticated client possession.

Even a valid Finished has a narrow meaning. It binds key knowledge to this handshake transcript under the selected mode. It does not prove the legal identity of the person, the integrity of the device, the validity of the original registration ceremony, current account authorization or the success of a later business action. Those decisions occur outside the handshake.

An incident ledger therefore needs distinct states: scheme negotiated; registration path real or simulated; server Finished verified by client; client Finished verified by server; application data released; authorization granted; requested action completed. Collapsing them into login_success=true destroys the control boundary the protocol is trying to create.

PAKE identity, SNI and certificate identity are different

The draft says the PAKE server_identity is disjoint from Server Name Indication. That is not a naming detail. SNI routes a connection and can participate in certificate selection; the PAKE identity indexes cryptographic context and registration. The strings may look alike while being governed by different systems.

A client can also send signature_algorithms with PAKE. If the server selects PAKE in that case, it must send Certificate and CertificateVerify. This produces PAKE-plus-certificate authentication. Without that request, PAKE can authenticate password knowledge without making the same PKI-backed server-name claim.

Products must say which mode ran. “Mutually authenticated TLS” is too broad if the audit record cannot show whether the server was authenticated by the PAKE context, a certificate reference identity, or both. Nor may certificate validation promote the PAKE client label into an authorized account. Each claim needs its own policy owner.

External PAKE needs a second receipt

Internal PAKEs fit their exchange into ClientHello and ServerHello. The draft also describes external PAKEs whose extra rounds occur before TLS. Their resulting secret is imported as an external PSK under RFC 9258 and then used by an ordinary TLS PSK connection.

That architecture creates a join. The application must retain which external transcript produced which imported identity, how peer roles and channel context were bound, and which later TLS connection consumed it. A successful PSK handshake proves possession of the imported key. It cannot reconstruct whether the earlier PAKE contacted the intended peer, used the intended identities or was paired with the correct connection.

RFC 9258 helps domain-separate imported keys by protocol, KDF and context. It does not observe the application ceremony that supplied those inputs. If correlation logs are missing, TLS success is a receipt for the second half of an unproved chain.

Post-quantum traffic is not post-quantum password custody

The ordinary TLS key share may be hybrid or post-quantum. That can protect recorded application traffic from a future cryptographically relevant quantum computer. The draft warns that this does not automatically protect a classical PAKE transcript.

If a future machine breaks the classical assumption behind the selected PAKE, recorded PAKE messages may expose a reusable password even while the surrounding application ciphertext remains protected. The consequence is forward-looking: the recovered password can enable impersonation in future sessions until it is changed.

The document includes OQUAKE and OQUAKE+ paths and refers to a hybrid external design. Those dependencies are themselves active research drafts. They must not be marketed as settled, audited deployments. The durable governance lesson is simpler: record traffic-confidentiality posture and credential-recovery posture separately.

Registration remains outside the handshake

Every PAKE flow begins with prior state: a password or a derived verifier, client and server identities, salts, scheme parameters and an account lifecycle. The draft does not define how identity was proved during registration, how recovery works, who may reset a password, how records migrate between schemes or how old verifier material is destroyed.

A flawless handshake can therefore sit on a defective registration process. A help desk may have reset the verifier for the wrong person. A migration may retain an old record. An augmented PAKE may keep the password away from the server while still leaving a stolen credential file subject to offline dictionary work.

Protocol evidence cannot repair missing institutional evidence. The operator needs a versioned registration receipt, a scheme-migration ledger and an authorization record in addition to the transcript.

The useful outcome is a chain of bounded claims

The proposal is valuable precisely because it refuses to use a password as a raw TLS PSK and because it gives servers a way to avoid obvious account enumeration. Those advantages disappear when operators turn every intermediate green light into proof of identity.

Scheme selection proves compatibility. A simulated share preserves ambiguity. Finished proves transcript-bound key possession. A certificate can add a server-name claim. Authorization maps the authenticated principal to an action. An outcome record says what the application actually did.

Leadership should demand all of those states, with the modes and uncertainty attached. The most dangerous dashboard is not one that reports a failure. It is one that reports “account authenticated” at the exact stage designed to answer accounts that do not exist.

Sources