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

[Jim Schaad <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, September 28, 2016 5:39 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Goeran Selander
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> 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
>