Subject: [lamps] WGLC for draft-ietf-lamps-samples?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 21:04:03 -0400

With the switch from SHA512 to SHA1 for the MAC of the PKCS12 objects in
draft-ietf-lamps-samples, i believe that there are no major outstanding
concerns.

I personally consider this draft to be ready for working group last
call, though i recognize it's not my place to make that decision.

Here's my summary of the work on the draft:

 - all implementations that i know of are capable of importing the Alice
   and Bob pkcs12 bundles (though some might need manual conversion from
   PEM to DER first).  Implementations that lack curve 25519 can't
   handle Carlos or Dana, of course.  I don't think there's anything
   else to do here.

 - the PKCS12 bundles are still using 3DES internally to lock the
   private keys.  That raised some derision on the list recently.  If
   folks would prefer that we switch from that to, say, AES 128 or AES
   256, i can spin one more revision to address it.

 - the PBKDF2 parameters for the encrypted PKCS-8 objects embedded in
   the PKCS12 bundles are relatively cheap/weak (~5000 cycles of a
   simple hash) -- but then, the passwords chosen are terrible as well.
   If folks would prefer, i can increase the cost for PBKDF2 for the
   PKCS-8 objects.  Let me know, though i think it's unnecessary.  I
   suppose if we increase the work factor for the PKCS-8 objects, we
   should also increase the PBKDF2 work factor for the bags of x.509
   certificates, though they contain nothing secret.  But since the cert
   bags in a PKCS12 object typically share the same password with the
   encrypted PKCS-8 objects, if we increase the work factor of one
   without the other, then cert bags can serve as a cheap oracle for
   testing passwords that can then be applied to the PKCS-8 objects.

 - During IETF 111 we briefly discussed the possibility of including an
   appendix describing how to import the various objects on different
   popular systems.  The sense i got from the people engaged in the
   discussion was that this kind of ephemera might not be appropriate
   for a reference document.

Please let me know what y'all think the next steps for this draft should
be.

       --dkg