Re: [kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE

[Nadja von Reitzenstein Cerpnjak <[e-mail]>]

Hello Rick,

> Thanks for this specification!  Since Stef (who implemented OPAQUE
> for SASL) wrote a text before, I wonder if/how these attempts are
> best integrated.
>
> https://github.com/stef/sasl-opaque

I'm not quite sure. I've read Stef's draft and I feel like its somewhat 
orthogonal to mine; the encoding of the different OPAQUE messages (i.e. 
KE1, KE2 and KE3) are already defined in the OPAQUE draft. I think an 
area where my draft could however take from Stef's is regarding more 
meta usage information, e.g. around the registration abilities of OPAQUE.

>> The values of client_identity and server_identity are set to:
>> client_identity := client-first-message + "," + client_public_key
>> server_identity := server-message-bare + "," + server_public_key
> Are client_ and server_public_key binary?  The I-D is unclear, it
> generically says "encoded".  If it's DER you cannot find the head in
> backward direction.

That's a good point. I could have sworn the OPAQUE draft defines what it 
means with 'encoded' but I seem to misremember.

As the type and thus size of those keys is already known beforehand I 
think serializing them as 32-byte arrays as is done in the OPAQUE draft 
is the right approach, but I'll update my draft to make that explicit, 
thanks!

>> The PLUS suffix is only used
> "The -PLUS suffix is only used" (adding a dash)

Thanks ^^

>> C: n,,n=user,r=<ke1>
>> S: c=<cbdata>,i=<params>,v=<ke2>
>> C: p=<ke3>
> Are <ke1>, <ke2>, <ke3> binary or base64?  Both work, of course.

Base64, I've noted that in a section afterwards explaining all 
attributes but it's probably the right choice to make this example 
contain actual base64 data for clarification.

>> 5.1. OPAQUE Attributes
> I'm not sure that it is beneficial to define a family, if there is
> one actual case for OPAQUE; but it is definitely a good idea to name
> the attributes in the SASL mechanism.  It should be relatively simple
> to write a future spec saying "like the old one, but XXX is now YYY
> while ZZZ is kept; the SASL mechname has become OPAQUE-XXX-ZZZ."
> (A bit like DIGEST-MD5 which could have an alter ego in DIGEST-SHA384.)
>
> What I wonder is what value is added by declaring a family or group?
> (It may exclude later improvements, which might travel along with an
> algorithm update.)

Initially I just considered making it a family the correct thing to do, 
as that would make it easier for future specifications to be build on top.
But having thought about it a bit more and especially after Simon's mail 
I don't think it's the best way to do it; as both of you said there's no 
reason why a future specification couldn't define e.g. `OPAQUE-P256SHA` 
even when there isn't an OPAQUE mechanism family. And, as noted, that 
does mean those mechanisms can work very differently if necessary.

So there isn't specific value added and when I finally get time to 
update my draft again I'll change it to not try to define a mechanism 
family.

Thanks,

Nadja