Subject: [COSE] AD review of draft-ietf-cose-msg

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 2 Sep 2016 22:58:25 -0400

Hello,

Thank you all for your work on draft-ietf-cose-msg.  I mainly have
nits to fix in my comments, which is bound to happen with such a long
draft.  Sorry for the time it took to turn this review around.

I haven't looked at the shepherd report yet, but it will need to
include any remaining downrefs - assuming some of the idnits for this
can be cleaned up.  The idnits need to be checked as well as there are
some formatting problems that can easily be corrected.

Nits:

Abstract

Change from:
   Concise Binary Object Representation (CBOR) is data format designed
   for small code size and small message size.  There is a need for the
   ability to have the basic security services defined for this data
   format.
To:
   Concise Binary Object Representation (CBOR) is a data format designed
   for small code size and small message size.  There is a need for the
   ability to have basic security services defined for this data
   format.

Introduction:
Change from:
   There has been an increased focus on the small, constrained devices
   that make up the Internet of Things (IoT).
To:
   There has been an increased focus on small, constrained devices
   that make up the Internet of Things (IoT).
Change from:
   A need exists to provide message security
   services for IoT and using CBOR as the message encoding format makes
   sense.
To:
   A need exists to provide message security
   services for IoT, using CBOR as the message encoding format makes
   sense.

Section 1.1
Change from:
   o  Define a single top message structure so that encrypted, signed
      and MACed messages can easily identified and still have a
      consistent view.
To:
   o  Define a single top message structure so that encrypted, signed
      and MACed messages can easily be identified and still have a
      consistent view.

For the following, I am not sure I am parsing this correctly, can it
be rephrased:
   o  Signed messages separate the concept of protected and unprotected
      parameters that are for the content and the signature.

Section 3:
In the 'protected' bucket definition:
change from:
      Senders SHOULD encode an zero length map as a zero
      length string rather than as a zero length map (encoded as h'a0').
To:
      Senders SHOULD encode a zero length map as a zero
      length string rather than as a zero length map (encoded as h'a0').
s/an/a/

Change from:
      After encoding the map the value is
      wrapped in the binary object.
To:
      After encoding the map, the value is
      wrapped in the binary object.

Section 4: Second sentence:

Can this be reworded from:
   COSE_Sign allows
   for one or more signers to be applied to a single content.
To: COSE_Sign allows
   for one or more signers to be applied to a single piece of content.

It doesn't read well to me, but if that is a well understood way to
phrase this, let me know.

Section 4.1: Can the second "about" be changed to "for" or
"describing"?  It took me a few times reading this to get it.
current:
   There are provisions for parameters
   about the content and parameters about the signature to be carried
   along with the signature itself.

Section 4.1 middle of second paragraph:
Change from:
   Support of different communities of
   recipients is the primary reason that signers choose to include more
   than one signature.
To:
   Support for different communities of
   recipients is the primary reason that signers choose to include more
   than one signature.

Section 5.4, second bullet #3
Is this intended to be "Direct and Direct"?
          Direct and Direct Key Agreement:  The key is determined by the
          key and algorithm in the recipient structure.  …

Section 6.4:
Change from:
   How to verify a MAC are:
To:
   The steps of how to verify a MAC are:

You don't save a line of text, so it would be better to include what
is needed for it to be easily understood.

Section 9, first paragraph:
Remove the parens and s/One/A MAC/
Change from:
   (One cannot, for example, be used to prove the identity
   of the sender to a third party.)
To: A MAC cannot, for example, be used to prove the identity
   of the sender to a third party.

*Many of the places where parenthesis are used, it would be better to
remove them and leave the sentence as part of the paragraph.

Section 9.1.1: second sentence should be more clear that the "method
is an attack method.  How about change from:
   The current best method appears to be a
   brute force attack on the key.
To:
   The current best attack method appears to be
   brute force on the key.

