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

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

Actually, there is new work attempting to integrate Opaque (an augmented PAKE) into TLS - https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/

This was discussed in the TLS WG meeting; I believe they intend to integrate this into TLS at some point...

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
> Sent: Wednesday, March 17, 2021 11:43 AM
> To: Nick Lamb <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [lamps] [EXTERNAL] draft-ietf-lamps-lightweight-cmp-profile-05
> concern
> 
> 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?
> 
> 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". I assume this
> shared secret will be some kind of registration code that a PKI operator
> distributes out-of-band to the end entity requesting the certificate? Seems a
> bit out of scope for a CMP RFC to put constraints on how that is generated.
> 
> So I suppose this email thread boils down to a request to add a "garbage-in,
> garbage-out" security consideration statement to the draft that a low
> entropy shared secret will result in a low entropy TLS session?
> 
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Nick Lamb
> Sent: March 16, 2021 11:20 AM
> To: [e-mail]; [e-mail]
> Subject: [EXTERNAL] [lamps] draft-ietf-lamps-lightweight-cmp-profile-05
> concern
> 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> 
> __________________________________________________________
> ____________
> Hi
> 
> I am not a LAMPS working group member, but I watched a video of the
> presentation of this ID at IETF 110 on Youtube.
> 
> I noted with concern that the presenter suggests TLS 1.3's PSK modes are
> suitable for use with a password.
> 
> This is _explicitly_ not the case. To quote RFC 8446:
> 
> "Deriving a shared secret from a password or other low-entropy sources is
> not secure.  A low-entropy secret, or password, is subject to dictionary
> attacks based on the PSK binder.  The specified PSK authentication is not a
> strong password-based authenticated key exchange even when used with
> Diffie-Hellman key establishment."
> 
> If CMP or LAMPS generally needs a way to use passwords to authenticate TLS
> it's worth reaching out to the TLS WG to ask them what you should do here,
> or contrariwise if this profile for CMP is to use PSKs it should likewise make
> explicit that you must not use passwords and similar human memorable low-
> entropy secrets.
> 
> Nick.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm
> __;!!FJ-Y8qCqXTj2!I5B4z3nBjk83j5emJqmOydz-
> dI4c_Lj4PXWDA4IItw2znDIALakjPklbFa0pKhZIf1rnybj-xQ$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm