[COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Sun, 16 October 2016 20:56 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cose@ietf.org
Delivered-To: cose@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 631D1129439; Sun, 16 Oct 2016 13:56:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com>
Date: Sun, 16 Oct 2016 13:56:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/bIXQDEZLxXT47JRtC-XmSpDgZrw>
Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org
Subject: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.17
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Oct 2016 20:56:57 -0000
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. (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
- [COSE] Stephen Farrell's Discuss on draft-ietf-co… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Justin Richer
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Justin Richer
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Kathleen Moriarty
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Göran Selander
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Carsten Bormann
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Göran Selander
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Göran Selander
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Göran Selander
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Göran Selander