Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT)

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Monday, June 15, 2020 4:05 PM
> To: Jim Schaad <[e-mail]>
> Cc: 'The IESG' <[e-mail]>; [e-mail]; cose-
> [e-mail]; 'Matthew Miller' <[e-mail]>;
> [e-mail]
> 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 <[e-mail]>
> > Sent: Wednesday, June 10, 2020 6:44 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; Matthew Miller <[e-mail]>;
> > [e-mail]
> > 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-signat
> > 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.

> 
> 
> >
> > ----------------------------------------------------------------------
> > 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.

> >    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.

> >
> >    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.

> 
> > 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.

> >       *  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.

> 
> >       *  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.

> 
> >       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.

> 
> > 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.

> > 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
> 
> > 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.

> > 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.

> > Acknowledgments
> >
> > Göran could probably get his proper name, now.
> > [JLS] I think he probably would as well.
> 
> I think I've seen the RPC proactively do this, but nothing stops us from helping.

Jim

> 
> Thanks for all the discussion and updates!
> 
> -Ben