Section 9.2.1, first bullet, second sentence:
Remove the last comma.
change from:
      If this is not the case, an attacker will be able to
      generate a message with a valid tag given two message, tag pairs.
To:
      If this is not the case, an attacker will be able to
      generate a message with a valid tag given two message tag pairs.

Same section, the second bullet doesn't read well.  The current text:
   o  If the same key is used for both encryption and authentication
      operations, using CBC modes an attacker can produce messages with
      a valid authentication code.
How about:
   o  When using CBC mode, if the same key is used for both encryption
and authentication
      operations, an attacker can produce messages with
      a valid authentication code.

Section 10.2, 4th paragraph, second to last sentence:
Change from (s/user/use/):
   Less constrained devices will want to be able to user
   larger messages and are more willing to generate new keys for every
   operation.  This favors larger values of L and M.
To:
   Less constrained devices will want to be able to use
   larger messages and are more willing to generate new keys for every
   operation.  This favors larger values of L and M.

Same section, third to last bullet, add "is":
Change from:
   o  If the 'alg' field present, it MUST match the AES-CCM algorithm
      being used.
To:
   o  If the 'alg' field is present, it MUST match the AES-CCM algorithm
      being used.

Section 12.1.2.1

Is PFS spelled out in the draft before this use?  Just checking…  It
might not be as it appears as "perfect forward secrecy (no
abbreviation) and RFC4949 in section 12.4

Section 15, second paragraph:

It reads oddly to me…
   Applications are therefore intended to profile the usage of this
   document.  This section provides a set of guidelines and topics that
   applications need to consider when using this document.

What do you mean by 'profile the usage'?  Should this be worded differently?

Section 16.2

I think it's a little confusing to state the registry values require
expert review, then buried in the 'label' description say it can be
specification required.  Wouldn't it be more clear to state that a
dependency exists and a specification is required in the intro
paragraph for this section?  This applies to the other sections that
also require a specification as it don't seem that all registries do.

Section 16.7

There is a spurious > character
   It is requested that IANA create a new registry "COSE Key Type
   Registry"> The

Section 16.11, third bullet:  Can you rephrase the following sentence,
it could read better:
      Some
      of the ranges are restricted in range, items that are not expected
      to be common or are not expected to be used in constrained
      environments should be assigned to values which will encode to
      longer byte strings.

Section 17.

I don't see theft that says this section should be removed upon
publication.  Is it supposed to be retained in the document?   Just
checking as I thought the boiler plate for this has them being
removed.

Section 18: This bullet is difficult to read, is it missing an "or"?:
   o  Use of 'direct' as a recipient algorithm combined with a second
      recipient algorithm, either directly in a separate message,
      exposes the direct key to the second recipient.
How about:
   o  Use of 'direct' as a recipient algorithm combined with a second
      recipient algorithm, either directly or in a separate message,
      exposes the direct key to the second recipient.

Thank you!  It's nice to see this get wrapped up in a timely manner.
-- 

Best regards,
Kathleen

---

From: Jim Schaad <[email-masked]>
Date: Sat, 3 Sep 2016 14:59:06 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Friday, September 02, 2016 7:58 PM
> To: [email-masked]
> Subject: [COSE] AD review of draft-ietf-cose-msg
> 
> Hello,
> 
> Thank you all for your work on draft-ietf-cose-msg.  I mainly have nits to fix in
> my comments, which is bound to happen with such a long draft.  Sorry for the
> time it took to turn this review around.
> 
> I haven't looked at the shepherd report yet, but it will need to include any
> remaining downrefs - assuming some of the idnits for this can be cleaned up.
> The idnits need to be checked as well as there are some formatting problems
> that can easily be corrected.

The formatting issues are going to need to be fixed either by the RFC Editor or by a new fix to xml2rfc.  It has to do with the fact that I do a hanging text list for a sentence rather than for a key word followed by punctuation.

>    ability to have basic security services defined for this data

Done

>    that make up the Internet of Things (IoT).

