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

[Stephen Farrell <[e-mail]>]

Hi Jim,

On 03/10/16 06:36, Jim Schaad wrote:
> Stephen,
> 
> Answers and questions interspersed below along with some - yes I need
> to do that.  I should be able to get to those in the first half of
> this week.  Am building a github branch for responses if you want to
> look at things as we go along.

Good stuff. Some answers below where they seem useful.

> 
> Jim
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[e-mail]] Sent: Wednesday, September 28,
>> 2016 5:39 AM 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-19: (with DISCUSS and 
>> COMMENT)
>> 
>> 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:
> 
> 
> I build a version of the document with no CDDL, I have added some
> pointers to the use of "/" and "[+ FOO]" to the CDDL preview section
> at the top of the document.  I have also identified the structures
> Sig_structure and Enc_structure like I did the Mac_structure in the
> text.  (Also found a COSE_Encrypt that should have been a
> COSE_Encrypt0.)
> 
>> 
>> (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.)
> 
> The description for key_ops points to Table 3, so I think it is fully
> supplied.
> 
>> 
>> (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.)
> 
> I am not sure that I would know how to do it even with CDDL, however
> in this case that is a moot question as this structure is only
> encoded and never transmitted or decoded.
> 
> Will also note, that you have better eyes than me as I do not see two
> optional fields at the end.  I see one optional field at the end of
> two different arrays, so that would be a CBOR ignorance I think.

I'd say we should be able to kill this discuss point easily
with the changes you're making.

