LAMPS Session at IETF 105 Tuesday, 23 July 2019 at 13:30 Chairs: Russ Housley and Tim Hollebeek Review of WG document status In the RFC Editor queue: - RFC6844bis - root-key-cert-extn - PKIX-shake With the IESG: - CMS-shakes Quynh: good review comments received and addressed; an update was posted today, another expected soon. - lamps-cms-hash-sig - lamps-cms-mix-with-psk Russ: No open issues on either of these. Header Protection Requirements Bernie Hoeneisen/Alexey Melnikov This -00 requirements document merges luck-pep and melnikov-lamps on header protection. Which protection levels should be in scope? The choices are: - signed and encrypted - signed only - encrypted only Discussion at IETF104 suggested that the encryption-only case is not relevant. ==> No objections raised in the room, but few people in the room have read the draft. Alexey: We are not collecting requirements for the sake of it; the goal is to define the end-state solution, and (where needed) to be able to prioritise requirements as a precursor to that. The difficulty of processing BCC Alexey: I have tried to implement S/MIME encryption with BCC; results showed that this can give rise to 3 variants of the message, depending on whether one is a BCC recipient, a non-BCC recipient, or the originator's sent mail folder. Russ: Receipt of a non-delivery notice is another complication. Some people in the room recalled guidance about handling BBC recipients the S/MIME version 3 specifications, but no one remembered which RFC to reference off the top of their head. (Likely places are RFC 2632, RFC 2633, or RFC 2634.) Deb Cooley: If the recipient list includes the BCCs, why bother including them (because that is what BCC is all about); just send a single copy for the "legit" recipients so that it can be processed as normal. Russ: (1) Processing varies if we are talking about RFC5322-compliant lists. For example, with Mailman there is only one recipient, which forwards to all the list subscribers. (2) Processing all the BCC recipients the same way as "the legit recipients" would result in the key management information revealing the BCC list to all of the other recipients and the BBC recipients, which defeats the point of BBC in the first place. The temptation is to process each BCC recipient separately, which adds iterations and complexity to processing of the "SUBMIT" operation. Requirements Backward Compatibility Bernie: Need to be able to distinguish forwarded from wrapped messages (and attachments). Bernie: Need to define a way to indicate support for header protection (HP). Russ: Part of the issue here is how an IMAP server decides what to send to the client. When a single mailbox is accessed using multiple clients, some of them might be able to handle HP and others not. ==> This is not well-enough documented and specified yet to determine whether this is a MUST level requirement. Paul Turner: Has usability been considered? Bear in mind that currently even email encryption ans signing seems to be beyond many users. Markus: We are doing some work to improve the user experience, but that does not fix clients that do not know how to process the improvements. Bernie: Pretty sure we are not going to solve user experience issues in LAMPS, but privacy/security factors cannot be ignored indefinitely. And these issues go beyond Header Protection. Alexey: Agreed that user interface discussion is not one of IETF strengths, but discussing better user experience metaphors is still useful. ==> Take topic to mailing list Lightweight CMP Profile and CMP Updates Hendrik Brockhaus Outcomes from IETF 104: CMP Profile topic is better suited to LAMPS than other potential working groups since it is not specific to constrained environments and LAMPS has PKIX history. CMP Updates Russ: Would a PKCS#8 wrapper allow you to include the public key, privacy key and wrapped data in one object? (See RFC 5958.) Jim Schaad: Don’t think the PKCS#8 format includes the public key. CMRF use by CMC and CMP and adoption/omission of this feature was briefly discussed. Hendrik has draft text to add CMP to the LAMPS WG Charter. ==> R Daniliw: The draft text for the Charter is hard to parse; please edit and submit to mailing list for further review. Simple Update to RFC 5480 Sean Turner Proposal is to update the Key Usage specifications in Section 3 of RFC 5480 as follows: Provide requirements for keyEncipherment and dataEncipherment. MUST NOT be set for: - id-ecPublicKey - i.e., unrestricted and ECDSA - id-ecMQV - id-ecDH Does the proposed change require LAMPS to re-charter? ==> R Daniliw: would prefer a forcing function that ensures this is incorporated in the charter; current charter explicitly excludes adoption of "other stuff". Yoav Nir: The proposal is that the two values referred to MUST NOT be used; what if they are? Sean Turner: Really don't think CAs were setting these values. ==> Chairs to propose text for a re-charter to address clarifications of this sort. Post Quantum composite signatures Mike Ounsworth Problem statement: In the transition period for post-quantum (PQ) encryption, you might not be sure whether or not e.g. RSA is compromised, and accordingly wish to accommodate composite signatures consisting of one signature type known not to be compromised, and one whose status is uncertain. Proposed approach is to ensure that composite signatures are handled at the crypto library layer and therefore do not require changes to the protocols above the library. In theory, it "drops in" to X.509, CMS, and ASN.1-based protocols. Scott Fluhrer: Encryption/dual-use keys and KEMs (Key Exchange Mechanisms) are intentionally out of scope here; they are hard. Riad Wahbi: What happens if any of the composite signature algorithms is compromised? This seems a counter-intuitive weakening of current guarantees, leading to a loss of current security properties. Scott Fluhrer: Could change it to say "if there are any unsupported algorithms in the composite that you can/should reject the certificate". Robin Wilton: If failure of any of the algorithms in the composite causes failure of the whole signature verification, I question whether we have met the stated goal of maintaining trust during a post-quantum interim period. Max Pala: True. However, if the policy is "if an algorithm in the composite is known to have been compromised, a relying party should rely on an uncompromised algorithm in the composite" - this delivers longevity of the protocol. Ryan Sleevi: Separating this from the protocol layer creates its own challenges by pushing policy-level choices down to the verifier. Russ: I am not sure this is better than having two signatures and two certificate OR having to negotiate this at the protocol layer as part of ciphersuite negotiation. Scott Fluhrer: It may be premature for the draft to specify verifier policy choices at this point without giving (the developer) some indication of the implications of a couple of choices.