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

[Eric Rescorla <[e-mail]>]

On Mon, Mar 24, 2025 at 5:17 PM Martin Thomson <[e-mail]> wrote:

> On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote:
> > 1. Getting PQ resistance for free even with non-PQ PAKEs.
> > 2. Reducing the combinatoric explosion of "groups"
>
> I don't know that you are really getting PQ resistance if your PAKE
> remains vulnerable.  You might maintain confidentiality for that single
> connection, but if there is a possibility of impersonation (are you relying
> on the PAKE for authentication of the server?) then you lose.
>

This is what we are doing right now by rolling out PQ for key establishment
but not for authentication:
we provide security against harvest now decrypt later attacks, but not
against impersonation if there
is a CRQC.


Avoiding the combinatoric problem seems like a pretty high complexity tax.
> Sure, we are already in the position where we have N (number of ECC groups)
> x M (number of PQ groups) groups.  Adding a PAKE makes that N x M x P
> (number of PAKEs).  However, these are all small numbers.  Building a
> parallel extension is relatively straightforward if you model it like key
> exchange and use the obvious combiner.  But then, why did we not do that
> with PQ as well?
>

I agree it's a judgement call, but IMO PQ key establishment via KEMs is
more like DH
key establishment than PAKEs are. For instance, neither needs to connect
with some
password database.

For this reason and others,it's not clear to me that in fact it will be
simpler to have
combined PAKE + ECC + PQ groups than to have the PAKE be separate.

-Ekr