Skip to main content

Minutes IETF105: lamps
minutes-105-lamps-00

Meeting Minutes Limited Additional Mechanisms for PKIX and SMIME (lamps) WG
Date and time 2019-07-23 17:30
Title Minutes IETF105: lamps
State Active
Other versions plain text
Last updated 2019-08-10

minutes-105-lamps-00
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
<draft-ietf-lamps-header-protection-requirements-00>
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
<draft-brockhaus-lamps-lightweight-cmp-profile>
<draft-brockhaus-lamps-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
<draft-turner-5480-ku-clarifications>
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
<draft-ounsworth-pq-composite-sigs>
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.