> 
>> 
>> (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 have come around to the feeling that the algorithm needs to be part
> of the value that is being authenticated as part of all of the
> messages. 

Is that just a feeling of yours or are we confident it
represents WG consensus? (Honest question - I just don't
recall.)

> This being the case, the only what that it can be enforced
> is to make the algorithm be a part of the protected attributes.   In
> my mind the cost of the 2 bytes for this purpose seems to be
> sufficiently small that including it does not seem to be a large
> burden.
> 
> There were several people in the IoT world who felt as you that one
> could have an implicit algorithm and they did not want to spend the
> two bytes for the purpose of including it in the AEAD.  This being
> the case, I did provide the appendix to tell how to do this.  I
> expect that people are going to do this and not following the
> guidance that was provided about making sure that the algorithm is
> authenticated.

Right, but isn't that then pretty much an RFC6919 "MUST, but
we know you (sometimes) won't"? I just don't see how that helps
with interop.

I do agree that it's conceivable that the lack of an alg in
a protocol could lead to vulnerabilities. However, there are
clearly cases where a protocol can be secure without an
explicit alg, and we know that folks will do that optimisation
sometimes, so I think the most that'd be right is a SHOULD,
but likely a MAY is even better. (If however, there's a clear
WG consensus to take the RFC6919 route, then I'll get out of
the way, but with an "I told you so" in my back pocket;-)

> 
>> 
>> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is
>> clear enough, can you say what's meant here?
> 
> Derive bits was added to the JOSE documents in response to the W3C
> WebCrypto work where they wanted to be able to control that something
> could derive bits but not derive a key.  These were initially not
> present in this document but was added by request so that it would
> match what the JWK document had.  The description in JWK is "derive
> bits not to be used as a key".  Does that read better?  If so I can
> change this.

That is clearer yes. Maybe add a pointer to the JWK doc as well?
I'm not convinced of the utility myself though but so long as
it's clearly described then that'll sort this discuss point.

> 
>> 
>> (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.
> 
> It is not clear to me that many, if any, current packages support the
> concept of doing deterministic ECDSA.  

But they don't to COSE either so I'm not clear that's a good
argument unless there's evidence that crypto libraries likely
to be used for COSE won't include deterministic ECDSA. (That
last would be a surprise given that deterministic is clearly
superior.)

> If this case it seems to be
> odd that we would require it.   I can do some research to figure this
> out.

Cool. Be interested in what you find.

> 
>> 
>> (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.
> 
> The value of 'crv' is defined in table 22.  The same algorithm is
> used to identify all of the curves.

I'm still not getting that but didn't yet re-read the doc. I will
as we go so let's punt on this for the moment.

> 
>> 
>> (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.)
> 
> This follows what JOSE did in in RFC 7517 (JWK).  I might, or might
> not, agree with you that specifying an algorithm would be sufficient.
> Consider one of the ECDH-ES variants.  It is defined to work with
> keys of the key type 'EC2' as well as 'OKP'.  These two key types
> have different sets of required parameters but some of them overlap.
> Specifically, 'x' is in both but 'y' is only in one of them.  In this
> case the additional parameter of 'crv' could also be used to
> distinguish them but a generic piece of code looking only at the
> algorithm would not have enough detail.

Hmm. Still not convinced, but I'll look again as we go. This is
I guess similar to the issue with the alg as a MUST in that we
can be pretty sure some folks will ignore that MUST I think.

> 
>> 
>> (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.)
> 
> This was part of the secondary algorithm draft which the WG decided
> not to do as part of the 'we are not going to do RSA at this time'.
> I expect that I will write an individual draft to cover these.  It
> was also not clear to me that small devices were going to be using
> this type of secret to start with in any event.

Fair enough. Consider this bit sorted.

> 
>> 
>> (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.
> 
> See https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
> for how this is being addressed.

Hmm. No 25519? Odd that. But fair enough I suppose if it's being
handled somewhere.

> 
>> 
>> (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.)
> 
> This view was advanced by several people in the WG as well.  My worry
> about this position is that it might encourage point squatting.  I
> cannot respond for other experts, but I would ask for a usable
> description of the algorithm.  If I was not familiar I would also
> request either additional review from CFRG and/or conference papers
> on the algorithm.  If it was not a publicly available specification,
> I would then assign a "non-optimal" point.  My expectation is that
> there are going to be more small networks of IoT devices than there
> are for TLS systems.  This means that it is more likely that
> localized algorithms may be desired.

Yeah but desired-by-someone != desirable-for-the-Internet :-)

I would worry about less well reviewed lightweight crypto in this
space - that'll be attractive for implementers/vendors but might
not be a good plan.

> 
> I am not against raising the level to specification required, but
> would worry about point squatting.
> 
> If this is not "expert review" what do you believe would be a better
> requirement?  I do not believe this should be dumped on either the
> IESG or CFRG.

I think expert review with specification required is maybe right
with the guidance tightened up along the lines you state above.
(But see below.)

> 
>> 
>> (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.
> 
> I would not object to doing this.  While I don't know if the TLS
> experiment on this is going to work, I don't have any problems with
> participating in the same experiment here as well.

Great. If we do that then I think the expert's job can be easier
as it'll be much clearer what the IETF likes. (And that'd sort
my discuss point #9 too.)

> 
> I am not sure what we should say for deprecation of algorithms here
> should be, they are going to live for a long time and new systems
> will probably ship with the same algorithms as long as they need to
> interoperate.  Consider the lighting use case that is being fought
> over in ACE right now.  You cannot put a new light bulb in that uses
> a different algorithm unless you are willing to start broadcasting
> two messages.  This is probably going to lead to very slow
> deprecation over time.

Well, it's always slow. But I think if we can clearly see from the
registry what the IETF currently likes, then implementers should
have an easier time. I'd have no objection if the extra column
wasn't just a binary y/n, but I think it's hard to come up with
good semantics for anything else. (Where "y" just means that the
IETF currently likes the registry entry.)

> 
> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
COMMENT:
>> ----------------------------------------------------------------------
>>

I'll go over these later if that's ok, gotta do another thing
right now;-) Please ping me if you need a response before you
do edits though.

Cheers,
S.


>>
>>
>>
>> 
- 1.4: the 2nd last paragraph is unclear to me. Probably just needs
re-phrasing.
> 
> Which is unclear, the problem or the action?
> 
>> 
>> - 1.5: I'd add a reference to RFC5116.
> 
> Reasonable and done.
> 
>> 
>> - 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.)
> 
> I agree that this is an API requirement.
> 
>> 
>> - 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.
> 
> Given that this is the second person suggesting this (also in Gen-Art
> review). I am going to add a colon to deal with this.
> 
>> 
>> - 3.1, "all the keys may need to be checked" - really?  Or do you
>> mean all the keys associated with this kid?
> 
> I thought that this said keys associated with the kid.  Did you not
> read it this way?  If not then I will look at re-phrasing.
> 
>> 
>> - 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.)
> 
> I was originally going to make IV an algorithm specific parameter
> rather than a common parameter.  It was just so common that it seemed
> to be better to only define it once.  Any algorithm that needed
> different behavior could easily define an algorithm specific
> parameter for IV work instead.  So as you say an easy work around
> exists if needed.
> 
>> 
>> - 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?
> 
> There was a signingTime parameter in the original document.  The WG
> decided that it was not going to be needed enough at this point in
> time to have it defined now.  Additionally, there were some arguments
> over the format of the time field as some systems support a real
> clock and some only support a relative clock to when they were last
> started up.
> 
>> 
>> - 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.
> 
> I would say that this is not real, but I looked carefully at this
> when doing the EdDSA algorithms.  I will look at this and see if I
> cannot find some way to state this either generally or specifically.
> 
>> 
>> - 4.3: "cannot bleed" isn't clear enough maybe, give an example
>> perhaps where the decoder can fail to disambiguate a boundary?
> 
> I'll look at this and see if I cannot come up with better language.
> However, there are no decode issues here.
> 
>> 
>> 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/
> 
> What if it is s/one must also/the application must also/
> 
>> 
>> (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.
> 
> The "and incrementing" to me was implied in the first paragraph with
> the fact that this is intended to be used with the "partial IV"
> parameter.  I'll see if I can make this cleaner.
> 
>> 
>> - 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?)
> 
> Yeah, reads messy - let me think about it.
> 
>> 
>> - 8.2.1: you need a reference for batch signing. (Or could it be
>> omitted?)
> 
> I kept asking for one in the EdDSA document and never got one there,
> so I don't have one to push in here.
> 
>> 
>> - 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:-)
> 
> When I was doing research about this, I could not find any solid
> results on truncated MAC values that people seemed to agree on. Most
> people seem to look at this as just a birthday attack so I would need
> to do more searching to find something useful.
> 
>> 
>> - 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.)
> 
> Will do.
> 
>> 
>> [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.
> 
> I copied "OKP" from draft-ietf-jose-cfrg-curves.  Since it has
> already gone through there I am reluctant to be different.
> 
> I will re-look at the order and make sure that there is something
> lying around for the acronym expansion.
> 
>> 
>> - 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)
> 
> Yes that is the formula and yes it makes sense to document it in that
> manner.
> 
>> 
>> - 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.)
> 
> I am lost and don't understand what you are saying here.
> 
> * For EC2 key types the curve is fixed, but the cryptographic
> function is not fixed. * For OKP key types, the curve/cryptographic
> function pair is fixed.
> 
> This is analogous to what is happing for the PKIX world.
> 
> Are you suggesting that something change?  If so what?  (Just so I
> can evaluate it.)
> 
>> 
>> - 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).
> 
> Will add a reference to draft-selander-ace-object-security.  (Which
> is being discussed in core not ace).
> 
>> 
>> - 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.)
> 
> Yes, the cfrg curves should be normative and yes I will go back over
> the list.
> 
>> 
>> - 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>?
> 
> Answer above.
> 
> 
> Jim
> 
> 
>> 
>> - 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 mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/cose
>