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

[Jim Schaad <[e-mail]>]

Another thread dealing with this issue includes https://www.ietf.org/mail-archive/web/cose/current/msg00981.html  - basically the subject is 'make "alg" field optional'

Usual suspects (Göran, Ludwig, Francesca) on one side, me and a couple of others on the other side.  Interestingly the antis included Mike who argued for this in the JOSE.

Jim




> -----Original Message-----
> From: Göran Selander [mailto:[e-mail]]
> Sent: Wednesday, October 26, 2016 9:37 PM
> To: Stephen Farrell <[e-mail]>; Justin Richer <[e-mail]>
> Cc: Jim Schaad <[e-mail]>; [e-mail]; The IESG
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS
> and COMMENT)
> 
> Stephen, Justin,
> 
> About item (2) - mandatory alg header - this was discussed on different
> occasions. Several voices were heard in support of a setting where a kid
> identifies key and algorithm. One thread starts here:
> 
> https://www.ietf.org/mail-archive/web/cose/current/msg00544.html
> 
> Appendix A was the proposed solution to resolve the conflict of mandatory alg
> header, but the case with only kid is discouraged, both in appendix A and in the
> section on COSE_Encrypt0
> https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-5.2
> 
> draft-ietf-core-object-security, which is the first and currently only adopted
> application of COSE, uses the COSE_Encrypt0 structure, does not have the alg
> header and has a kid header (“context identifier”, recommended to be 64 bit
> pseudo-random).
> 
> 
> Since you ask: Of course we would prefer to apply an endorsed version of COSE
> instead of making an exception from an exception. Appendix A in a sense opens
> a door. When what is mandatory in the body isn’t really mandatory, it is a
> smaller step to deviate from the recommendations.
> 
> I think the contentious point was the potential non-uniqueness of kid. If I may
> wish: If we maintain mandatory alg header, then maybe some text about when
> kid header only could be acceptable, for example sufficiently large random kids,
> if we agree on that?
> 
> Göran
> 
> 
> On 2016-10-26 17:12, "Stephen Farrell" <[e-mail]> wrote:
> 
> >
> >Hiya,
> >
> >On 26/10/16 16:06, Justin Richer wrote:
> >> Hi Stephen,
> >>
> >> Sorry for the delay on answering #2 and #6 below. After researching
> >> the list archives and issue tracker, neither Kepeng nor I can find
> >> discussion on either issue. If there is such discussion in the
> >> archives, we would appreciate the working group members pointing us
> >> all to it.
> >>
> >> But as such, these both seem to be items that were added to the spec
> >> by the editor without controversy or contention from the working
> >> group. Therefore, it does appear to reflect consensus as there were
> >> no objections raised. We both think that the items are OK as is, but
> >> we’d like to give the working group a couple days to respond
> >> otherwise if that’s not the case for anyone.
> >
> >Thanks for checking. If the WG don't say they'd like a change within a
> >couple of days, I'll clear the discuss. (Please do ping me though, I
> >may forget;-)
> >
> >Cheers,
> >S.
> >
> >
> >>
> >> Thank you,
> >>
> >> — Justin & Kepeng, as COSE chairs
> >>
> >>
> >>> On Oct 19, 2016, at 8:59 AM, Justin Richer <[e-mail]>
> >>> wrote:
> >>>
> >>> Hi Stephen,
> >>>
> >>> The consensus of the working group after Yokohama was to make the
> >>> CDDL non-normative and still use it as a description/example format.
> >>>
> >>> https://www.ietf.org/mail-archive/web/cose/current/msg00802.html
> >>> <https://www.ietf.org/mail-archive/web/cose/current/msg00802.html>
> >>>
> >>> I believe the current draft reflects that state. Yes, CDDL syntax is
> >>> peppered throughout the document as illustration, but it’s the
> >>> English text that’s normative.
> >>>
> >>> One point that was discussed was that if the draft did not use CDDL,
> >>> then another description language would likely need to be made up to
> >>> make human-readable examples in the text. The group felt that it was
> >>> better to use an existing (even if
> >>> unfinished/unofficial) description format but remove the normative
> >>> dependency.
> >>>
> >>> — Justin, as chair.
> >>>
> >>>> On Oct 16, 2016, at 3:41 PM, Stephen Farrell
> >>>> <[e-mail] <mailto:[e-mail]>>
> >>>> wrote:
> >>>>
> >>>>
> >>>> Hiya,
> >>>>
> >>>> Dear cose-chairs - there is stuff in this discuss for you to deal
> >>>> with. (Just putting that there in case you're not delving down into
> >>>> the body of the mails:-)
> >>>>
> >>>> On 16/10/16 22:50, Jim Schaad wrote:
> >>>>> I think we dealt with all of the comments.  I cannot help you with
> >>>>> getting chair response.
> >>>>>
> >>>>> See below for my one issue.
> >>>>>
> >>>>> Jim
> >>>>>
> >>>>>
> >>>>>> -----Original Message----- From: Stephen Farrell
> >>>>>> [mailto:[e-mail]
> >>>>>> <mailto:[e-mail]>] Sent: Sunday, October 16,
> >>>>>> 2016 1:57 PM To: The IESG <[e-mail] <mailto:[e-mail]>>
> >>>>>> Cc: [e-mail]
> >>>>>> <mailto:[e-mail]>; Goeran Selander
> >>>>>> <[e-mail]
> >>>>>> <mailto:[e-mail]>>; [e-mail]
> >>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>> <mailto:[e-mail]> Subject: Stephen Farrell's Discuss on
> >>>>>> draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)
> >>>>>>
> >>>>>> Stephen Farrell has entered the following ballot position for
> >>>>>> draft-ietf-cose-msg-20: 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
> >>>>>> <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/
> >>>>>> <https://datatracker.ietf.org/doc/draft-ietf-cose-msg/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>------------------------------------------------------------------
> >>>>>>---
> >>>>>>-
> >>>>>>
> >>>>>>
> >DISCUSS:
> >>>>>>
> >>>>>>------------------------------------------------------------------
> >>>>>>---
> >>>>>>-
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >Thanks for the updates in -20. I think we've only the following points
> >left. Note
> >>>>>> that 2 of those are questions to the WG chairs and not to Jim.
> >>>>>>
> >>>>>> (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.
> >>>>>>
> >>>>>> Can you help me see that the changes there are such that CDDL is
> >>>>>> ok as informative? I'm not sure but as I read it there is still
> >>>>>> no natural language statement that a "counter signature" is one
> >>>>>> (or more) COSE_Signature values.
> >>>>>
> >>>>> In section 1.3 the following text was added:
> >>>>>
> >>>>> Two syntaxes from CDDL appear in this document as shorthand.
> >>>>> These are:
> >>>>>
> >>>>> FOO / BAR - indicates that either FOO or BAR can appear here [+
> >>>>> FOO] - indicates that the type FOO appears one or more times in an
> >>>>> array
> >>>>>
> >>>>> The value from the table is:
> >>>>>
> >>>>> COSE_Signature / [+ COSE_Signature ]
> >>>>>
> >>>>> Section 4.1 contains the text:
> >>>>>
> >>>>> The CBOR object that carries the signature and information about
> >>>>> the signature is called the COSE_Signature structure.
> >>>>>
> >>>>>> From that I think that all of the needed normative text is
> >>>>>> present.
> >>>>
> >>>> Yeah, I get that. But then I think you've embedded some CDDL
> >>>> notation at least as normative. (I mean the constructs you describe
> >>>> with FOO/BAR above.)
> >>>>
> >>>> While I do start to feel pedantry-panic that I'm saying it, if
> >>>> really treating CDDL as informative, I think you ought say in text
> >>>> that one or more COSE_Signature fields need to be in a counter
> >>>> signature.
> >>>>
> >>>> But I'm gonna clear that anyway as the whole CDDL is not normative
> >>>> thing is really pretence IMO and there's no point in me joining in
> >>>> with that further.
> >>>>
> >>>> That means that clearing this discuss is now solely down to the
> >>>> chairs saying they're happy that Jim's positions do reflect wG
> >>>> consensus.
> >>>>
> >>>> Cheers, S.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> (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 think we left the mail thread on this with you saying "Best to
> >>>>>> ask the chairs if they agree that this is WG consensus,"
> >>>>>> as you're an admitteddly strong partisan on this topic.
> >>>>>>
> >>>>>> So, COSE chairs - what's your take? (If you say this is ok with
> >>>>>> the WG, I'll clear.)
> >>>>>>
> >>>>>> (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.)
> >>>>>>
> >>>>>> I think this is the similar to discuss point (2) above.
> >>>>>>
> >>>>>> So again, COSE chairs, can you confirm that this design does
> >>>>>> reflect WG consensus and isn't just a thorough and good editor
> >>>>>> getting his way? (If you say this is ok with the WG, I'll clear.)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>------------------------------------------------------------------
> >>>>>>---
> >>>>>>-
> >>>>>>
> >>>>>>
> >COMMENT:
> >>>>>>
> >>>>>>------------------------------------------------------------------
> >>>>>>---
> >>>>>>-
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat more about
> 'em
> >>>>>> if that's useful.
> >>>>>>
> >>>>>> - 1.4: the 2nd last paragraph is unclear to me. Probably just
> >>>>>> needs re-phrasing.
> >>>>>>
> >>>>>> - 1.5: I'd add a reference to RFC5116.
> >>>>>>
> >>>>>> - 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.
> >>>>>>
> >>>>>> - 3.1, "all the keys may need to be checked" - really?  Or do you
> >>>>>> mean all the keys associated with this kid?
> >>>>>>
> >>>>>> - 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.)
> >>>>>>
> >>>>>> - 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?
> >>>>>>
> >>>>>> - 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.
> >>>>>>
> >>>>>> - 4.3: "cannot bleed" isn't clear enough maybe, give an example
> >>>>>> perhaps where the decoder can fail to disambiguate a boundary?
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> - 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?)
> >>>>>>
> >>>>>> - 8.2.1: you need a reference for batch signing. (Or could it be
> >>>>>> omitted?)
> >>>>>>
> >>>>>> - 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:-)
> >>>>>>
> >>>>>> - 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.)
> >>>>>>
> >>>>>> [1]
> >>>>>> https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/
> >>>>>> <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.
> >>>>>>
> >>>>>> - 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.)
> >>>>>>
> >>>>>> - 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
> >>>>>> says how to do <not-foo>?
> >>>>>>
> >>>>>> - 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.htm
> >>>>>> l
> >>>>>> <https://www.ietf.org/mail-archive/web/secdir/current/msg06801.ht
> >>>>>> ml>
> >>
> >