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

[Jim Schaad <[e-mail]>]

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]]
> Sent: Sunday, October 16, 2016 1:57 PM
> 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-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
> 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:
> ----------------------------------------------------------------------
> 
> 
> 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.

> 
>    (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/
> 
> - 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