Done

>    services for IoT, using CBOR as the message encoding format makes

Done

>       and MACed messages can easily be identified and still have a

Done

> 
> For the following, I am not sure I am parsing this correctly, can it be rephrased:

Does this work?
   o Signed messages distinguish between the protected and unprotected parameters that relate to the content from those that relate to the signature.

>       length string rather than as a zero length map (encoded as h'a0').

Done

>       wrapped in the binary object.

Done

> It doesn't read well to me, but if that is a well understood way to phrase this, let
> me know.

How does this work?
    COSE_Sign allows for one or more signatures to be applied to the same content.

> 
> Section 4.1: Can the second "about" be changed to "for" or "describing"?  It took
> me a few times reading this to get it.
> current:

Does this work?
        Parameters related to the content and parameters related to the signature are carried along with the signature itself.

>    recipients is the primary reason that signers choose to include more

Done

>           key and algorithm in the recipient structure.  …

If I use the section titles it becomes:
     Direct Encryption and Direct Key Agreement: ...
I think this might be better - what do you think?

> You don't save a line of text, so it would be better to include what is needed for
> it to be easily understood.

Done

>    of the sender to a third party.

Done

> 
> *Many of the places where parenthesis are used, it would be better to remove
> them and leave the sentence as part of the paragraph.

I have included a note to the RFC editor to look at this as an issue.  I think that they should stay as that is the way that I thought it should be at the time.

> 
> Section 9.1.1: second sentence should be more clear that the "method is an
> attack method.  How about change from:

Changed to 
   The current best attack appears to be brute force on the key.

>       generate a message with a valid tag given two message tag pairs.

Changed to 
     given to message and tag pairs

>    o  When using CBC mode, if the same key is used for both encryption and
> authentication

Done

>    operation.  This favors larger values of L and M.

Done

>    o  If the 'alg' field is present, it MUST match the AES-CCM algorithm

Done, along with the rest of the cut and pastes from here.

> 
> Section 12.1.2.1
> 
> Is PFS spelled out in the draft before this use?  Just checking…  It might not be as
> it appears as "perfect forward secrecy (no

Does not appear to be - It is now expanded

> What do you mean by 'profile the usage'?  Should this be worded differently?

Does this make more sense?

        It is intended that a profile of this document be created that defines the interopability requirements for that specific application.
        This section provides a set of guidelines and topics that need to be considered when profiling this document.

> 
> Section 16.2
> 
> I think it's a little confusing to state the registry values require expert review,
> then buried in the 'label' description say it can be specification required.
> Wouldn't it be more clear to state that a dependency exists and a specification is
> required in the intro paragraph for this section?  This applies to the other
> sections that also require a specification as it don't seem that all registries do.
> 
> Section 16.7
> 

Typo should have been a period.
Done

> 
> Section 16.11, third bullet:  Can you rephrase the following sentence, it could
> read better:
>       Some

Does this work any better?

              The length of the encoded value should be weighed against how many code points of that length are left, the capabilities of devices for expected use, and the number of code points left that encode to that size.

> checking as I thought the boiler plate for this has them being removed.

Currently it is just as a comment in the XML to the RFC Editor rather than as explicit text in the document.  I think this meets the spirit of the request in RFC 7942.

>       exposes the direct key to the second recipient.

I have just removed the secondary clause entirely.  I don't think it helps anything anymore.

> Thank you!  It's nice to see this get wrapped up in a timely manner.

Jim

> --
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Jim Schaad <[email-masked]>
Date: Sat, 3 Sep 2016 15:58:47 -0700

> sections that also require a specification as it don't seem that all registries do.

I separated this issue because I think it is potentially going to need more discussion than any of the other issues.

>From the IANA point of view, I want to keep these registry rules simple.  That is, I want IANA to treat the registries as if everything is expert review.

