-----Original Message----- From: Benjamin Kaduk via Datatracker <[email protected]> Sent: Wednesday, June 10, 2020 6:44 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Matthew Miller <[email protected]>; [email protected] Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT)
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. [JLS] I tried a couple of times to get Kenny interested in seeing if anybody in CFRG wanted to pursue this and never got anywhere. This text is here as much to let people know that such an algorithm might be defined in the future and it might cause some problems if it is. At one point I looked at looked at writing an experimental RFC which would define a version of this with RSA. The padding algorithm would look like that in PKCS #1.5 with the following change: PS = byte count || stolen bytes || 0xff where byte count is the length of stolen bytes and stolen bytes are the last n bytes of the signed message. Where byte count is the minimum of the message length and (emLen - tLen - 4). I ended up not doing this because I did not want it to escape into the wild and I did not see any way of having people implement this for testing and still making sure that it was contained. One pointer is https://crypto.stackexchange.com/questions/17802/description-of-signatures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si ---------------------------------------------------------------------- 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? [JLS] There was some discussion about this in the WG that was pretty inconclusive. Given that did not change I did not see this to be a big issue but if the IESG wants to change this tell me. Do we need to check usage of "counter signature" with and without space? [JLS] I have a note in the XML to the RFC Editor about this point. 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. [JLS] See response to Martin (still to be written) Section 1 Shouldn't we refer to RFC 8259 by its STD number (90)? [JLS] Makes sense 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. [JLS] Changed * 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? [JLS] Changed. * 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. [JLS] Removed starting 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 be done before sending objects back and forth. [JLS] New text: The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols. The use of COSE in online protocols needing encryption, require that an online key establishment process 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? [JLS] Yes Section 1.3 * Define a single top message structure so that encrypted, signed, nit: "top-level"? [JLS] "overall"? * 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]"? [JLS] Changed, we will see what the copy editor says. 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? [JLS] See message to Martin (to be written) context can come from several different sources including: Protocol interactions, associated key structures and program configuration. nit: serial comma, please. [JLS] Now Oxford comma style 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? [JLS] No it is still implicit. Consider the usage of a "kid context" in OSCORE as a method of identifying what items should be placed into the context structure. It changes over time and is not the kid itself. The use of "kid context" as a name is not good, but I did not name it. 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"? [JLS] Makes sense Section 2 1. The protected header parameters encoded and wrapped in a bstr. nit: I think this flows better with a comma after "parameters". [JLS] sure 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"? [JLS] As in the third element of the array. 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. [JLS] Your point being? Text is re-written to eliminate. 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? [JLS] No The following CDDL fragment identifies all of the top messages [hmm, maybe my earlier comment about "top-level message" was misguided] [JLS] see above comment. 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"? [JLS] I probably meant to rite always though. 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. [JLS] The RFC editor did not object last time. Noun = encoding, verb = preferred. 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?). [JLS] Yes it is redundant - removed 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] [JLS] Yep - fixed 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"? [JLS] A bit wordy - but ok 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?) [JLS] No it does not include COSE_Sign0 because it has only one layer, but it does include the tagged version which is defined in terms of COSE_Sign. 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"?] [JLS] I don't like that wording, but have no problems eliminating "common". 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? [JLS] **** I don't understand your worry here. These are separate maps and thus there is no "last match wins" between the two different buckets. 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'? [JLS] Where to start, all of the constructions/algorithms have the ability to do the authentication. The use of an AE algorithm does not allow this. By construction, the encryption structures (Encrypt, Encrypt0 and Recipient) do not do this, Changed to " (e.g. COSE_Sign and COSE_Mac0)" 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. [JLS] Done * 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? [JLS] Yes, I had originally assigned countersign0 to 8 and then messed up. * 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. [JLS] There is no requirement that an algorithm is restricted to that range. The assumption is that purely optional items might be placed farther out in the range and thus need to be placed in the "crit" attribute. This is just a restriction, similar to the 0-7 range of things that can be omitted. * 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? [JLS] I am pretty sure I meant applications. 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). [JLS] I don't think this is really necessary but "IV (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/ [JLS] Yep 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?) [JLS] No - they are carried in COSE_Signature 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? [JLS] No it is the "size of the payload" as in the payload you signed. 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. [JLS] No, it really is just externally supplied data - so changed to that 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"? [JLS] This is dealing with a value passed in from the application and does not refer to a CBOR encoded value. * 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". [JLS] somebody asked for the change from could to would. I debated it with them and then made the change. Going to concatenation makes sense. I don't think that giving the property a name would really help 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?) [JLS] Yes 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... [JLS] Yes - fixed in all three spots 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. [JLS] Changed to " This is same structure as COSE_Signature and thus it can have protected and unprotected attributes, including chained counter signatures." 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 [...]"). [JLS] Doesn't bother me - it falls out from the previous sentence 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" [JLS] Changed 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"? [JLS] This is a really weird reading on your part, but changed. COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature) note that 6.98 is incorrect; this is going to be the TBD value. [JLS] Cut and paste error - yes this is a TBD. 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)? [JLS] Yes that is true 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. [JLS] Did you take a look at Appendix B 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? [JLS] It is only a matter of time. Personally I was waiting for Argon2 get someplace before even trying to define one. Section 6.3 It's slightly amusing that the "Enc_structure" is actually the AAD, not anything encrypted :) [JLS] You are easily amused then. 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? [JLS] Yes that would be my expectation. 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.] [JLS] see above 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. [JLS] It doesn't really bother me 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. [JLS] Not clear which comment you are referring to 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. [JLS] sure. 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? [JLS] Yup. 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. [JLS] Looks like I tried two different ways to same the same thing and did not delete one of them. 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. [JLS] Doesn't really add anything - delete Section 9.1 There are two signature algorithm schemes. The first is signature nit: mybe "two types of" (and "scheme" singular)? [JLS] No, I think this is a correct usage. 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? [JLS] Yes if we don't think we are going to have a fast publish. What is the current RFC Editor queue processing time? 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.) [JLS] Given what I said above, if you really want to change this we could point to Argon2 Section 9.5.1 * A header parameter identifying the shared secret SHOULD be present. What type of header parameter might do that? [JLS] Will KID would be one that could do this. 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 [JLS] ok 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? [JLS] No, it uses COSE_Recipient. It used to use COSE_Encrypt until I change the syntax slightly. 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"? [JLS] Yes. The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for direct key agreement? [JLS] see above and others. 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? [JLS] No, that would be more algorithm specific esp for the latter. 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". [JLS] 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? [JLS] I don't have an issue with this, I forgot such a beast had been created. 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? [JLS] Unless we move the DE guidance, I don't see any reason to. 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? [JLS] Yes they should 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] [JLS] s/the following// 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] [JLS] Deleted 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. [JLS] Might just as well delete the duplicated paragraph. gone 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 :) [JLS] Given that I had to explain this initially, it is nice to know it has gone far more main stream. No longer starting. Section 14.1 side note: OpenSSL 1.0 (no minor version information given?)?! That stuff's EOL! [JLS] I actually just updated the library in the last month to require 1.1 in order to get support for EdDSA, however yes it did not really what the minor version was because it was totally generic to that version. I changed that to 1.1, but given that this goes away before publishing I don't suppose it matters andy. Section 14.4 side note: what's curve24459? [JLS] You mean you don't recognize the really twisted curve of 25519 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. [JLS] Done 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? [JLS] I could move the reference without any problems. However, putting it directly in to the downref registry is probably a good idea so that protocol documents can make algorithms MUST. 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. [JLS] The current CoRE group communication document is breaking the "one key one algorithm" rule although in an offline way. At least for OSCORE, there would not be a way to distinguish between any of the "it did not decrypt" cases. 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? [JLS] That’s what I get for renaming things. Acknowledgments Göran could probably get his proper name, now. [JLS] I think he probably would as well. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
