Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 26 October 2016 15:12 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A07129581; Wed, 26 Oct 2016 08:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level:
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIkkuXS1KTs4; Wed, 26 Oct 2016 08:12:43 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822791295A0; Wed, 26 Oct 2016 08:12:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 23CAEBE2E; Wed, 26 Oct 2016 16:12:41 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 653IYdixXj0B; Wed, 26 Oct 2016 16:12:37 +0100 (IST)
Received: from [172.20.5.168] (unknown [46.218.58.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC39CBE32; Wed, 26 Oct 2016 16:12:36 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477494757; bh=IyAwCYme1rexooUC2tVokFdpIYmG1zosFtx66pjjwjU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dzOS3NIyCJxC3Jtb/gORSzKSh5X9fgq8wKwzEQuMq1Sb63AGX+HSKl7Gh5LX8KNWD sopK+hn4DujQaFD4bFUt8ydP5Hi/xrzTXKWVmJjVQq0oWh8bBa9JOc61B0urwb7RMz a8BFiOt1kcG2qB1vpVLXEBdnr8dGIwo6NKzXz+lU=
To: Justin Richer <jricher@mit.edu>
References: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> <029401d227f7$5cdb7fa0$16927ee0$@augustcellars.com> <e9ca5f76-e0a1-2824-4ddc-b74c416c2f0f@cs.tcd.ie> <822A08BC-5710-48E6-BCC7-AC86A554EFEC@mit.edu> <476D703F-727E-49D9-89C1-F6FD1092D55E@mit.edu>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <94353594-ef7c-d909-605a-391ef2502c68@cs.tcd.ie>
Date: Wed, 26 Oct 2016 16:12:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <476D703F-727E-49D9-89C1-F6FD1092D55E@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="TVFXtQVeiowoUTsREEL02q9nPa2opDiWL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/_03GULhVJuwSDHs1G4eYWfAXyjs>
Cc: Jim Schaad <ietf@augustcellars.com>, cose-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org
Subject: Re: [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
Precedence: list
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: Wed, 26 Oct 2016 15:12:48 -0000
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 <jricher@MIT.EDU> >> 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 >>> <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> >>> 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:stephen.farrell@cs.tcd.ie >>>>> <mailto:stephen.farrell@cs.tcd.ie>] Sent: Sunday, October 16, >>>>> 2016 1:57 PM To: The IESG <iesg@ietf.org >>>>> <mailto:iesg@ietf.org>> Cc: draft-ietf-cose-msg@ietf.org >>>>> <mailto:draft-ietf-cose-msg@ietf.org>; Goeran Selander >>>>> <goran.selander@ericsson.com >>>>> <mailto:goran.selander@ericsson.com>>; cose-chairs@ietf.org >>>>> <mailto:cose-chairs@ietf.org>; goran.selander@ericsson.com >>>>> <mailto:goran.selander@ericsson.com>; cose@ietf.org >>>>> <mailto:cose@ietf.org> 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> >
- [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