[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

[Björn Haase <[e-mail]>]

Hi Laura, Hi all,

I plan to come up with a more detailed review of the draft this week together with description of the actual use-cases. In our company’s setting the main use-case for PAKE are customer-owned server devices that are not yet integrated in a PKI and yet not integrated with other authentication protocol ecosystems (such as OAuth).

One important use-case relates to networks that may be wire-gapped and air-gapped from central authentication server structures for extended times.

Also in our setting the most important aspect for use of TLS is used outside of the scope of browsers where the PAKE protocol component within TLS can be given direct access to some limited user interface for the purpose of authentication.

>Regardless of the point above, I do not believe this would work. You need some protocol to carry the PAKE information and if that's not going in the TLS >handshake, where is it going?

My main objection regarding the draft will boil down to the above conclusion by Eric. I believe that we need a mechanism to carry the PAKE protocol-variant specific information gets integrated as part of the TLS handshakes as only with this we will be enabling secure use of PAKE protocols such as OPAQUE or CPace. When preparing PAKE for TLS I think that we really should prepare the structure of the messages such that protocols such as OPAQUE and CPace are not effectively ruled out because information beyond “identity” identifiers needs to be exchanged or because “identity” identifiers such as server-identity identifiers might only become available after receiving the ServerHello.

Find below the P.S. a more comprehensive attempt of describing my ideas on how this could be made working.

Yours,

Björn



P.S.

This will mean that I believe that for viable integration into TLS we would have to prepare an internal PakeProtocolVariantComponent-To-TlsCoreComponent API structure.

I believe that similar to the actual specification on how to implement certificate trust chain evaluations on the client *for* TLS we would be having PakeProtocolVariantComponent somewhat separated from TlsCoreComponent part.

- In the API between the two components the PakeProtocolVariant component would be providing the shared session secret to the TlsCoreComponent after two flows and would also responsible for carrying out the PAKE-protocol equivalent of what is the “certificate trust-chain check” in PKI.

- The TLS core component would allow for PAKE-protocol-variant-specific payload fields in the client-hello and server hello messages and would be arranging for the bulk message payload encryption after successful authentication and shared session secret derivation.


Depending on the protocol type, the PakeProtocolVariant component might require to exchange  information which could be all of: “user names”, “PBKDF functions for memory-hard password-verifier hashing”, “OPRF challenge”, “Salt values used for PBKDF”, “OPAQUE AKE protocol variant” or “elliptic curve group choice” handshake information.


(Even if some of this pake-protocol-variant-specific information would benefit from encryption for some PAKE protocols, I believe that we might have to leave the implementation of an encrypted client hello outside of the scope of a TLS-PAKE extension and use mechanisms such as the existing “encrypted client hello” concepts if needed. In many settings clear-text transfer of the PAKE-protocol-specific information can be considered acceptable IMO, though.)


After thinking through design options I personally came to the conclusion that the theoretically possible approach of re-allowing arbitrary EAP subprotocols for this purpose -- such as was allowed in TLS 1.2 --  is not an advisable approach for TLS 1.3. I believe that this likely would become a nightmare regarding interoperability and also regarding security analysis regarding TLS1.3.

In order to avoid the issues that come with possibly overly flexible constructions such as EAP, I’d advocate to really concentrate on really *few* PAKE protocols for integration in TLS based on the actual use-cases. I am completely with Scott Fluhrer with the assessment that SPAKE2+ might not actually be the choice to recommend for TLS 1.3.

I believe that actually regarding the use-cases we might be having only two use-cases (balanced PAKE and augmented PAKE) and might actually only be recommending two or three PAKE protocols.


Regarding the interfaces between TlsCoreComponent and PakeProtocolVariant -modules:

I believe that for PAKE integration to TLS we need to prepare a more flexible mechanism for PAKE-protocol-variant meta-information *within* the client and server hello messages.

The requirement to impose for support for TLS integration regarding the PAKE protocol would be to request that after completing the client- and server-hello messages the shared secret for the session has to be established leaving only the final key confirmation by the client to the third message flow. I.e. we would be imposing the requirement that for suitability for TLS a PAKE protocol must not change the three-message-flow structure.

As different PAKE protocols will require *very* different information to be piggy-backed with the client and server hello messages the approach that I suggest is to allow for embedded container fields within the client and server hello messages which need to become PAKE-protocol specific and will have to contain all PAKE-protocol-variant specific parts. I would rather not recommend to consider flattening exchanged information already plainly as individual fields on the hierarchy level of the ClientHello and ServerHello such as suggested by the draft.

I.e. I believe that for a suitable TLS integration we rather should consider embed a pake-protocol-flavor specific data field into the ClientHello and ServerHello which bundles all required information for a specific PAKE protocol variant. I.e. one would be having something like the following:

ClientHello:
{
 Advertises support for PAKE protocols SPAKE2+ and OPAQUE,
CBorEncodedSpecificInformationForSpake2+ {IdentityFieldClient, SPAKE CurveGroupList, BlindedECDHPublicShareServerForPreferredCurve},
CBorEncodedSpecificInformaitonForOpaque{UserName, OPRF CurveGroup, OPRF challenge, AKE_Message1},
…
}

As a response servers supporting different protocol variants might respond either with

ServerHello-from-a-server-supporting-OPAQUE:
{
Support for PAKE protocol OPAQUE,
CBorEncodedSpecificInformationForOpaque{OPRF response, OPRF CurveGroup, PBKDF-Function to use for password verifier, Parametrization of PBKDF for memory hard hashing, Encrypted certificate, AKE_Message2},
…
}

or alternatively the response from a server supporting SPAKE2+ would look like

ServerHello-from-a-server-supporting-SPAKE2+:
{
Support for PAKE protocol SPAKE2+,
CBorEncodedSpecificInformationForSPAKE2+{IdentityFieldServer, CurveGroup BlindedECDHPublicShareServer },
…
}

Most probably for PAKE the protocol specific fields would best be encoded according to CBOR or DER encoding rules according to some schema as one embedded block and rather
not by using individual fields flatly on the level of the ClientHello and ServerHello.


So summing up: I believe that for a viable PAKE extension we need a general structure in TLS that first advertises support for a specific set of PAKE protocols in the ClientHello and where we prepare pake-protocol specific container fields embedded in the ClientHello and ServerHello messages. The draft should be specifying that after the Server-Hello messages both sides have the shared session key secret available and will provide authentication/identity information to both parties such that the PAKE equivalent of a “trusted certificate chain evaluation” for a PKI can be carried out.

I.e. the main change in the TLS specification might be that we more clearly define API interfaces between the
1) … authentication and shared session-secret establishment component and the …
2)  … bulk payload message authentication and encryption components working with the shared session secret …
where

