Re: [lamps] [EXTERNAL] draft-ietf-lamps-lightweight-cmp-profile-05 concern

[Nick Lamb <[e-mail]>]

On Wed, 17 Mar 2021 15:42:40 +0000
Mike Ounsworth <[e-mail]> wrote:

> Hi Nick,
> 
> That's what PAKEs are for, right? If I'm following the TLS WG
> properly, the TLS 1.3 PAKE draft (draft-barnes-tls-pake) expired in
> 2019 and PAKEs did not make it into 1.3. Is that right?

I have replied (and I see someone else also replied) mentioning the
work to integrate OPAQUE. This may be too complicated for a
"lightweight" profile or it might delay publication unacceptably but
others will know better.


> Looking at Hendrik's slides and I-D, I see proposals for specifying
> TLS 1.2 and 1.3 PSK cipher suites. I also see in the draft:
> 
>    *  The client MUST use its shared secret information for
>       authentication.
>    *  The server MUST use a suitable shared secret information for
>       authentication.
> 
> Nowhere does it refer to this shared secret as a "password".

When I examine these slides
https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-lightweight-cmp-profile-updates-cmp-and-cmp-algorithms-00

Or I review the video on which I was commenting:
https://youtu.be/DQQ4h_M1XYM?t=4453

I see that page 9 explicitly refers to passwords - writing
"We would like to specify suitable TLS cipher suite for use with
pre-shared secret information, e.g., passwords"

So it seems to me that in fact it does exactly what you've said it does
not.

It is a problem that so often a value envisioned as a 128-bit PSK -
which would be safe for many purposes ends up implemented in real
systems as a human readable password - which is much too fragile; and
then actually used as a boilerplate value (ie users don't know why it's
supposed to be a high entropy secret so they write the name of the
company or something) and as a result a cast iron security
guarantee in the design becomes so flimsy as to have no value in real
usage.

Nick.