Please see my review of the PR, Ludwig. -----Original Message----- From: Ludwig Seitz <[email protected]> Sent: Sunday, August 25, 2019 11:40 PM To: Benjamin Kaduk <[email protected]> Cc: [email protected]; [email protected] Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06
Hi Ben, fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 (waiting for Mike to double-check and merge them). As for those that are still open, comments are inline. /Ludwig On 13/08/2019 01:15, Benjamin Kaduk wrote: >>> The "COSE_Key" member MAY also be used for a COSE_Key representing a >>> symmetric key, provided that the CWT is encrypted so that the key is >>> not revealed to unintended parties. The means of encrypting a CWT is >>> explained in [RFC8392]. If the CWT is not encrypted, the symmetric >>> key MUST be encrypted as described in Section 3.3. >>> >>> It's hard for me to escape the conclusion that this paragraph needs to >>> be a dedicated section with a bit more discussion about how exactly this >>> usage is performed and encoded. >>> >> >> This mirrors the corresponding procedure in RFC 7800. Would it be OK to >> just refer to that document >> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? > > (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in > the opposite order.) > Well, I still wouldn't like it. But I don't think I have grounds to block > the document from advancing if you just refer back to JWT. > Göran and I have discussed this, and we agree that it is indeed underspecified (e.g. which key is used to encrypt this "inner" COSE_Encrypt0 contained in the cnf element?). Additionally I can personally confirm that this is a headache to implement (and I haven't even touched a constrained implementation). We see two alternatives here: 1.) Remove the possibility to have a separate encrypted cnf element. Instead mandate that the whole CWT should be encrypted if it contains a secret key. + make spec easier (to implement) and doesn't requires a long specification on how to handle this case - breaks direct equivalence with RFC 7800 2.) Add some dedicated section that explains how the key for this inner encrypted cnf element is selected and communicated to the RS. + The draft remains functionally equivalent to RFC 7800 - Increased draft complexity at questionable gain - Possible implementer headaches, especially on constrained devices There is an issue about this here: https://github.com/cwt-cnf/i-d/issues/19 >>> The following example CWT Claims Set of a CWT (using CBOR diagnostic >>> notation, with linebreaks for readability) illustrates the use of an >>> encrypted symmetric key as the "Encrypted_COSE_Key" member value: >>> >>> { >>> /iss/ 1 : "coaps://server.example.com", >>> /sub/ 2 : "24400320", >>> /aud/ 3: "s6BhdRkqt3", >>> /exp/ 4 : 1311281970, >>> /iat/ 5 : 1311280970, >>> /cnf/ 8 : { >>> /COSE_Encrypt0/ 2 : [ >>> >>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? >>> >>> [I did not validate the COSE_Encrypt0 output] >>> >> >> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key >> is not. We'd have to define it or write an explanatory comment. > > Maybe I'm confused about how the diagnostic notation works, but the > top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches > iss/sub/aud/etc. in the preceding notation. If the rules are different for > map keys whose corresponding values are themselves structured data types, > then I should just unconfuse myself and we can move on with things... > > Issue created here https://github.com/cwt-cnf/i-d/issues/20 Will fix. >> >>> o A recipient can decide not to use a CWT based on a created Key ID >>> if it does not fit the recipient's requirements. >>> >>> I'm not sure I understand the semantics being described here. Are we >>> saying that the issuer might give a presenter a CWT, and by the time the >>> presenter presents the CWT to the recipient, the recipient says "this is >>> no good" and denies the transaction in question, forcing the presenter >>> to go back to the issuer and try again? (How do we know that the issuer >>> would make any different choices the second time around?) >> >> This risk always exists. In a constrained device world, the recipient >> may already have cleared out the key referenced by the key ID, which >> would force it to reject a CWT using this as proof-of-possession. >> >> I'm not sure how to give good guidance in this case. The error message >> delivered by the recipient rejecting the CWT might be helpful I suppose. >> Do you think this merits some text? > > It's not entirely clear to me that we need to add more text here, but if we > did, it would focus on what "decide not to use" means at a protocol level, > and perhaps how the CWT might not "fit the recipient's requirements" (e.g., > the key id having fallen out of cache as you describe). Issue created here: https://github.com/cwt-cnf/i-d/issues/21 Will fix. >> >>> from changing any elements conveyed within the CWT payload. Special >>> care has to be applied when carrying symmetric keys inside the CWT >>> since those not only require integrity protection but also >>> confidentiality protection. >>> >>> Do we want to reiterate the common mechanisms for providing >>> confidentiality protection here, or just leave the existing text earlier >>> in the document to cover it? >>> >> Doesn't it say a few sentences before: "it is >> necessary to apply data origin authentication and integrity >> protection (via a keyed message digest or a digital signature)." ? >> >> I would consider this to be enough. > > That doesn't cover the *confidentiality* protection, specifically. (So it > seems the answer to my original question is still unclear, at least to me.) > Issue created here: https://github.com/cwt-cnf/i-d/issues/22 Will fix. > >>> Section 6 >>> >>> ensure correct processing. The recipient needs to be able to use >>> credentials to verify the authenticity, integrity, and potentially >>> the confidentiality of the CWT and its content. This requires the >>> >>> Just from a rhetorical point of view, can you help me understand how >>> credentials would be used to verify the confidentiality of a CWT? It >>> seems like this depends on either (or both of) how the CWT is >>> transmitted or how it is prepared, and I am not sure how the recipient's >>> credentials come into play. >>> >> >> This text is referring to the issuer's credentials (e.g. the >> Authorization Server issuing the CWT), that the recipient needs to >> verify the CWT. Do you want us to clarify this sentence? > > Note that I was specifically asking about "potentially the > confidentiality"; I don't understand the intended workflow for verification > of confidentiality (and thus which credentials are involved). I don't > really see how a credential held solely by the issuer could proide > confidentiality protection when it needs to be understood by some other > protocol participant. Issue created here: https://github.com/cwt-cnf/i-d/issues/23 Will fix. >>> Section 7 >>> >>> Criteria that should be applied by the Designated Experts include >>> determining whether the proposed registration duplicates existing >>> functionality, determining whether it is likely to be of general >>> applicability or whether it is useful only for a single application, >>> and evaluating the security properties of the item being registered >>> and whether the registration makes sense. >>> >>> I know we've been using (variations of) this text for a while, but it >>> seems to me that it could be more clear than it currently is -- is >>> duplication of functionality grounds for denial of registration? What >>> about general vs. specific applicability? The latter seems more clearly >>> applicable for determining which range from which to allocate, since >>> that has impact on the encoding size. Can the experts insist on updates >>> to the security considerations text of a specification prior to granting >>> approval, or are they limited to denying registration of values with >>> poor security properties or insufficient documentation thereof? >>> >> >> I'm too unfamiliar with the designated expert system to provide a good >> answer on this one. Can one of my co-authors chip in here? >> Issue created here: https://github.com/cwt-cnf/i-d/issues/25 Will fix. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
