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

[Göran Selander <[e-mail]>]

On 2016-11-01 20:17, "COSE on behalf of Jim Schaad" <[e-mail]
on behalf of [e-mail]> wrote:

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

Just for the record: Hannes, Abhinav and Sandeep was also on this side
this time

Göran


> 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>
>> >>
>> >
>
>
>_______________________________________________
>COSE mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/cose