Given that I want to break down the label ranges.  Would it makes sense to move this language from here to section 16.11 so that it is clear that this will be for the expert reviewers to look at rather than for IANA to look at?

Jim

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 4 Sep 2016 22:21:15 -0400

Hi Jim,

Thanks for the very quick response!  Inline.

>    o Signed messages distinguish between the protected and unprotected parameters that relate to the content from those that relate to the signature.

Yes, that reads better to me, thank you!

>     COSE_Sign allows for one or more signatures to be applied to the same content.

Ah, that's better, thank you!

>         Parameters related to the content and parameters related to the signature are carried along with the signature itself.

Thank you, that helps me.

> I think this might be better - what do you think?

Yes, please do expand that, thank you!  That makes sense now.  :-)

> I have included a note to the RFC editor to look at this as an issue.  I think that they should stay as that is the way that I thought it should be at the time.

OK, fair enough. That's a good way to figure out the best solution.  Thanks.

>    The current best attack appears to be brute force on the key.

Better, thanks!

>      given to message and tag pairs

Ah, ok, thanks.  At least there was something to fix there ;-)

> Done, along with the rest of the cut and pastes from here.

Cool, thanks.

> Does not appear to be - It is now expanded

Great, thanks!  Easy to miss this in a big document when text gets moved around.

>         This section provides a set of guidelines and topics that need to be considered when profiling this document.

Much better, thank you!!

> Typo should have been a period.

Thanks!

>               The length of the encoded value should be weighed against how many code points of that length are left, the capabilities of devices for expected use, and the number of code points lef…

Yes, thank you!

> Currently it is just as a comment in the XML to the RFC Editor rather than as explicit text in the document.  I think this meets the spirit of the request in RFC 7942.

Ah, ok, so it is meant to be removed.  This may come up in the IESG
reviews.  If it does either one of us can respond quickly.  Good to
know the intent.  I'd be fine with whatever the WG wanted, but need to
know what that is, which is why I asked.  It helps to have this
knowledge ahead of time.

> I have just removed the secondary clause entirely.  I don't think it helps anything anymore.

OK, thanks.

Thank you!  I see you have a separate response for the IANA question.
I'll try to get back to you tomorrow or Tuesday on that as it is
getting late.

Have a nice weekend and thanks again for all your work on this.
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Sep 2016 14:00:40 -0400

> I separated this issue because I think it is potentially going to need more discussion than any of the other issues.

Good, thanks.

> Given that I want to break down the label ranges.  Would it makes sense to move this language from here to section 16.11 so that it is clear that this will be for the expert reviewers to look at ra…

Well, this just applies to section 16.2, right?  If so, then I think
the intro to just the subsection that requires a specification should
also include that information.  If it's buried within the subsection,
I think it gets lost for the draft review process.  It might work out
fine when it's used to add to the registry, but it should be as clear
as possible.  If it were just in 16.11, I think that would be
confusing since it doesn't apply to all the registries established by
this draft.  ANother sentence or two in the introduction should be all
this requires to make it more clear.  WHat do you think?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Sep 2016 11:39:56 -0700

> Sent: Tuesday, September 06, 2016 11:01 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [COSE] AD review of draft-ietf-cose-msg
> 
specification
> required.
> >> Wouldn't it be more clear to state that a dependency exists and a
> >> specification is required in the intro paragraph for this section?
> >> This applies to the other sections that also require a specification as
it don't
> seem that all registries do.
> >>
> >
> > I separated this issue because I think it is potentially going to need
more
> discussion than any of the other issues.
> 
> Good, thanks.
> 
> >
> > From the IANA point of view, I want to keep these registry rules simple.
That
> is, I want IANA to treat the registries as if everything is expert review.
> >
> > Given that I want to break down the label ranges.  Would it makes sense
to
> move this language from here to section 16.11 so that it is clear that
this will be
> for the expert reviewers to look at rather than for IANA to look at?
> 
> Well, this just applies to section 16.2, right?  If so, then I think the
intro to just
> the subsection that requires a specification should also include that
information.
> If it's buried within the subsection, I think it gets lost for the draft
review
> process.  It might work out fine when it's used to add to the registry,
but it
> should be as clear as possible.  If it were just in 16.11, I think that
would be
> confusing since it doesn't apply to all the registries established by this
draft.
> ANother sentence or two in the introduction should be all this requires to
make
> it more clear.  WHat do you think?

