Minutes IETF109: lamps
minutes-109-lamps-00

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.