[lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 16 August 2019 17:21 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E552B12008D; Fri, 16 Aug 2019 10:21:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lamps-cms-mix-with-psk@ietf.org, Tim Hollebeek <tim.hollebeek@digicert.com>, lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com>
Date: Fri, 16 Aug 2019 10:21:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ee_sWnmIa4oqz-F1H9huUw0Iyms>
Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 17:21:59 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-mix-with-psk-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think we need to have a discussion about the abstract API for a KEY-DERIVATION instance and how that relates to what we need for a key combination operation. In Section 5 we assume that we can use the HKDF terminology, but that doesn't seem to hold universally for KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2 (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is specified by RFC 2898 as taking just the input secret (password) and a salt, with no separate 'info' (and of course the different iteration count and PRF parameters needed for its construction). I note (with chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for the HKDF-based KEY-DERIVATION instances but is silent about how one is supposed to know what to pass for salt/info (the IKM we can perhaps assume will be obvious). In short, should we be seeking to define a distinct key combination operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key derivation? Some KDFs support this fairly well, but it's not clear to me that it is a universal property. For example, the proof in [H2019] seems to be assuming HKDF but this draft does not (as is clearly seen from the use of the X9.63 KDF in one of the examples). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we need to document the risk of "algorithm mismatch" that is present because we use separate algorithm identifiers for KDF, key-encryption, key-agreement, etc. (vs. a "cipher-suite"-like approach that bundles together a known-good combination)? In particular, I see we talk about the key length for content- and key-encryption algorithms, but are there other constraints that should be applied? Section 2 The PSK MUST be distributed to the sender and all of the recipients by some out-of-band means that does not make it vulnerable to the future invention of a large-scale quantum computer, and an identifier MUST be assigned to the PSK. What are the uniqueness/scope requirements for that identifier? Section 3 ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport algorithm to establish the key-derivation key. KeyTransRecipientInfo is described in Section 6.2.1 of [RFC5652]. I think we need to be more clear that the 'encryptedKey' member of KeyTransRecipientInfo contains not the "result of encrypting the content-encryption key for this recipient" per RFC 5652, but rather the "result of encrypting the key-derivation key for this recipient". That is, to call out how we are deviating from RFC 5652. Section 5 Many key derivation functions (KDFs) internally employ a one-way hash function. When this is the case, the hash function that is used is identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] (editorial?) This reads as if the KeyDerivationAlgorithmIdentifier is going to be (e.g.) 2.16.840.1.101.3.4.2.1 for regular SHA-256, which is presumably not the case. It sounds more like "indicated by" or "indicated as part of the semantics of the" would be more appropriate. (side note) Is there a story behind using 5 and 10 for the ENUMERATED values? CMSORIforPSKOtherInfo ::= SEQUENCE { psk OCTET STRING, keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) }, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, pskLength INTEGER (1..MAX), kdkLength INTEGER (1..MAX) } If psk is encoded as an OCTET STRING (i.e., including its length), why do we need a separate pskLength field? Section 7 material. Compromise of the key-encryption key may result in the disclosure of all content-encryption keys or content-authenticated- encryption keys that were protected with that keying material, which in turn may result in the disclosure of the content. a nit, but for the key-agreement variant we have two things that we call "key-encryption key"s, so use of the definite article here is potentially ambiguous. This specification does not require that PSK is known only by the sender and recipients. The PSK may be known to a group. Since confidentiality depends on the key transport or key agreement algorithm, knowledge of the PSK by other parties does not enable eavesdropping. However, group members can record the traffic of Would it be appropriate to add either "inherently" (enable eavesdropping) or "with currently available technology"? Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and nit: "cryptanalysis" Section 8 With respect to "not really making privacy worse", this does seem to risk exposing that a group of (identified) recipients/participants share access to a single PSK (identity), which could potentially correlate them for other sorts of surveillance/attack. Section 10.2 Don't RFCs 5911, 5912, and 6268 need to be normative since we import from them in the ASN.1 module? Section A.1 [I did not attempt to validate the examples.] The pre-shared key known to Alice and Bob: c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 (Should we say it's in hex? Similarly for other non-ASCII-armored fields, especially the PSK identifier which looks like it is more of a string than a hex-encoded binary blob)
- [lamps] Benjamin Kaduk's Discuss on draft-ietf-la… Benjamin Kaduk via Datatracker
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Russ Housley
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Russ Housley
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Phillip Hallam-Baker
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Phillip Hallam-Baker
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Russ Housley
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Russ Housley
- Re: [lamps] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk