4

In TLS 1.2, there was TLS-SRP (RFC 5054,) which provided a password-authenticated key exchange (PAKE) protocol for use with TLS. However, it apparently relied on handshake messages that have been removed from TLS 1.3 and, thus, is not applicable to TLS 1.3. TLS 1.3 does still support the PSK-DHE handshake, but it doesn't provide PAKE properties since it allows offline brute-force attacks. It appears that there was a proposal to add a PAKE extension for TLS 1.3 back in 2018, but the draft appears to have expired and I haven't seen why it was allowed to expire or if anything further came of it.

Has anything been done since then to add PAKE support to TLS 1.3? Are there any active proposals?

Community
  • 1
reirab
  • 175
  • 10

2 Answers2

3

Has anything been done since then to add PAKE support to TLS 1.3? Are there any active proposals?

No, nothing has been done, and there are no active drafts.

One possible reason for this (I don't know if this is the reason; it sounds plausible to me) is that the TLS working group is waiting for the CFRG [1] to complete its study of PAKEs; the CFRG is mostly done; they have selected OPAQUE as the recommendation if you need an asymmetric PAKE (the server doesn't need to know, which fits how TLS would use it) [2], however just selecting the winner is not sufficient - they need to put together an RFC that explains exactly how to use it (and how to avoid various subtle pitfalls).

Once the CFRG has put together such an RFC, I would expect that a proposal to use it within TLS will be submitted (of course, you are welcome to submit such a proposal)

[1] The Crypto Forum Research Group; that's a group whose purpose is to make recommendations about cryptography to the various IETF working groups

[2] And the winner in the symmetric case would be CPACE; however that is less likely to be used in TLS, as it requires the server to have a copy of the password

poncho
  • 154,064
  • 12
  • 239
  • 382
1

Since posting the question, I became aware of TLS-PWD, defined in RFC 8492, which uses the Dragonfly PAKE (RFC 7664) and does define support for both pre-1.3 TLS and TLS 1.3.

I'm currently (as of Jan 2021) not seeing implementations of the the TLS-PWD cipher suites in common TLS implementations, though, so poncho's answer still appears to be correct as far as practice is concerned. However, I decided to add this answer in case it might help someone later if/when libraries implement the TLS-PWD cipher suites.

The TLS-PWD cipher suites are prefixed with TLS-ECCPWD:

  • TLS_ECCPWD_WITH_AES_128_GCM_SHA256
  • TLS_ECCPWD_WITH_AES_256_GCM_SHA384
  • TLS_ECCPWD_WITH_AES_128_CCM_SHA256
  • TLS_ECCPWD_WITH_AES_256_CCM_SHA384
Community
  • 1
reirab
  • 175
  • 10