I think this is everything except for you discuss-discuss. Jim
> -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: Tuesday, June 16, 2020 8:03 PM > To: Jim Schaad <[email protected]> > Cc: [email protected]; [email protected]; 'Matthew > Miller' <[email protected]>; 'The IESG' <[email protected]>; > [email protected] > Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > struct-10: (with DISCUSS and COMMENT) > > On Mon, Jun 15, 2020 at 06:44:02PM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk <[email protected]> > > > Sent: Monday, June 15, 2020 4:05 PM > > > To: Jim Schaad <[email protected]> > > > Cc: 'The IESG' <[email protected]>; > > > [email protected]; cose- [email protected]; > > > 'Matthew Miller' <[email protected]>; > > > [email protected] > > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on > > > draft-ietf-cose-rfc8152bis- > > > struct-10: (with DISCUSS and COMMENT) > > > > > > Hi Jim, > > > > > > On Sun, Jun 14, 2020 at 03:00:23PM -0700, Jim Schaad wrote: > > > > > > > > > > > > -----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-si > > > > gnat ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si > > > > > > I was thinking specifically of worked examples for COSE usage. > > > E.g., verifying that the "payload" element of SOSE_Sign > > > interoperates, especially when the signature provides full message > > > recovery and how the "message sent" and recovered content are > reconstituted into the "message content" > > > during the Verification() process. We don't give many details of > > > how that would work or what an algorithm specification would need to > > > provide in order to give a complete specification. > > [JLS] I don't have any problems with providing such a thing using the evil > signature algorithm that I outlined above on the examples website, but I don't > know that it has any place in the document. > > I also expect that such a thing doesn't have any place in the document. > > But where does that leave us, though -- do we have enough > knowledge+experience for how to use signature with recovery for COSE > messages to merit granting it full Internet Standard status? I can't say the > answer for sure, just on my own authority; hence the "discuss discuss". > Well - I think that I do. I did play with this at one point which is why there are a number of - if you do this then ... statements in the draft. I don't think that there is anything in the base COSE document that is going to care about signature with recovery and the details can be left to an algorithm description when we get one. YMMV > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > ---- > > > > COMMENT: > > > > ------------------------------------------------------------------ > > > > ---- > > > > > > > > > > > > > > > > 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). > > > > > > [something doesn't seem to be showing up well in the text/plain > > > component here; I'll try to take a look at the updated I-D when it > > > lands] > > > > > > > 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 > > > > > > "popular" is not quite right, though maybe "oft-used"? > > > > [JLS] Ok - trying to change it just made me sad. Rewrote to > > > > A one such application-specific element would be to include a URI or > other pointer to where the data that is being hashed can be obtained. > > Thanks, that seems better on a few axes. > > > > > 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. > > > > > > I was thinking more the parallelism in "is both <x> and <y>", or > > > perhaps that "shorter" invites a comparison with something unnamed > > > ... I couldn't really pin my finger on it at the time. > > [JLS] The options were covered in the preceding sentences and I don't know > that you can get much shorter than a one byte encoding and still have > existence. > > Okay, let's leave it for the RFC Editor. > > > > > > > > > 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. > > > > > > I think this can depend on whether you see the application as doing > > > "I am going to obtain all the attributes" or "I am going to get a > > > value of attribute <X>". In the latter, you presumably stop once > > > you get a value, here, from the protected bucket. In the former > > > case, though, if you do "get all labels from the protected bucket, > > > put into local cache, then get all labels from the unprotected > > > bucket, put into the same cache", then a "last store wins" for the cache will > do the wrong thing. > > > If that's not a relevant "worry", sorry for the noise. > > [JLS] No it is a relevant worry. There are two buckets and if you combine the > buckets you had better combine them in the correct way. You are going to > need to know if the cache is last wins, first wins or go boom on duplicates. I am > not sure what I can say to make things clearer though. > > I think the core of the (potential) issue is "first" -- "first" assumes something > about what procedure is being used in a way that "priority over" > or "has precedence" does not, which is what I was trying to get at. (Going into > more detail about the procedure to use for which "first" makes sense feels like > it's going in the wrong direction.) How about /before they are obtained/and only if not present should they be obtained/ > > > > > > > > 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)" > > > > > > We have a MUST-level requirement to do something "where the ability > > > to do so exists". If we leave it to the reader to determine when > > > the ability to do so exists, I don't expect 100% accuracy in > > > practice, so I'm looking for a way that we can give clear guidance on when > this protection needs to be present. > > > > [JLS] Where the ability does not exist is when you do an AE algorithm. It can > be done everywhere else. (And don't get me started on all of the arguments > that I had with the OSCORE people about how important I thought it was to do > this.) Otherwise between the structure and the algorithm (AEAD) you can > always do this either in the protected attributes or in external data. > > Brainstorming (and feel free to do something completely different, or decide > that it's not worth it), maybe "(The only algorithm and message-type > combinations where this ability does not exist is when an authenticated > encryption only (not AEAD) symmetric cipher mode is used for a > [COSE_Encrypt*, COSE_Recipient*] message.)"? > > > > > * 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. > > > > > > I agree that it's just a restriction, but the way it's written right > > > now it feels like the core spec is making statements about what you > > > should assume to be the case for algorithm-dependent values, without > > > actually placing a requirement on the algorithm specifications to > > > provide that property. If we said that algorithm specs can impose a > > > similar requirement on which values are required to implement and > > > thus safe to omit, and suggested the range of -1 to - > > > 128 for those values, I wouldn't have a problem, since that makes it > > > clear that it's a property of the algorithm in question. > > > > [JLS] Does this read better? > > > > Integer labels in the range -1 to -128 can be omitted. Algorithms can assign > labels in this range where the ability to process the content of the label is > considered to be core to implementing the algorithm. Algorithms can assign > labels outside of this range where the ability to process the content of the label > is not considered to be core, but needs to be understood to correctly process > this instance. Integer labels in the range -129 to -65536 > <bcp14>SHOULD</bcp14> be included as these would be less common header > parameters that might not be generally supported. > > That helps, yes. Even better would be normative language, like "algorithms > MUST only assign labels in this range where [...]" :) My problem with a MUST is that I don't know what it means to be "core to implementing". I think that is too vague to make the MUST useful. > > > > > > > > * 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. > > > > > > I'm having trouble picturing this, but will trust you that it makes sense. > > > > > > > > > > > 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 > > > > > > I thought the COSE_Sign structure contained one or more > > > COSE_Signature structures. > > > > Yes it does. I think of the "signature" as the byte string as being different > from the COSE_Signature structure. This is referring to the first. > > Okay ... but even in this sense the "signature" is *indirectly* contained in > COSE_Sign, and I at least did not get the sense from this text that we intended > the "directly carries" sense of the term. Maybe we should leave a note to ask > the RFC Editor for help; I'm failing to come up with a good wording right now. > I am sure they will love me for this. > > > > > > > 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. > > > > > > I'm having trouble parsing that -- it feels circular to me. "In the > > > act of signing, the size of the payload you are signing is reduced > > > by the number of bytes that will be recovered." So what's the > > > payload, the longer thing or the shorter thing? > > > > [JLS] The payload that is encrypted is the longer thing. The payload that is > carried in the COSE message is the shorter thing. > > Using the same word to mean different things makes the reader work. I'd > support adding some adjectives, but won't insist on it. [JLS] Not a big issue - added "original" and "transmitted" as appropriate. > > > > > > > > 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 > > > > > > Oops, the referred-to question was "Am I reading this right that the > > > idea is to use capabilities to lock a key down to a single curve?" > > [JLS] Capabilities are not used to lock a key down to a single curve. The curve > is a field in the COSE_Key object. > > Okay, thanks for clarifying. > > > > > 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? > > > > > > I think it's pushing 12 weeks, what with C238 and the bulge that > > > accumulated in RFC-EDITOR (https://www.rfc- > editor.org/current_queue.php). > > > I'd happily approve a report if you want to file one. > > [JLS] done > > Thanks, verified! > > > > > 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 > > > > > > My main complaint here is that there's a "type error" -- PBES2 is > > > not a KDF (right?). I could tolerate dropping the last sentence > > > entirely, or a bland "Specific KDF constructions are needed to be > > > safely used with non-random secrets" (and no reference), but pointing to > Argon2 would also be fine. > > [JLS] Switched. > > > > > > > > > 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. > > > > > > Do we want to provide guidance in the doc, or is "kid" sufficiently > > > self- explanatory and obvious? > > [JLS] I think that it is obvious. I also think something like "password hint" > would be as well, but is not currently defined. > > Okay. > > > > > 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. > > > > > > I think we had someone (Barry?) mention on the telechat that we > > > might not need to put it in the registry since it was unclear who > > > else would need to reference it. So, thanks for stating a position > > > -- I trust that the responsible AD will do the right thing. > > > > > > > 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. > > > > > > Sigh. I wonder if I can convince any cryptographers to look at the > > > group communication document. > > > > [JLS] That is not where I would put the limited resources. I would have them > look at draft-ietf-lwig-curve-representations and ask if there are issues using > the same private key for an EdDSA signature and ECDH after doing the > mapping. I think I recently saw something on the CFRG list which had a pointer > to a paper saying that reuse for ECDH and ECDSA was ok. > > Fair enough. > > Thanks, as always, > > Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