No, this issue applies to section 16.2 (Header parameters), 16.4
(Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve
Parameters).   Since it is for more than just one section I think it could
merit its own bullet point in 16.11 and that would be reasonable.

Some additional text would also work as well, but it is not a one place fix.

Jim

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Sep 2016 15:22:19 -0400

On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad <[email-masked]> wrote:
> Parameters).

Oh, that's right...

   Since it is for more than just one section I think it could
> Some additional text would also work as well, but it is not a one place fix.

I think it will be more clear in each section since you can do it with
just a sentence in the intro.  It should help avoid problems later
since each section adds to a registry or creates one.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Sep 2016 15:10:00 -0700

So something along the lines of this?

The registry is to be created as Expert Review Required.  There are
additional restrictions for sub-ranges of values. Expert review guidelines
are provided in Section 16.11.

Jim

> Sent: Tuesday, September 06, 2016 12:22 PM
> >> >> I think it's a little confusing to state the registry values
> >> >> require expert review, then buried in the 'label' description say
> >> >> it can be
> > specification
> >> required.
> >> the
> >> this
just a
> sentence in the intro.  It should help avoid problems later since each
section
> adds to a registry or creates one.
> 
> Thanks,
> Kathleen
> 
> 
> >
> > Jim
> >
> >>
> >>
> >> Thanks,
> >> Kathleen
> >>
> >> >
> >> > Jim
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >>

---

From: [email-masked]
Date: Fri, 9 Sep 2016 22:11:58 -0400

Sorry I didn't see this message, not sure why.

Hmmm, how about for the sections that have the need for a specification, you add in something like:

Please excuse typos, sent from handheld device 

> On Sep 6, 2016, at 6:10 PM, Jim Schaad <[email-masked]> wrote:
> 
> additional requirements for sub-ranges of values,

> where a specification may also be necessary. Expert review guidelines

Thanks,
Kathleen

---

From: Jim Schaad <[email-masked]>
Date: Sat, 10 Sep 2016 14:30:09 -0700

OK,

I am going to suggest that the paragraph should read as follows:

It is requested that IANA create a new registry entitled "COSE Header
Parameters".  The registry should be created as Expert Review Required.
Guidelines for the experts is provided in Section 16.11.  It should be noted
that in additional to the expert review, some portions of the registry
require a specification, potentially on standards track, be supplied as
well.

Jim

> From: COSE [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, September 09, 2016 7:12 PM
> Hmmm, how about for the sections that have the need for a specification,
you
> add in something like:
> >>> Some additional text would also work as well, but it is not a one
> >>> place
> > fix.
> >>

---

From: [email-masked]
Date: Sat, 10 Sep 2016 19:27:06 -0400

> On Sep 10, 2016, at 5:30 PM, Jim Schaad <[email-masked]> wrote:
> 
> OK,
> 

Thanks, that wording is helpful as that wasn't entirely clear to me.  Let me know when it's ready.  I still need to dig into the downrefs, but that won't take long.

Thanks,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 Sep 2016 15:24:38 -0400

Hello,

top-posting.  I just went through all of the downrefs and the only 2
that are not in the downref registry are RFC3610 and RFC7539.

Both have been referenced normatively before, RFC3610 by RFC4309,
RFC5084, RFC5412, and RFC5669 and RFC7539 by RFC7905.  I'll make a
note of this when I start the last call and am adding them to the
registry as I believe they are community accepted normative
references.

Thank you,
Kathleen

-- 

Best regards,
Kathleen