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

[Benjamin Kaduk <[e-mail]>]

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


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

My preference would be to bring the text into this document, but I'd like
to hear from others.

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

Ah, excellent.

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

[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"?

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

Okay.

>    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

Okay.

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

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

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.

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

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

Ah, okay.

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

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

>       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

I thought the COSE_Sign structure contained one or more COSE_Signature
structures.

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

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

Okay.

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

Okay.

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

That probably works.  (I was just expecting "information identifying the
key" or "information about the key".)

>    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

Not when I wrote this :)

>    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

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?"

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

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.

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

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

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

Got it, thanks.

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

You have a lot of company :)

> 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

(I think Alvaro(?) also remarked on this and you replied there too.)

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

Yeah, it was just a side note since it will go away.  Thanks for updating
it!

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

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.

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

I think I've seen the RPC proactively do this, but nothing stops us from
helping.

Thanks for all the discussion and updates!

-Ben