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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 28 Sep 2016 05:39:03 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-cose-msg-19: 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:
----------------------------------------------------------------------

I think this is a fine design and well documented, (though
long) and I'm sure we'll clear up the points below quickly
enough. Some of them may need some discussion but others are
mostly checking.

(1) general: I think the inclusion of CDDL is an error here
and we'd be better off having someone (if interested)
generate the CDDL schema stuff later on when/if CDDL is
standardised/stabilised. Including it now creates the
potential for breakage unnecessarily IMO. However, the WG did
explicitly discuss iirc, so this is just a personal comment
that I'm also in the rough on inclusion of CDDL in this spec.
(As an example, for someone not familiar with CDDL, the
inclusion of fragments interspersed in the text is
distracting and potentially puzzling when one gets to the end
of section 3.) However, I do think there are places where the
CDDL is effectively normative despite what is said in the
introduction, the ones I've spotted are below. (Happy to chat
about 'em as I may be mistaken.) I also wondered if one could
really implement this if all the CDDL was removed from the
text, which is what I think would be required if CDDL were
really to be informative. Anyway the places I think some more
text may be needed are:

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

(1.2) 4.4, 2nd list point 1: the use of Sig_structure makes
the CDDL normative. (Same with the use in 4.5 and
Enc_structure in 5.3.)

(1.3) 7.1, the key_ops value is only specified in CDDL, in
Table 3. (It is well-defined below the table in text though,
so this one's borderline.)

(1.4) 11.2: it's not clear to me that a reader knows how to
handle decoding of the two optional fields at the end (other
and SuppPrivInfo) without looking at the CDDL. Can you
explain? (That might be just my ignorance of CBOR, but wanted
to check.)

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

(3) 7.1: key_op 8, "derive bits" - I don't think this usage
is clear enough, can you say what's meant here?

(4) Why not make deterministic ECDSA a MUST?  8.1.1 says:
"Applications that specify ECDSA should evaluate the ability
to get good random number generation and require
deterministic signatures where poor random number generation
exists."  I don't think that is sufficiently clear, nor
realistic, and I don't recall this being discussed on the
list (sorry if I'm forgetting) and bad random values are a
killer flaw here that has happened in the wild.

(5) Table 6, is this 25519 or 448? Where does it say?  Sorry
if I'm being dumb here, but I don't see where you say which
curve is specified, the definition of 'crv' says defined for
this alg which I assume means listed in Table 6.

(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.)

(7) section 11: given that we know people will use human
memorable secrets, why have you not defined codepoints for
PBES2 (or the more commonly supported?) PBDKF2?  I'm fine if
there's a reason, or even if it was discussed by the WG, but
just wanted to check as I'd worry that folks will use the
ones defined here with human memorable secrets no matter what
the spec says so giving 'em something more tailored might be
better. (OTOH, one could argue that making this apparent
might be worse too I guess.) 

(8) 12.4: Why is no ephemeral-ephemeral (E-E) variant
supported? Some protocols will allow for that and it seems
wrong to disallow it when it could relatively easily be
supported. For some applications where content is dealt with
in store-and-forward mode, there may be situations (e.g.
provisioning, "introduction") where E-E could be used.
As-is, applications wanting that will have to hack the
recipient DH-public into a home-grown structure (or use one
of the COSE_Key labels from Table 19) and then treat that as
ES-DH. That seems likely to lead to non-interop or security
errors being made. I'd be fine if you even said how to re-use
the structures currently defined for E-E btw and didn't
introduce new structures.

(9) 16.4: I'm not sure expert review is right here.  What if
the expert is asked to add SM2/SM4 while there is still no
widely available non-Chinese text to describe those?  I think
the expert ought enforce a "specification required" rule at
least and maybe more.  (And ought never allow an algorithm
with no specification publicly available.)

(10) 16.4 (and elsewhere maybe) I think this registry is
missing a column - as is being done in the TLS WG, I think
there should be a column saying if the IETF is happy enough
with an algorithm and that getting a "Y" in that ought
require standards action. (Or some similar scheme.) I don't
think the standards-track range of codepoints is enough here,
e.g. at some time we will want to deprecate things, and at
other times we may want to define things for the future on
the standards-track but not (yet) recommend their use.  The
last bullet in 16.11 does help here, but I'd argue that we
need to do more to protect the expert (and implementers) from
the trickle of vanity/national algorithms/curves that are
always being proposed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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