PAKE may provide an alternative to ECDH and Certificates for component 1).

Already today’s component for 1) (ECDH and Certificates) interfaces to some component external to the TLS core component for the purpose of certificate-trust-chain data base access and trust-chain checks.

In the case of PAKE TLSO we would also have to interface to an external component, however in this case this might involve an interface to some user credentials database on the server side and a GUI component for the client side.

Yours,

Björn



Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone]
[e-mail] |  www.ehla.endress.com 





Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 



Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 



Von: Eric Rescorla <[e-mail]>
Gesendet: Montag, 17. März 2025 00:16
An: Rob Sayre <[e-mail]>
Cc: Laura Bauman <l_bauman=[e-mail]>; [e-mail]
Betreff: [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt



On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre <[e-mail]<mailto:[e-mail]>> wrote:
On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman <l_bauman=[e-mail]<mailto:[e-mail]>> wrote:
Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt and provided feedback so far. As more people start reading it, I wanted to clarify that the current draft version does not yet reflect the change we intend to make to allow Certificates and the pake extension to be used together. We’ve filed a GitHub issue here tracking our intent to change this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25.

I'm pretty sure this is not news to authors, but I've thought about this one before (when the IRTF was conducting their PAKE contest). It seems like using both PAKE and certificates together, in combination with "Sign In" products would be pretty powerful. I am not sure why this draft needs TLS extensions, and it doesn't cover the thorny problem of PAKE registration at all.

Leaving the question of registration aside, I don't believe that PAKEs are really viable in the Web context, for two reasons:

- Sites in general want to control the login experience and this means having the password typed in in a box they control, not in the browser UI, especially given the current terrible state of password UIs for browsers.
- In the phishing context, the attacker site can just prompt the user directly for their password or simulate the PAKE UI, thus bypassing the PAKE. The whole premise of phishing is that the user doesn't check carefully, so I don't think we can rely on users to detect this form of attack.

We already have phishing resistant authentication mechanisms such as WebAuthn which don't have this problem, so I think the motivation for PAKEs on the Web is pretty weak.


Couldn't it be click "Sign In", and start the TLS key schedule from there, instead of "0"? No extensions necessary.

Regardless of the point above, I do not believe this would work. You need some protocol to carry the PAKE information and if that's not going in the TLS handshake, where is it going?

-Ekr




I decided not to work on this problem, because I figured it would make a lot of people mad, and I didn't want to spend my time on it. But, might as well ask the question since we have this draft in front of us.

thanks,
Rob


_______________________________________________
TLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>