LAMPS WG at Virtual IETF 109 Minutes: Jonathan Hammell Jabber Scribe: Tim Hollebeek AGENDA 1) Agenda Bash 2) Documents with the RFC Editor a) draft-ietf-lamps-ocsp-nonce b) draft-ietf-lamps-rfc7030est-clarify 3) Active Working Group Documents a) draft-ietf-lamps-cmp-updates b) draft-ietf-lamps-cmp-algorithms c) draft-ietf-lamps-lightweight-cmp-profile d) draft-ietf-lamps-header-protection 4) Prospective Active Working Group Documents a) draft-dkg-lamps-e2e-mail-guidance b) draft-housley-lamps-crmf-update-algs c) draft-housley-lamps-cms-aes-gmac-alg 5) Wrap Up MINUTES 1) Agenda bash: No agenda changes were requested. 2) Documents with the RFC Editor a) draft-ietf-lamps-ocsp-nonce is in AUTH48; no known issues. b) draft-ietf-lamps-rfc7030est-clarify is in AUTH48; no known issues. 3) Active Working Group Documents a) Hendrik Brockhaus presented on draft-ietf-lamps-cmp-algorithms. (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00) Currently only message digest algorithms are the SHA-2 family, but plan is to add SHAKE. No additional message digest algorithms suggested. Use of content encryption is intended for certificates and passphrases. Currently only content-encryption algorithms are AES-CCM and AES-GCM, but could add AES-CBC or ChaCha20-Poly1305. Russ Housley pointed out that AES-CCM and AES-GCM require AuthEnvelopedData rather than EnvelopedData as currently used in CMP. Hendrik plans to move to AES-CBC. Current MAC algorithms include PasswordBasedMAC, PBMAC1, DHBasedMAC, and HMAC_SHA-2. Hendrik plans to add AES-GMAC and KMAC. Mailing list thread suggested preference for AES-GMAC versus AES-CMAC. Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is gaining support. Russ (and several in chat) suggested dropping DSA. No objections. Current key agreement algorithms are Diffie-Hellman and ECDH. Daniel Khan Gilmore (DKG) suggested explicitly discourage use of static-static variants of Diffie-Hellman and ECDH. Current key transport algorithms is PKCS#1 V1.5 and RSAES-OAEP. Russ has not seen RSAES-OAEP in the wild. Hendrik will remove RSAES-OAEP. Symmetric key-encryption algorithm is AES-KEYWRAP. Key derivation algorithm is PBKDF2. b) draft-ietf-lamps-cmp-updates (Hendrik) (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00) All issues from IETF 108 and subsequent discussion on mailing list have been addressed in the current I-D. In order to handle PKIs with multiple root CA certificates, new OID is used to include certificate in the request. If PKI supports more than one certificate profile, request to CA for certificate request template is ambiguous. Agreement to add an InfoTypeValue in the PKIHeader.generalInfo. Reuse of AttributeTypeValues controls in context of certificate request template. No objection. Once the document is stable, the WG will ask IANA to make early assignment for the needed OID. DKG asked the authors to get feedback from Mark Nottingham on use of .well-known. In chat, several people suggested use .well-known/cmp and the IANA registry to use. The ASN.1 module should be an update to RFC 5912. c) draft-ietf-lamps-lightweight-cmp-profile (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00) All issues from IETF 108 and subsequent discussion on mailing list have been addressed in the current I-D. GitHub.com/Siemens includes a reference lightweight RA implementation. No suggestions on better TLS cipher suite for use of PSKs. d) draft-ietf-lamps-header-protection (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-header-protection-00) Summary of changes since IETF 108 were presented. Then, the list of still open issues was given. The I-D will be overhauled to focus on implementation guidance. In particular how to handle reception for the the two header protection schemes found in the wild. The authors are requesting feedback for message composition. A table that captures the way that user agents handle the various situations will help the WG choose the best way forward regarding message composition. DKG proposed a header confidentiality policy (HCP) for encrypted messages. This I-D will recommend one default HCP, but more could be added in future I-Ds. Bernie Hoeneisen wondered how much we lose with hcp_strong option (see slides). Alexey Melnikov pointed out an impact to MUAs that support message threading without downloading the entire message. Tim Hollebeek pointed out the HCP definition works in a header-by-header method, which makes some wholistic policy statements impossible. DKG agreed, and he observed that HCP is also stateless. Need discussion on the mailing list to select the default HCP. Also, there may need a signaling mechanism to say which HCPs are supported by the MUA, but that should be done in future I-D. Russ pointed out that SMIMECapabilities was intended to be such a signaling mechanism, but it hasn't been a significant success in altering behaviour. Bernie said that hcp_strong is implemented in PeP without any problems. Looking for feedback on some more subtleties. 4) Prospective Active Working Group Documents a) draft-dkg-lamps-e2e-mail-guidance (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-end-to-end-mail-guidance-00) DKG talked about End-to-End Cryptographic E-mail Guidance. Russ said that adopting this document may require a WG re-charter. DKG said it should not be lumped under header protection. DKG requested review and to contribute suggestions. The I-D is on gitlab, and DKG is happy to accept PRs. No objections raised for this work item topic, despite it covering user experience. No concerns from Roman as Security AD. DKG will propose re-charter text on the mailing list. b) draft-housley-lamps-crmf-update-algs (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-draft-housley-lamps-crmf-update-algs-02) Russ talked about updates to the cryptographic mandatory-to-implement algorithms in CRMF (RFC 4211) for the Password-based MAC. The proposed replacements are based on mailing list discussion. Plan to do WG call for adoption, followed immediately by WG Last Call. No objections. Tim will start WG adoption call on the mailing list. c) draft-housley-lamps-cms-aes-gmac-alg (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-draft-housley-lamps-cms-aes-gmac-alg-01) At Russ' request, NIST assigned three OIDs for AES-GMAC. This I-D specifies the OIDs and GMACParameters. Tim has already started WG adoption call on the mailing list. If adopted, then WG Last Call will follow immediately. 5) Wrap Up: no other business.