Re: [kitten] complementary OPAQUE SASL mechanism draft

[Simo Sorce <[e-mail]>]

On Fri, 2022-10-14 at 20:48 +0200, Simon Josefsson wrote:
> Stefan Marsiske <[e-mail]> writes:
> 
> > this draft by far less ambitious than the other introduced a few days ago on
> > this list. this one only specifies a simple OPAQUE mechanism for SASL and
> > mostly only the wireformat. there is no channel binding, and no secure layer.
> > it also does not support cryptographic agility[1], similar to wireguard and
> > other modern solutions, eliminating footguns, negotiations and other
> > complexity. it only specifies one configuration, one of the two specified by
> > the IRTF CFRG draft[2] with one change, the usage of argon2i for the KSF
> > instead of scrypt (for which i have an issue open to change[3]).
> 
> <rant>
> 
> I really prefer this kind of security protocol design.  Experience with
> other protocols, and even SASL (remember DIGEST-MD5?), has shown too
> many times that negotiation and parameter choices is harmful to
> security.  I wish we made GS2 and SCRAM less complex.  I understand some
> poeple want to continue the practice for SASL mechanisms, given the
> responses on my suggestion to hard-code parameters for OPAQUE*.  However
> I think the arguments for kind of design are weak at this point.  It is
> easy to ask for an optional feature, and give some rationale for the
> request that makes sense in isolation, but the hard part of security
> protocol design is to say NO to that feature creep.  When we don't, we
> all end up with ASN.1/PKIX hell and it takes years to recover.
> Premature parametrization is the root of many security flaws.


OTOH lack of agility makes it extremely hard to handle operationally.

As much as agility makes things more complicated it also makes it
actually possible to do smooth transitions over large deployments.

Lack of agility forces into flag days which end up with excruciating
disruptions or loss of security.

That said,
the good thing about SASL is that it is itself a negotiation mechanism.
As long as the actual mechanism exposed in SASL has an algorithm
qualified name like "OPAQUE-foo" rather than just OPAQUE, upgrades will
be possible by simply supporting multiple OPAQUE-xyz mechanisms.

Regards,
Simo.
 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc