Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT)

From: Jim Schaad <[email-masked]>
Date: Sun, 2 Oct 2016 22:36:37 -0700

Stephen,

Answers and questions interspersed below along with some - yes I need to do that.  I should be able to get to those in the first half of this week.  Am building a github branch for responses if you want to look at things as we go along.

Jim

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2016 5:39 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Goeran Selander
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and
> COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-cose-msg-19: 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-msg/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> I think this is a fine design and well documented, (though
> long) and I'm sure we'll clear up the points below quickly enough. Some of them
> may need some discussion but others are mostly checking.
> 
> (1) general: I think the inclusion of CDDL is an error here and we'd be better off
> having someone (if interested) generate the CDDL schema stuff later on when/if
> CDDL is standardised/stabilised. Including it now creates the potential for
> breakage unnecessarily IMO. However, the WG did explicitly discuss iirc, so this
> is just a personal comment that I'm also in the rough on inclusion of CDDL in this
> spec.
> (As an example, for someone not familiar with CDDL, the inclusion of fragments
> interspersed in the text is distracting and potentially puzzling when one gets to
> the end of section 3.) However, I do think there are places where the CDDL is
> effectively normative despite what is said in the introduction, the ones I've
> spotted are below. (Happy to chat about 'em as I may be mistaken.) I also
> wondered if one could really implement this if all the CDDL was removed from
> the text, which is what I think would be required if CDDL were really to be
> informative. Anyway the places I think some more text may be needed are:

I build a version of the document with no CDDL, I have added some pointers to the use of "/" and "[+ FOO]" to the CDDL preview section at the top of the document.  I have also identified the structures Sig_structure and Enc_structure like I did the Mac_structure in the text.  (Also found a COSE_Encrypt that should have been a COSE_Encrypt0.)

> 
> (1.1) table 2: As-is the value type column seems to me to make CDDL normative.
> I don't see the natural language version that you said would be normative.
> 
> (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the CDDL normative.
> (Same with the use in 4.5 and Enc_structure in 5.3.)
> 
> (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3. (It is well-
> defined below the table in text though, so this one's borderline.)

The description for key_ops points to Table 3, so I think it is fully supplied.

> 
> (1.4) 11.2: it's not clear to me that a reader knows how to handle decoding of
> the two optional fields at the end (other and SuppPrivInfo) without looking at
> the CDDL. Can you explain? (That might be just my ignorance of CBOR, but
> wanted to check.)

I am not sure that I would know how to do it even with CDDL, however in this case that is a moot question as this structure is only encoded and never transmitted or decoded.

Will also note, that you have better eyes than me as I do not see two optional fields at the end.  I see one optional field at the end of two different arrays, so that would be a CBOR ignorance I think.

> 
> (2) 3.1, alg: so you're disallowing a setup where the kid alone identifies the key
> and algorithm to the recipient?
> That is used in some IETF protocols (OSPF iirc) so rhat's a pity, and will in those
> (maybe less common) cases consume a few bytes that could otherwise be
> saved.  I think, but am not sure, that the WG already discussed this, but if not,
> maybe worth a thought? (Or even a 2nd thought:-) And appendix A.1 is really
> puzzling - as it provides instructions for how to not follow a MUST in the body of
> the document.

I have come around to the feeling that the algorithm needs to be part of the value that is being authenticated as part of all of the messages.  This being the case, the only what that it can be enforced is to make the algorithm be a part of the protected attributes.   In my mind the cost of the 2 bytes for this purpose seems to be sufficiently small that including it does not seem to be a large burden.  

There were several people in the IoT world who felt as you that one could have an implicit algorithm and they did not want to spend the two bytes for the purpose of including it in the AEAD.  This being the case, I did provide the appendix to tell how to do this.  I expect that people are going to do this and not following the guidance that was provided about making sure that the algorithm is authenticated.  

> 
> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is clear enough, can you
> say what's meant here?

Derive bits was added to the JOSE documents in response to the W3C WebCrypto work where they wanted to be able to control that something could derive bits but not derive a key.  These were initially not present in this document but was added by request so that it would match what the JWK document had.  The description in JWK is "derive bits not to be used as a key".  Does that read better?  If so I can change this.

> 
> (4) Why not make deterministic ECDSA a MUST?  8.1.1 says:
> "Applications that specify ECDSA should evaluate the ability to get good random
> number generation and require deterministic signatures where poor random
> number generation exists."  I don't think that is sufficiently clear, nor realistic,
> and I don't recall this being discussed on the list (sorry if I'm forgetting) and bad
> random values are a killer flaw here that has happened in the wild.

It is not clear to me that many, if any, current packages support the concept of doing deterministic ECDSA.  If this case it seems to be odd that we would require it.   I can do some research to figure this out.

> 
> (5) Table 6, is this 25519 or 448? Where does it say?  Sorry if I'm being dumb
> here, but I don't see where you say which curve is specified, the definition of
> 'crv' says defined for this alg which I assume means listed in Table 6.

The value of 'crv' is defined in table 22.  The same algorithm is used to identify all of the curves.

> 
> (6) section 10: why MUST the kty values be present always?
> That seems unnecessary in some contexts and I don't get a security reason why
> it's needed e.g. if there's an alg id somewhere - can you explain? I can see folks
> omitting this leading to interop problems for not useful reasons. (Same
> comment applies in other cases where kty is a MUST, e.g.
> 12.1.2, 12.2.1.)

This follows what JOSE did in in RFC 7517 (JWK).  I might, or might not, agree with you that specifying an algorithm would be sufficient.  Consider one of the ECDH-ES variants.  It is defined to work with keys of the key type 'EC2' as well as 'OKP'.  These two key types have different sets of required parameters but some of them overlap.  Specifically, 'x' is in both but 'y' is only in one of them.  In this case the additional parameter of 'crv' could also be used to distinguish them but a generic piece of code looking only at the algorithm would not have enough detail.

> 
> (7) section 11: given that we know people will use human memorable secrets,
> why have you not defined codepoints for
> PBES2 (or the more commonly supported?) PBDKF2?  I'm fine if there's a reason,
> or even if it was discussed by the WG, but just wanted to check as I'd worry that
> folks will use the ones defined here with human memorable secrets no matter
> what the spec says so giving 'em something more tailored might be better.
> (OTOH, one could argue that making this apparent might be worse too I guess.)

This was part of the secondary algorithm draft which the WG decided not to do as part of the 'we are not going to do RSA at this time'.  I expect that I will write an individual draft to cover these.  It was also not clear to me that small devices were going to be using this type of secret to start with in any event.

> 
> (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported? Some
> protocols will allow for that and it seems wrong to disallow it when it could
> relatively easily be supported. For some applications where content is dealt with
> in store-and-forward mode, there may be situations (e.g.
> provisioning, "introduction") where E-E could be used.
> As-is, applications wanting that will have to hack the recipient DH-public into a
> home-grown structure (or use one of the COSE_Key labels from Table 19) and
> then treat that as ES-DH. That seems likely to lead to non-interop or security
> errors being made. I'd be fine if you even said how to re-use the structures
> currently defined for E-E btw and didn't introduce new structures.

See https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ for how this is being addressed.

> 
> (9) 16.4: I'm not sure expert review is right here.  What if the expert is asked to
> add SM2/SM4 while there is still no widely available non-Chinese text to describe
> those?  I think the expert ought enforce a "specification required" rule at least
> and maybe more.  (And ought never allow an algorithm with no specification
> publicly available.)

This view was advanced by several people in the WG as well.  My worry about this position is that it might encourage point squatting.  I cannot respond for other experts, but I would ask for a usable description of the algorithm.  If I was not familiar I would also request either additional review from CFRG and/or conference papers on the algorithm.  If it was not a publicly available specification, I would then assign a "non-optimal" point.  My expectation is that there are going to be more small networks of IoT devices than there are for TLS systems.  This means that it is more likely that localized algorithms may be desired.  

I am not against raising the level to specification required, but would worry about point squatting.

If this is not "expert review" what do you believe would be a better requirement?  I do not believe this should be dumped on either the IESG or CFRG. 

> 
> (10) 16.4 (and elsewhere maybe) I think this registry is missing a column - as is
> being done in the TLS WG, I think there should be a column saying if the IETF is
> happy enough with an algorithm and that getting a "Y" in that ought require
> standards action. (Or some similar scheme.) I don't think the standards-track
> range of codepoints is enough here, e.g. at some time we will want to
> deprecate things, and at other times we may want to define things for the future
> on the standards-track but not (yet) recommend their use.  The last bullet in
> 16.11 does help here, but I'd argue that we need to do more to protect the
> expert (and implementers) from the trickle of vanity/national algorithms/curves
> that are always being proposed.

I would not object to doing this.  While I don't know if the TLS experiment on this is going to work, I don't have any problems with participating in the same experiment here as well.

I am not sure what we should say for deprecation of algorithms here should be, they are going to live for a long time and new systems will probably ship with the same algorithms as long as they need to interoperate.  Consider the lighting use case that is being fought over in ACE right now.  You cannot put a new light bulb in that uses a different algorithm unless you are willing to start broadcasting two messages.  This is probably going to lead to very slow deprecation over time.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> - 1.4: the 2nd last paragraph is unclear to me. Probably just needs re-phrasing.

Which is unclear, the problem or the action?

> 
> - 1.5: I'd add a reference to RFC5116.

Reasonable and done.

> 
> - 3.1, crit: The statement that security libraries or application code can handle
> this is odd - isn't that an API requirement? (I'm not objecting, but it's odd.)

I agree that this is an API requirement.

> 
> - 3.1, "content type" is the space there intended?  If so, maybe add quotes or a
> comma or something to disambiguate the name and descriptive text? Same for
> other multi-word names here.

Given that this is the second person suggesting this (also in Gen-Art review). I am going to add a colon to deal with this.

> 
> - 3.1, "all the keys may need to be checked" - really?  Or do you mean all the
> keys associated with this kid?

I thought that this said keys associated with the kid.  Did you not read it this way?  If not then I will look at re-phrasing.

> 
> - 3.1, IV/Partial IV - I think it's an error to define this here. What if some
> algorithm can't use that kind of (0|partial)^IV but needs something else instead?
> Shouldn't all mechanism for handling IVs be defined by the algorithm/mode?
> (This isn't a discuss because I can't think of a good counter example and there'd
> be other ways around the problem too probably.)

I was originally going to make IV an algorithm specific parameter rather than a common parameter.  It was just so common that it seemed to be better to only define it once.  Any algorithm that needed different behavior could easily define an algorithm specific parameter for IV work instead.  So as you say an easy work around exists if needed.

> 
> - 4.1: signingTime is often needed with signatures. Isn't that common enough to
> want to define a way to do it, as an option?

There was a signingTime parameter in the original document.  The WG decided that it was not going to be needed enough at this point in time to have it defined now.  Additionally, there were some arguments over the format of the time field as some systems support a real clock and some only support a relative clock to when they were last started up.

> 
> - 4.1: If I sign with a private key corresponding to a 2047 or 2049 bit RSA public
> key modulus, then is it clear what to put where in the signature bstr? (Yes, that'd
> be dumb, but I wonder is what to do well enough defined, as I don't think you
> can rule it out in all cases.) Since you don't include RSA here I guess it's ok to skip
> this, but maybe you need to say that such issues need to be handled in the
> definition of signature algs.

I would say that this is not real, but I looked carefully at this when doing the EdDSA algorithms.  I will look at this and see if I cannot find some way to state this either generally or specifically.

> 
> - 4.3: "cannot bleed" isn't clear enough maybe, give an example perhaps where
> the decoder can fail to disambiguate a boundary?

I'll look at this and see if I cannot come up with better language.  However, there are no decode issues here.

> 
> 4.4, last para: I disagree that one must (even lowercase
> must) check the signing identity.  That's application behaviour and should be
> stated here in such concrete terms.
> At least s/must also/may also want to/

What if it is s/one must also/the application must also/

> 
> (Note - the above were comments on -18, but also seem to work based on -19.
> Subsequent comments are on -19.)
> 
> - 7.1: "starting at the same base IV" - are you missing "and incrementing" or
> something? Otherwise I think this seems unclear.

The "and incrementing" to me was implied in the first paragraph with the fact that this is intended to be used with the "partial IV" parameter.  I'll see if I can make this cleaner.

> 
> - 8.2.1: is the phrasing of the 1st para right? would it be better to say that the
> value of a key for EdDSA MUST NOT be used for ECDH and vice-versa. (Or maybe
> points instead of
> keys?)

Yeah, reads messy - let me think about it.

> 
> - 8.2.1: you need a reference for batch signing. (Or could it be omitted?)

I kept asking for one in the EdDSA document and never got one there, so I don't have one to push in here.

> 
> - section 9: I think it'd be good to be clearer about the strength of truncated
> MAC values. (And I can't recall the right thing to say off the top of my head:-)

When I was doing research about this, I could not find any solid results on truncated MAC values that people seemed to agree on. Most people seem to look at this as just a birthday attack so I would need to do more searching to find something useful.

> 
> - 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd be better to refer to
> the draft as that should be published soon. (Same for RFC3447 btw.)

Will do.

> 
>    [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/
> 
> - 12.4: Why "OKP"? And saying there's no "simple way" to do point validation
> seems fairly opaque, a reference there or explanatory text would be good. (Ah,
> it's in section 13, maybe shuffle the text or include a pointer.) Octet key pair
> doesn't seem like that good a name to me btw.

I copied "OKP" from draft-ietf-jose-cfrg-curves.  Since it has already gone through there I am reluctant to be different.

I will re-look at the order and make sure that there is something lying around for the acronym expansion.

> 
> - 12.5: The 1st para seems wrong. (Or at least is unclear to
> me.) "Encrypted with <foo> and <bar>" seems ambiguous anyway, does it mean
> double encryption or two parallel ciphertexts?
> (I assume the former.) What's the algebraic thing you're trying to explain?  It'd
> be good to provide that for such relatively complex operations I think. Is this
> what you mean?
> 
> 		KW(KDF(DH-shared),CEK)

Yes that is the formula and yes it makes sense to document it in that manner.

> 
> - Table 22: The EC2 or OKP value is fixed per curve and the cryptographic
> function being performed so seems unnecessary.
> Do you really need it so? Why? (I'm not buying that some future form of ECC
> might mean this is needed btw - and codepoints aren't expensive here, right? So
> other forms of ECC can burn codepoints when that's needed and in the
> meantime we'd save bytes and complexity.)

I am lost and don't understand what you are saying here.

* For EC2 key types the curve is fixed, but the cryptographic function is not fixed.
* For OKP key types, the curve/cryptographic function pair is fixed.

This is analogous to what is happing for the PKIX world.

Are you suggesting that something change?  If so what?  (Just so I can evaluate it.)

> 
> - Section 15: Do we have any examples of such a profile?  I think it'd be great if
> we did and could add an informative reference here (even if that's to an early I-
> D).

Will add a reference to draft-selander-ace-object-security.  (Which is being discussed in core not ace).

> 
> - section 19: I don't get how ECDSA is normative and the cfrg curves are not.
> Same for RFC6979. Maybe these all could do with checking? (No big deal IMO
> but maybe worth it.)

Yes, the cfrg curves should be normative and yes I will go back over the list.

> 
> - Appendices A.1 (as already noted) and A.2 are a puzzle.
> Why say in the body of the document to do <foo> and then an appendix that
> says how to do <not-foo>?

Answer above.

Jim

> 
> - Appendix C and the implementation status section: Many thanks - great to see
> that! (I didn't check 'em though:-)
> 
> - Thanks also for speedily handling the extensive secdir review.
> 
>    [2] https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 03 Oct 2016 10:04:40 +0200

Jim,

please do not remove the CDDL from the text.

We discussed this in the WG and the result was very clear.

(I do agree with Stephen's comments that the English text needs to be
completed where it does not fully mirror the CDDL yet.)

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 3 Oct 2016 11:16:22 +0100

Hi Jim,

On 03/10/16 06:36, Jim Schaad wrote:
> Stephen,
> 
> Answers and questions interspersed below along with some - yes I need
> to do that.  I should be able to get to those in the first half of
> this week.  Am building a github branch for responses if you want to
> look at things as we go along.

Good stuff. Some answers below where they seem useful.

> 
> Jim
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Wednesday, September 28,
>> 2016 5:39 AM To: The IESG <[email-masked]> Cc:
>> [email-masked]; Goeran Selander 
>> [email-masked]; [email-masked] Subject: Stephen
>> Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and 
>> COMMENT)
>> 
>> 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-msg/
>> 
>> 
>> 
>> long) and I'm sure we'll clear up the points below quickly enough.
>> Some of them may need some discussion but others are mostly
>> checking.
>> 
>> (1) general: I think the inclusion of CDDL is an error here and
>> we'd be better off having someone (if interested) generate the CDDL
>> schema stuff later on when/if CDDL is standardised/stabilised.
>> Including it now creates the potential for breakage unnecessarily
>> IMO. However, the WG did explicitly discuss iirc, so this is just a
>> personal comment that I'm also in the rough on inclusion of CDDL in
>> this spec. (As an example, for someone not familiar with CDDL, the
>> inclusion of fragments interspersed in the text is distracting and
>> potentially puzzling when one gets to the end of section 3.)
>> However, I do think there are places where the CDDL is effectively
>> normative despite what is said in the introduction, the ones I've 
>> spotted are below. (Happy to chat about 'em as I may be mistaken.)
>> I also wondered if one could really implement this if all the CDDL
>> was removed from the text, which is what I think would be required
>> if CDDL were really to be informative. Anyway the places I think
>> some more text may be needed are:
> 
> 
> I build a version of the document with no CDDL, I have added some
> pointers to the use of "/" and "[+ FOO]" to the CDDL preview section
> at the top of the document.  I have also identified the structures
> Sig_structure and Enc_structure like I did the Mac_structure in the
> text.  (Also found a COSE_Encrypt that should have been a
> COSE_Encrypt0.)
> 
>> 
>> (1.1) table 2: As-is the value type column seems to me to make CDDL
>> normative. I don't see the natural language version that you said
>> would be normative.
>> 
>> (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the
>> CDDL normative. (Same with the use in 4.5 and Enc_structure in
>> 5.3.)
>> 
>> (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3.
>> (It is well- defined below the table in text though, so this one's
>> borderline.)
> 
>> (1.4) 11.2: it's not clear to me that a reader knows how to handle
>> decoding of the two optional fields at the end (other and
>> SuppPrivInfo) without looking at the CDDL. Can you explain? (That
>> might be just my ignorance of CBOR, but wanted to check.)
> 
> I am not sure that I would know how to do it even with CDDL, however
> in this case that is a moot question as this structure is only
> encoded and never transmitted or decoded.
> 
> Will also note, that you have better eyes than me as I do not see two
> optional fields at the end.  I see one optional field at the end of
> two different arrays, so that would be a CBOR ignorance I think.

I'd say we should be able to kill this discuss point easily
with the changes you're making.

> 
>> 
>> (2) 3.1, alg: so you're disallowing a setup where the kid alone
>> identifies the key and algorithm to the recipient? That is used in
>> some IETF protocols (OSPF iirc) so rhat's a pity, and will in
>> those (maybe less common) cases consume a few bytes that could
>> otherwise be saved.  I think, but am not sure, that the WG already
>> discussed this, but if not, maybe worth a thought? (Or even a 2nd
>> thought:-) And appendix A.1 is really puzzling - as it provides
>> instructions for how to not follow a MUST in the body of the
>> document.
> 
> I have come around to the feeling that the algorithm needs to be part
> of the value that is being authenticated as part of all of the
> messages. 

Is that just a feeling of yours or are we confident it
represents WG consensus? (Honest question - I just don't
recall.)

> This being the case, the only what that it can be enforced
> is to make the algorithm be a part of the protected attributes.   In
> my mind the cost of the 2 bytes for this purpose seems to be
> sufficiently small that including it does not seem to be a large
> burden.
> 
> There were several people in the IoT world who felt as you that one
> could have an implicit algorithm and they did not want to spend the
> two bytes for the purpose of including it in the AEAD.  This being
> the case, I did provide the appendix to tell how to do this.  I
> expect that people are going to do this and not following the
> guidance that was provided about making sure that the algorithm is
> authenticated.

Right, but isn't that then pretty much an RFC6919 "MUST, but
we know you (sometimes) won't"? I just don't see how that helps
with interop.

I do agree that it's conceivable that the lack of an alg in
a protocol could lead to vulnerabilities. However, there are
clearly cases where a protocol can be secure without an
explicit alg, and we know that folks will do that optimisation
sometimes, so I think the most that'd be right is a SHOULD,
but likely a MAY is even better. (If however, there's a clear
WG consensus to take the RFC6919 route, then I'll get out of
the way, but with an "I told you so" in my back pocket;-)

> 
>> 
>> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is
>> clear enough, can you say what's meant here?
> 
> Derive bits was added to the JOSE documents in response to the W3C
> WebCrypto work where they wanted to be able to control that something
> could derive bits but not derive a key.  These were initially not
> present in this document but was added by request so that it would
> match what the JWK document had.  The description in JWK is "derive
> bits not to be used as a key".  Does that read better?  If so I can
> change this.

That is clearer yes. Maybe add a pointer to the JWK doc as well?
I'm not convinced of the utility myself though but so long as
it's clearly described then that'll sort this discuss point.

>> "Applications that specify ECDSA should evaluate the ability to get
>> good random number generation and require deterministic signatures
>> where poor random number generation exists."  I don't think that is
>> sufficiently clear, nor realistic, and I don't recall this being
>> discussed on the list (sorry if I'm forgetting) and bad random
>> values are a killer flaw here that has happened in the wild.
> 
> It is not clear to me that many, if any, current packages support the
> concept of doing deterministic ECDSA.  

But they don't to COSE either so I'm not clear that's a good
argument unless there's evidence that crypto libraries likely
to be used for COSE won't include deterministic ECDSA. (That
last would be a surprise given that deterministic is clearly
superior.)

> If this case it seems to be
> odd that we would require it.   I can do some research to figure this
> out.

Cool. Be interested in what you find.

> 
>> 
>> (5) Table 6, is this 25519 or 448? Where does it say?  Sorry if I'm
>> being dumb here, but I don't see where you say which curve is
>> specified, the definition of 'crv' says defined for this alg which
>> I assume means listed in Table 6.
> 

I'm still not getting that but didn't yet re-read the doc. I will
as we go so let's punt on this for the moment.

> 
>> 
>> (6) section 10: why MUST the kty values be present always? That
>> seems unnecessary in some contexts and I don't get a security
>> reason why it's needed e.g. if there's an alg id somewhere - can
>> you explain? I can see folks omitting this leading to interop
>> problems for not useful reasons. (Same comment applies in other
>> cases where kty is a MUST, e.g. 12.1.2, 12.2.1.)
> 
> This follows what JOSE did in in RFC 7517 (JWK).  I might, or might
> not, agree with you that specifying an algorithm would be sufficient.
> Consider one of the ECDH-ES variants.  It is defined to work with
> keys of the key type 'EC2' as well as 'OKP'.  These two key types
> have different sets of required parameters but some of them overlap.
> Specifically, 'x' is in both but 'y' is only in one of them.  In this
> case the additional parameter of 'crv' could also be used to
> distinguish them but a generic piece of code looking only at the
> algorithm would not have enough detail.

Hmm. Still not convinced, but I'll look again as we go. This is
I guess similar to the issue with the alg as a MUST in that we
can be pretty sure some folks will ignore that MUST I think.

> 
>> 
>> (7) section 11: given that we know people will use human memorable
>> secrets, why have you not defined codepoints for PBES2 (or the more
>> commonly supported?) PBDKF2?  I'm fine if there's a reason, or even
>> if it was discussed by the WG, but just wanted to check as I'd
>> worry that folks will use the ones defined here with human
>> memorable secrets no matter what the spec says so giving 'em
>> something more tailored might be better. (OTOH, one could argue
>> that making this apparent might be worse too I guess.)
> 
> This was part of the secondary algorithm draft which the WG decided
> not to do as part of the 'we are not going to do RSA at this time'.
> I expect that I will write an individual draft to cover these.  It
> was also not clear to me that small devices were going to be using
> this type of secret to start with in any event.

Fair enough. Consider this bit sorted.

> 
>> 
>> (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported?
>> Some protocols will allow for that and it seems wrong to disallow
>> it when it could relatively easily be supported. For some
>> applications where content is dealt with in store-and-forward mode,
>> there may be situations (e.g. provisioning, "introduction") where
>> E-E could be used. As-is, applications wanting that will have to
>> hack the recipient DH-public into a home-grown structure (or use
>> one of the COSE_Key labels from Table 19) and then treat that as
>> ES-DH. That seems likely to lead to non-interop or security errors
>> being made. I'd be fine if you even said how to re-use the
>> structures currently defined for E-E btw and didn't introduce new
>> structures.
> 

Hmm. No 25519? Odd that. But fair enough I suppose if it's being
handled somewhere.

> 
>> 
>> (9) 16.4: I'm not sure expert review is right here.  What if the
>> expert is asked to add SM2/SM4 while there is still no widely
>> available non-Chinese text to describe those?  I think the expert
>> ought enforce a "specification required" rule at least and maybe
>> more.  (And ought never allow an algorithm with no specification 
>> publicly available.)
> 
> This view was advanced by several people in the WG as well.  My worry
> about this position is that it might encourage point squatting.  I
> cannot respond for other experts, but I would ask for a usable
> description of the algorithm.  If I was not familiar I would also
> request either additional review from CFRG and/or conference papers
> on the algorithm.  If it was not a publicly available specification,
> I would then assign a "non-optimal" point.  My expectation is that
> there are going to be more small networks of IoT devices than there
> are for TLS systems.  This means that it is more likely that
> localized algorithms may be desired.

Yeah but desired-by-someone != desirable-for-the-Internet :-)

I would worry about less well reviewed lightweight crypto in this
space - that'll be attractive for implementers/vendors but might
not be a good plan.

> If this is not "expert review" what do you believe would be a better
> requirement?  I do not believe this should be dumped on either the
> IESG or CFRG.

I think expert review with specification required is maybe right
with the guidance tightened up along the lines you state above.
(But see below.)

> 
>> 
>> (10) 16.4 (and elsewhere maybe) I think this registry is missing a
>> column - as is being done in the TLS WG, I think there should be a
>> column saying if the IETF is happy enough with an algorithm and
>> that getting a "Y" in that ought require standards action. (Or some
>> similar scheme.) I don't think the standards-track range of
>> codepoints is enough here, e.g. at some time we will want to 
>> deprecate things, and at other times we may want to define things
>> for the future on the standards-track but not (yet) recommend their
>> use.  The last bullet in 16.11 does help here, but I'd argue that
>> we need to do more to protect the expert (and implementers) from
>> the trickle of vanity/national algorithms/curves that are always
>> being proposed.
> 
> I would not object to doing this.  While I don't know if the TLS
> experiment on this is going to work, I don't have any problems with
> participating in the same experiment here as well.

Great. If we do that then I think the expert's job can be easier
as it'll be much clearer what the IETF likes. (And that'd sort
my discuss point #9 too.)

> 
> I am not sure what we should say for deprecation of algorithms here
> should be, they are going to live for a long time and new systems
> will probably ship with the same algorithms as long as they need to
> interoperate.  Consider the lighting use case that is being fought
> over in ACE right now.  You cannot put a new light bulb in that uses
> a different algorithm unless you are willing to start broadcasting
> two messages.  This is probably going to lead to very slow
> deprecation over time.

Well, it's always slow. But I think if we can clearly see from the
registry what the IETF currently likes, then implementers should
have an easier time. I'd have no objection if the extra column
wasn't just a binary y/n, but I think it's hard to come up with
good semantics for anything else. (Where "y" just means that the
IETF currently likes the registry entry.)

I'll go over these later if that's ok, gotta do another thing
right now;-) Please ping me if you need a response before you
do edits though.

Cheers,
S.

- 1.4: the 2nd last paragraph is unclear to me. Probably just needs
re-phrasing.
>> - 3.1, crit: The statement that security libraries or application
>> code can handle this is odd - isn't that an API requirement? (I'm
>> not objecting, but it's odd.)
> 
>> - 3.1, "content type" is the space there intended?  If so, maybe
>> add quotes or a comma or something to disambiguate the name and
>> descriptive text? Same for other multi-word names here.
> 
> Given that this is the second person suggesting this (also in Gen-Art
> review). I am going to add a colon to deal with this.
> 
>> 
>> - 3.1, "all the keys may need to be checked" - really?  Or do you
>> mean all the keys associated with this kid?
> 
> I thought that this said keys associated with the kid.  Did you not
> read it this way?  If not then I will look at re-phrasing.
> 
>> 
>> - 3.1, IV/Partial IV - I think it's an error to define this here.
>> What if some algorithm can't use that kind of (0|partial)^IV but
>> needs something else instead? Shouldn't all mechanism for handling
>> IVs be defined by the algorithm/mode? (This isn't a discuss because
>> I can't think of a good counter example and there'd be other ways
>> around the problem too probably.)
> 
> I was originally going to make IV an algorithm specific parameter
> rather than a common parameter.  It was just so common that it seemed
> to be better to only define it once.  Any algorithm that needed
> different behavior could easily define an algorithm specific
> parameter for IV work instead.  So as you say an easy work around
> exists if needed.
> 
>> 
>> - 4.1: signingTime is often needed with signatures. Isn't that
>> common enough to want to define a way to do it, as an option?
> 
> There was a signingTime parameter in the original document.  The WG
> decided that it was not going to be needed enough at this point in
> time to have it defined now.  Additionally, there were some arguments
> over the format of the time field as some systems support a real
> clock and some only support a relative clock to when they were last
> started up.
> 
>> 
>> - 4.1: If I sign with a private key corresponding to a 2047 or 2049
>> bit RSA public key modulus, then is it clear what to put where in
>> the signature bstr? (Yes, that'd be dumb, but I wonder is what to
>> do well enough defined, as I don't think you can rule it out in all
>> cases.) Since you don't include RSA here I guess it's ok to skip 
>> this, but maybe you need to say that such issues need to be handled
>> in the definition of signature algs.
> 
> I would say that this is not real, but I looked carefully at this
> when doing the EdDSA algorithms.  I will look at this and see if I
> cannot find some way to state this either generally or specifically.
> 
>> 
>> - 4.3: "cannot bleed" isn't clear enough maybe, give an example
>> perhaps where the decoder can fail to disambiguate a boundary?
> 
> I'll look at this and see if I cannot come up with better language.
> However, there are no decode issues here.
> 
>> 
>> 4.4, last para: I disagree that one must (even lowercase must)
>> check the signing identity.  That's application behaviour and
>> should be stated here in such concrete terms. At least s/must
>> also/may also want to/
> 
>> (Note - the above were comments on -18, but also seem to work based
>> on -19. Subsequent comments are on -19.)
>> 
>> - 7.1: "starting at the same base IV" - are you missing "and
>> incrementing" or something? Otherwise I think this seems unclear.
> 
> The "and incrementing" to me was implied in the first paragraph with
> the fact that this is intended to be used with the "partial IV"
> parameter.  I'll see if I can make this cleaner.
> 
>> 
>> - 8.2.1: is the phrasing of the 1st para right? would it be better
>> to say that the value of a key for EdDSA MUST NOT be used for ECDH
>> and vice-versa. (Or maybe points instead of keys?)
> 
>> - section 9: I think it'd be good to be clearer about the strength
>> of truncated MAC values. (And I can't recall the right thing to say
>> off the top of my head:-)
> 
> When I was doing research about this, I could not find any solid
> results on truncated MAC values that people seemed to agree on. Most
> people seem to look at this as just a birthday attack so I would need
> to do more searching to find something useful.
> 
>> 
>> - 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd be
>> better to refer to the draft as that should be published soon.
>> (Same for RFC3447 btw.)
> 
> Will do.
> 
>> 
>> - 12.4: Why "OKP"? And saying there's no "simple way" to do point
>> validation seems fairly opaque, a reference there or explanatory
>> text would be good. (Ah, it's in section 13, maybe shuffle the text
>> or include a pointer.) Octet key pair doesn't seem like that good a
>> name to me btw.
> 
> I copied "OKP" from draft-ietf-jose-cfrg-curves.  Since it has
> already gone through there I am reluctant to be different.
> 
>> - 12.5: The 1st para seems wrong. (Or at least is unclear to me.)
>> "Encrypted with <foo> and <bar>" seems ambiguous anyway, does it
>> mean double encryption or two parallel ciphertexts? (I assume the
>> former.) What's the algebraic thing you're trying to explain?
>> It'd be good to provide that for such relatively complex operations
>> I think. Is this what you mean?
>> 
>> KW(KDF(DH-shared),CEK)
> 
>> - Table 22: The EC2 or OKP value is fixed per curve and the
>> cryptographic function being performed so seems unnecessary. Do you
>> really need it so? Why? (I'm not buying that some future form of
>> ECC might mean this is needed btw - and codepoints aren't expensive
>> here, right? So other forms of ECC can burn codepoints when that's
>> needed and in the meantime we'd save bytes and complexity.)
> 
> * For EC2 key types the curve is fixed, but the cryptographic
> function is not fixed. * For OKP key types, the curve/cryptographic
> function pair is fixed.
> 
>> - Section 15: Do we have any examples of such a profile?  I think
>> it'd be great if we did and could add an informative reference here
>> (even if that's to an early I- D).
> 
>> - section 19: I don't get how ECDSA is normative and the cfrg
>> curves are not. Same for RFC6979. Maybe these all could do with
>> checking? (No big deal IMO but maybe worth it.)
> 
>> - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say
>> in the body of the document to do <foo> and then an appendix that 
>> - Appendix C and the implementation status section: Many thanks -
>> great to see that! (I didn't check 'em though:-)
>> 
>> [2]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html
>> 
> 
> 
> _______________________________________________ COSE mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/cose
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Oct 2016 09:55:38 -0700

Carsten,

I built this version for review to make sure that all of the necessary text was present not as a step to removing the CDDL from the document.

Jim

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Monday, October 03, 2016 1:05 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Stephen Farrell' <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with
> DISCUSS and COMMENT)
> 
> Jim,
>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 5 Oct 2016 20:16:25 -0700

Stephen,

Couple of items below asking for input.  However, I think that I have dealt with most of the issues and will be pulling them into the version on github.

Jim

Editors copy is at https://cose-wg.github.io/cose-spec/
A diff to -19 can be found at https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/id/draft-ietf-cose-msg&url2=https://cose-wg.github.io/cose-spec/draft-ietf-cose-msg.txt

> Sent: Monday, October 03, 2016 3:16 AM
> To: Jim Schaad <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]

This is a question you would need to ask the chairs rather than me because I am a very strong partisan on this issue.  The question was discussed multiple times and I think that it was a WG consensus, but it is possible that it represents a brow beating from a very strong partisan.

> the way, but with an "I told you so" in my back pocket;-)

Let's leave it here for now and revisit when we have more info and we are doing an update/advancement of the document.

> it's clearly described then that'll sort this discuss point.

Done

> Cool. Be interested in what you find.

It seems to be much more widely implemented than I thought.  I have sent a note to the COSE mailing list to see if there are objections to making this change.

> as we go so let's punt on this for the moment.

ack

> can be pretty sure some folks will ignore that MUST I think.

Until we have more info - I think we just differ on this one.
 
> Fair enough. Consider this bit sorted.

ack

> Hmm. No 25519? Odd that. But fair enough I suppose if it's being

They are thinking about putting it in - so it will probably show up given some time.

> my discuss point #9 too.)

Done

> > review). I am going to add a colon to deal with this.

Done

> > read it this way?  If not then I will look at re-phrasing.

Need input

> > parameter for IV work instead.  So as you say an easy work around

No action taken.

> > clock and some only support a relative clock to when they were last

No action taken

> > cannot find some way to state this either generally or specifically.

Added the following sentence:
            Algorithms MUST specify padding if the signature value is not a multiple of 8 bits.

> > However, there are no decode issues here.

I have modified this text.

> > What if it is s/one must also/the application must also/

Looking for comment

> > parameter.  I'll see if I can make this cleaner.

I have re-written this text.

> > Yeah, reads messy - let me think about it.

I have done a re-write on this.

> > so I don't have one to push in here.

No action - but I think it needs to be stated

> > to do more searching to find something useful.

I did some more research and all I could find was:
- Birthday attack for collisions
- brute search for forgery on a message 2^(r-1)-1 attempts
- Changing the algorithm to use a shorter MAC code which can lead to a drastically smaller search space, but of course is prevented by MAC-ing the algorithm identifier.

I am not sure that including any of these, except maybe the last one, adds anything to the list of considerations.

> >> better to refer to the draft as that should be published soon.

Done

> > lying around for the acronym expansion.

Done

> > Yes that is the formula and yes it makes sense to document it in that

Done

> > Are you suggesting that something change?  If so what?  (Just so I

Request for information

> > is being discussed in core not ace).

done

> > Yes, the cfrg curves should be normative and yes I will go back over

Shifted around a couple of items

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 12:05:10 +0100

Hi Jim,

On 06/10/16 04:16, Jim Schaad wrote:
> Stephen,
> 
> Couple of items below asking for input.  However, I think that I have
> dealt with most of the issues and will be pulling them into the
> version on github.

I'll trim to just those input'y bits...

>>>> (2) 3.1, alg: so you're disallowing a setup where the kid
>>>> alone identifies the key and algorithm to the recipient? That
>>>> is used in some IETF protocols (OSPF iirc) so rhat's a pity,
>>>> and will in those (maybe less common) cases consume a few bytes
>>>> that could otherwise be saved.  I think, but am not sure, that
>>>> the WG already discussed this, but if not, maybe worth a
>>>> thought? (Or even a 2nd thought:-) And appendix A.1 is really
>>>> puzzling - as it provides instructions for how to not follow a
>>>> MUST in the body of the document.
>>> 
>>> I have come around to the feeling that the algorithm needs to be
>>> part of the value that is being authenticated as part of all of
>>> the messages.
>> 
>> Is that just a feeling of yours or are we confident it represents
>> WG consensus? (Honest question - I just don't recall.)
> 
> This is a question you would need to ask the chairs rather than me
> because I am a very strong partisan on this issue.  The question was
> discussed multiple times and I think that it was a WG consensus, but
> it is possible that it represents a brow beating from a very strong
> partisan.

Fair enough - cose WG chairs, what do you think?

>>>> "Applications that specify ECDSA should evaluate the ability to
>>>> get good random number generation and require deterministic
>>>> signatures where poor random number generation exists."  I
>>>> don't think that is sufficiently clear, nor realistic, and I
>>>> don't recall this being discussed on the list (sorry if I'm
>>>> forgetting) and bad random values are a killer flaw here that
>>>> has happened in the wild.
>>> 
>>> It is not clear to me that many, if any, current packages support
>>> the concept of doing deterministic ECDSA.
>> 
>> argument unless there's evidence that crypto libraries likely to be
>> used for COSE won't include deterministic ECDSA. (That last would
>> be a surprise given that deterministic is clearly superior.)
>> 
>>> If this case it seems to be odd that we would require it.   I can
>>> do some research to figure this out.
>> 
> It seems to be much more widely implemented than I thought.  I have
> sent a note to the COSE mailing list to see if there are objections
> to making this change.

Saw that and thanks. Be interesting to see if anyone objects
to this good change.

>>>> - 3.1, "all the keys may need to be checked" - really?  Or do
>>>> you mean all the keys associated with this kid?
>>> 
>>> I thought that this said keys associated with the kid.  Did you
>>> not read it this way?  If not then I will look at re-phrasing.
>>> 
> 
> Need input

If you said "all the keys associated with this kid may need
to be checked" then I think it'd be clear

>>> What if it is s/one must also/the application must also/

I still think "must" isn't right and "may" is correct

>>>> cryptographic function being performed so seems unnecessary. Do
>>>> you really need it so? Why? (I'm not buying that some future
>>>> form of ECC might mean this is needed btw - and codepoints
>>>> aren't expensive here, right? So other forms of ECC can burn
>>>> codepoints when that's needed and in the meantime we'd save
>>>> bytes and complexity.)
>>> 
>>> function is not fixed. * For OKP key types, the
>>> curve/cryptographic function pair is fixed.
>>> 

I'm suggesting that the key type is not needed once you
know what curve you're dealing with and hence the "MUST
check" is just adding cruft.

Cheers,
S.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 6 Oct 2016 19:04:07 -0700

> From: COSE [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, October 06, 2016 4:05 AM
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> If you said "all the keys associated with this kid may need to be checked" then I
> think it'd be clear

That seems fine - I'll get this done.

> I still think "must" isn't right and "may" is correct

I think you are wrong, but it is not worth arguing about.  I'll get this in.

> I'm suggesting that the key type is not needed once you know what curve you're
> dealing with and hence the "MUST check" is just adding cruft.

Right - so this is what an EC2 key looks like:

{
    1:2,
    -1:1, 
    -2:h'65eda5...de439c08551d', 
    -3:h'1e52ed...cd0084d19c'
  }

A shared secret key looks like:

{
   1:4, 
    -1:h'849b57...ea6c427188'
  },

And a hypothetical RSA key would look like

{
    1:3,
    -1:h'83425...25239fa',
   -2:3
}

Since label for curve is '-1', one would need to infer that it was a curve by being an integer and then based on the curve know what the rest of the parameters are.  The key type ('1') lets you know what the negative labels are.  So you cannot infer that the curve field is a curve field based on the text value as the same label is used multiple ways for different key types.

Jim

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Oct 2016 20:27:37 -0700

I have just published a draft -20 of the document.

I believe that this document addresses all of the issues that have been raised by the IESG.

This document does not address the blocking IANA issues.  I should have these addressed and a new version published by the start of next week.

Jim

---

From: [email-masked]
Date: Tue, 11 Oct 2016 07:26:45 -0400

Thank you, Jim.  I'll double check before you post the next version.

Kathleen 

Please excuse typos, sent from handheld device 

> On Oct 10, 2016, at 11:27 PM, Jim Schaad <[email-masked]> wrote:
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose