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: +49 7156 209 10377
[email protected] | 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 <[email protected]>
Gesendet: Montag, 17. März 2025 00:16
An: Rob Sayre <[email protected]>
Cc: Laura Bauman <[email protected]>; [email protected]
Betreff: [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre
<[email protected]<mailto:[email protected]>> wrote:
On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman
<[email protected]<mailto:[email protected]>> 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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
