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

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

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.html
>>>>>> <https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html>
>>
>