Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: 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-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Arguably a "discuss discuss".) If we don't have any worked examples of signatures with message recovery, should we include that possibility in the Internet Standard version of the protocol? Some of the description around how the details of this would work remain unclear to me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I support Roman's Discuss.) It's a little weird that we're Obsoletes:ing 8152 yet expect the expert review procedures from it to remain in force. Perhaps we should copy the expert review instructions to this document so that IANA is not relying on an obsolete document? Do we need to check usage of "counter signature" with and without space? I'd also like to discuss the question raised by Martin D. (on -algs) relating to "AE" and "AEAD". Section 9.3 is quite clear that we restrict content-encryption algorithms to those that support AAD, i.e., AEAD mechanisms, so we only seem to use AE for the Key Wrap operations. Perhaps we should add a clarifying note in the terminology section about what AE and AEAD are used for. Section 1 Shouldn't we refer to RFC 8259 by its STD number (90)? structures. CBOR was designed specifically both to be small in terms of messages transported and implementation size and be a schema-free decoder. A need exists to provide message security services for IoT, nit: I think the second "be" should be "to be" as well. * The description of the structure for the CBOR objects which are transmitted over the wire. Two objects are defined for encryption, signing and message authentication. One object is That's two objects *each*, right? * A starting set of attributes that apply to the different security objects. nit: the "starting set" wording feels a little out of place given that the registry already exists and has stuff that we're not covering. providing security services. The use of COSE, like JOSE and CMS, is only in store and forward or offline protocols, different solutions would be appropriate for online protocols although one can use COSE in an online protocol after having done some type of online key establishment process. Any application which uses COSE for security nit: comma splice (and the sentence after the comma is a bit long, too). additional data fields as part of the structure. A common structure is going to include a URI or other pointer to where the data that is being hashed is kept, allowing this to be application-specific. This is "common" in the sense of "a design pattern expected to be frequently used", not "a common baseline", right? Section 1.3 * Define a single top message structure so that encrypted, signed, nit: "top-level"? * Signed messages distinguish between the protected and unprotected header parameters that relate to the content from those that relate to the signature. nit(?): shouldn't this be "distinguish between [x] and [y]", not "between [x] from [y]"? Section 1.6 Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms that provide an authentication check of the contents algorithm with the encryption service. nit: this last "algorithm" seems spurious? context can come from several different sources including: Protocol interactions, associated key structures and program configuration. nit: serial comma, please. The context to use can be implicit, identified using the 'kid context' header parameter defined in [RFC8613], or identified by a Wouldn't the "kid context" be an *explicit* context, not implicit? protocol-specific identifier. Context should generally be included in the cryptographic configuration; for more details see Section 4.3. nit: "configuration" is not the first word I would have picked here (and is not used in Section 4.3). Maybe "construction"? Section 2 1. The protected header parameters encoded and wrapped in a bstr. nit: I think this flows better with a comma after "parameters". 3. The content of the message. The content is either the plaintext or the ciphertext as appropriate. The content may be detached (i.e. transported separately from the COSE structure), but the location is still used. The content is wrapped in a bstr when This is "location" in the sense of "the third element of the array", or "the location in the array is still used"? layer. In the content layer, the plaintext is encrypted and information about the encrypted message is placed. In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed. A single nit: ending the sentence with "is placed" feels rather Yoda-esque. 4. When a COSE object is carried as a CoAP payload, the CoAP Content-Format Option can be used to identify the message content. The CoAP Content-Format values can be found in Table 2. The CBOR tag for the message structure is not required as each security message is uniquely identified. Is it an error to include the tag? The following CDDL fragment identifies all of the top messages [hmm, maybe my earlier comment about "top-level message" was misguided] Section 3 or evaluation hints for the processing of the layer. These two buckets are available for use in all of the structures except for keys. While these buckets are present, they may not all be usable in all instances. For example, while the protected bucket is defined as nit: isn't "all buckets" just "both buckets"? h'a0'). The zero-length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation. After encoding the map, nit: this doesn't look like a complete sentence. structures for cryptographic computation. After encoding the map, the value is wrapped in the binary object. Recipients MUST accept This seems a bit redundant with earlier text (and shouldn't it be a "byte string" anyway?). both a zero-length byte string and a zero-length map encoded in the binary value. ["binary value" vs. "binary string" vs. "byte string" again] decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. perhaps, "common canonical encoding for input to cryptographic operations"? reference to any other layer. With the exception of the COSE_Sign structure, the only data that needs to cross layers is the (I assume this includes COSE_Sign0 and the tagged versions, too?) Parameters" registry (Section 12.2). Some common header parameters are defined in the next section. [similar comment as above about "common"; maybe "The basic protocol header parameters"?] malformed. Applications SHOULD verify that the same label does not occur in both the protected and unprotected header parameters. If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket. I a little bit worry that "take from protected before unprotected", combined with "don't check for duplicates", means "last match wins" and the unprotected one gets used. Perhaps it's better to talk about taking precedence if both are present? Section 3.1 alg: This header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be Can countersignatures authenticate 'alg'? Is there an easy listing of the class of message that does *not* allow for authenticating 'alg'? COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected header parameter bucket or as part of the externally supplied data. The value is taken from the "COSE Algorithms" registry (see I don't think we've introduced "externally supplied data" yet, so a forward reference might be in order. * Integer labels in the range of 0 to 7 SHOULD be omitted. side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as "unassigned" in the registry. Is there a story here? * Integer labels in the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly Where is this sub-partitioning of the -1 to -65536 range specified, that any given algorithm will only assign "critical" header parameters in the -1 to -128 range? If it's just convention I don't think the declarative language ("can be omitted") is appropriate. * Labels for header parameters required for an application MAY be omitted. Applications should have a statement if the label can be omitted. nit: applications or application protocols? The message IV is generated by the following steps: 1. Left-pad the Partial IV with zeros to the length of IV. 2. XOR the padded Partial IV with the context IV. nit: this procedure does not indicate how "the length of IV" is known (i.e., that it's a constant determined by the algorithm). Section 4.1 authenticated by the signature, or just present. An example of header a parameter about the content is the content type header nit: s/header a/a header/ A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body is called the COSE_Sign structure. The CBOR object that carries the signature and (COSE_Sign also carries the signature parts?) Note: When a signature with a message recovery algorithm is used (Section 9.1), the maximum number of bytes that can be recovered is the length of the payload. The size of the payload is reduced by the number of bytes that will be recovered. If all of the nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object that is reduced, right? Section 4.3 proxy's cache. But the sender can cause a failure at the server if a proxy, or an attacker, changes the set of accept values by including the field in the application-supplied data. nit: "application-supplied data" reads pretty oddly to me, though given what section this is in I guess it is not limited to just being "additional authenticated data". Also, it seems like more a property of the protocol the sender is using than the sole choice of the sender, to include or not include the set of accept values in the externally supplied data. This document describes the process for using a byte array of externally supplied authenticated data; the method of constructing the byte array is a function of the application. Applications that Why is this a "byte array" and not a "byte string"? * If multiple items are included, applications need to ensure that the same byte string cannot be produced if there are different inputs. This would occur by appending the text strings 'AB' and 'CDE' or by appending the text strings 'ABC' and 'DE'. This is (I liked this better as "could occur" of RFC 8152. Also, is concatenating" better than "appending", since we are posing the two strings as peers, not subject and object?) Also, sometimes this property is referred to as being an "injective mapping". Section 4.4 (I also had Roman's comment about the "CounterSignature" attributes in field (1).) 3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used. This field is omitted for the COSE_Sign1 signature structure and CounterSignature0 attributes. ("omitted" means "not present in the array at all", right?) 4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero- Are these "protected attributes" the "externally supplied data" of Section 4.3? We should probably use the same terminology to talk about them... Section 5 counter signatures use the structure COSE_Countersign. This is same structure as COSE_Signature and thus it can have protected attributes, chained counter signatures and information about identifying the key. Abbreviated counter signatures use the nit: "information about identifying the key" seems redundant. specified. One result of this is that for COSE one can expand the concept of counter signatures beyond just the idea of signing a signature to being able to sign most of the structures without having to create a new signing layer. When creating a counter signature, nit: this seems somewhat redundant with the first paragraph of the section ("this document extends to the concept of a counter signature to allow [...]"). Section 5.1 The COSE_Countersignature structure allows for the same set of capabilities of a COSE_Signature. This means that all of the nit: "same set of capabilities as" archiving services. More information on how this is used can be found in the evidence record syntax described in [RFC4998]. nit: I'm binding "this" to "COSE_Countersignature", which causes this sentence to not make much sense. Perhaps "how this can be used" or "how countersignatures signing countersignatures can be used" or "long-term archiving services"? COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature) note that 6.98 is incorrect; this is going to be the TBD value. Section 6.1 I think we need some forward-references to 6.3/6.4, here, since (e.g.) 6.2 is referencing back here to fill in the ciphertext. The COSE_recipient structure is a CBOR array. The fields of the array in order are: [...] ciphertext: This field contains the encrypted key encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value. I guess it's impossible to have protected headers with no encrypted key (since you need a ciphertext for protected headers)? COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] side note(?): I'm not sure I really understand when the recursive COSE_recipient structure would be used at higher depths of recursion. passwords: The CEK is encrypted in a KEK that is derived from a password. As of when this document was published, no password algorithms have been defined. If there aren't any, do we need to include it in the taxonomy? Section 6.3 It's slightly amusing that the "Enc_structure" is actually the AAD, not anything encrypted :) Section 6.4 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. Presumably we fail the operation if either verification fails? Section 7.3 3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero- [as above, using consistent terminology for "externally supplied data" would be useful.] Section 8 A COSE Key structure is built on a CBOR map. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 12.4). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry ([COSE.KeyParameters]). It's slightly jarring to have a section reference for one registry but an external reference for the other. Section 8.1 cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice. Depending on the answer to my question on -algs about capabilities and their use, this statement might need to be updated. kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user- provided byte string to a value computed on the public portion of the key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked. I suggest reiterating that it is not in any way a unique identifier. Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the Partial IV header parameter defined in Section 3.1. This field provides the ability to associate a Partial IV with a key that is then modified on a Er, isn't it the Base IV associated with the key and the Partial IV that's per-message? If different keys are derived for each sender, using the same Base IV with Partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same Base IV is likely to satisfy this condition. If the same key is used for The two sentences that start with "if different keys" seem to have some redundancy that could be eliminated. Section 9 to be exhaustive. New algorithms will be created which will not fit into this taxonomy. If this occurs, then new documents addressing this new algorithms are going to be needed. nit(?): this last sentence is written in a kind of colloquial style. Section 9.1 There are two signature algorithm schemes. The first is signature nit: mybe "two types of" (and "scheme" singular)? Section 9.2 Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, cannot be used to prove the identity of the sender to a third party. Hmm, should the s/can/cannot/ be filed as an erratum against 8152? Section 9.4 General KDFs work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. Functions like PBES2 [RFC8018] need to be used for non-random secrets. nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to a PBKDF construction, not PBES (which provides an abstract API for password-based encryption that uses PBKDF1 under the covers)? (Also, my understanding is that PBKDF1 is not exactly considered state-of-the-art.) Section 9.5.1 * A header parameter identifying the shared secret SHOULD be present. What type of header parameter might do that? Section 9.5.2 * The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present that has an unsupported algorithm, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to nit: comma splice Section 9.5.3 When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows: Does key transport use COSE_Encrypt or COSE_Recipient? Section 9.5.4 any dynamic key material. One side effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will Do we want to drop the "perfect"? The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for direct key agreement? Section 9.5.5 The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for key agreement with key wrap? * A header parameter identifying the recipient's key SHOULD be present. A header parameter identifying the sender's key SHOULD be present. Is there anything to say about what header parameters those might be? Section 10 The document limits the restrictions it imposes on the CBOR Encoder needs to work. nit: missing word or two? -algs seems to say "restrictions it imposes on how the CBOR Encoder needs to work". Section 11 * Applications need to determine the set of security algorithms that are to be used. When selecting the algorithms to be used as the mandatory-to-implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC- Do we want to mention BCP 201 here? Section 12 Do we want to update the reference for the registries themselves (to point to both 8152 and this) in addition to the reference for the registered entries? Section 12.3 The COSE Header Algorithm Parameters Registry is https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters , right? I don't see any of those being talked about in this document -- they're discussed in the KDF algorithms section in 8152. So shouldn't this registry (and its entries) point to the algorithms doc, not this one? Section 12.6 IANA added the following entries to the "CoAP Content-Formats" registry while processing [RFC8152]. IANA is requested to update the reference value from [RFC8152] to [[This Document]]. [no entries follow] Section 13 There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some [this stuff is in -algs, not -struct] There are a large number of algorithms presented in [I-D.ietf-cose-rfc8152bis-algs] that use nonce values. Nonces generally have some type of restriction on their values. Generally a nonce needs to be a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be nit: this looks like a bad edit from the splitting off of the algorithms: "all of these cases" cannot bind to "specified in this document" anymore, so we need to describe what we mean differently. One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. I think this may have graduated from "starting" to be more of a mainstream thing :) Section 14.1 side note: OpenSSL 1.0 (no minor version information given?)?! That stuff's EOL! Section 14.4 side note: what's curve24459? Section 15.1 [DSS] has only one usage now in -struct, which doesn't seem normative. I'd expect it to only be normative in -algs. Likewise for RFC 8032. It's also interesting to make a normative reference to -algs, which will be an informational RFC when published (given the current intended status). Are we creating it directly onto the downrefs registry? Appendix A side note: it seems like any scheme for conveying information about what algorithm to use other than "implicit by key with each key limited to one algorithm" has some risk of allowing an attacker's input to cause the key holder to perform some operation using that key but with the "wrong" algorithm. I think that if the externally visible results of that operation are indistinguishable from "the input was ignored", that does not give the attacker a channel by which to attack the key, but I'm not 100% sure. Even an application-layer "rejected due to bad input" might be enough of a lever to enable some types of attack. Appendix B All of the currently defined recipient algorithm classes only use two layers of the COSE_Encrypt structure. The first layer is the message COSE_Recipient? Acknowledgments Göran could probably get his proper name, now. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
