Hi Göran, Paul, Olaf, Sorry for the slow reply.
I agree with Göran's original assessment that the language referring to 7049bis does provide enough information to have a deterministic encoding for the HKDF inputs. As such, I don't think pull #28 is needed, and would prefer that it was reverted (the specific wording doesn't do a great job indicating that the whole list of requirements is "normative", to the extent that any example can be normative). Thanks, Ben On Thu, Oct 15, 2020 at 05:24:37PM +0000, Göran Selander wrote: > Hi Paul, > > Returning to the final remaining comment in your review. I made a pull > request to clarify the change I proposed at the end of the mail below (to > which I didn't find a response but I may have missed it): > > https://github.com/ace-wg/ace-dtls-profile/pull/28 > > Does this address your concern? > > Thanks, > Göran > > > On 2020-09-25, 17:07, "Göran Selander" <goran.selan...@ericsson.com> wrote: > > Hi Paul, > > On 2020-09-17, 17:26, "Paul Kyzivat" <pkyzi...@alum.mit.edu> wrote: > > Hi Olaf, > > On 9/17/20 4:09 AM, Olaf Bergmann wrote: > > Hi Paul, > > > > Responding to you remaining comments please see inline. > > > > Paul Kyzivat <pkyzi...@alum.mit.edu> writes: > > > >>>>> * Also in section 3.3: > >>>>> > >>>>> All CBOR data types are encoded in CBOR using preferred > serialization > >>>>> and deterministic encoding as specified in Section 4 of > >>>>> [I-D.ietf-cbor-7049bis]. This implies in particular that > the "type" > >>>>> and "L" components use the minimum length encoding. The > content of > >>>>> the "access_token" field is treated as opaque data for the > purpose of > >>>>> key derivation. > >>>>> > >>>>> IIUC the type of serialization and encoding is a requirement. > Will > >>>>> need some rewording to make it so. > >>>> > >>>> I take it that you and Ben have agreed that the example > description does > >>>> not necessarily need normative language as the description of > this key > >>>> derivation procedure is meant as an example how the > authorization server > >>>> and the resource server can securely agree on a shared secret to > be used > >>>> between the client and the resource server. > >> > >> This still confuses me. IIUC preferred serialization and > deterministic > >> encoding are *optional* in CBOR. The text hear seems to require it, > >> but doesn't use normative language to do so. > >> > >> If these are required for things to work then you make a normative > >> statement about it. E.g., "The "type" and "L" components MUST use > the > >> minimum length encoding." > >> > >> Or do you intend that some other (non-minimum-length) MAY be used? > (In > >> which case both sides would need a side agreement on what encoding > is > >> used.) > > > > The text here just gives an example how key derivation may be used > by > > the authorization server and the resource server to agree on a > shared > > secret (that is used to encrypt the traffic between the resource > server > > and the to-be-authorized client). > > > > To that regard, the text is not really normative. The only normative > > language we need here would be to avoid security issues. Commenting > on > > the data representation here is to be understood as a suggestion to > use, > > e.g., preferred CBOR serialization according to 7049bis. > > > > [...] > > Sorry to be so dense, but I'm still not getting it. > > I take your point that this is only an example of a way to agree on a > shared secret. But at the end of the day they indeed must somehow > agree > on a shared secret. *If* they use this technique then it will only > work > if they also agree on a consistent way to do the serialization and > encoding that is otherwise not standardized. So they need a side > agreement, which is not a good situation for a standardized protocol. > > At the very least it seems like you should highlight that some sort > of > out of band communication is required between the authorization and > resource servers to establish the shared secret or the algorithm to > be > used for deriving the shared secret. > > [GS] > I'm not sure I understand the issue correctly. > > Section 4.1 of ietf-cbor-7049bis states: > 'The preferred serialization always uses the shortest form of > representing the argument' > > This seems to me to be in coherence with: > "All CBOR data types are encoded in CBOR using preferred serialization > and deterministic encoding" > and > 'This implies in particular that the "type" and "L" components use the > minimum length encoding. ' > > If I understand right you would like to replace the latter sentence with: > 'The "type" and "L" components MUST use the minimum length encoding.' > > But there are multiple statements in this example which could be replaced > with normative language, e.g.,: > > 'In this example, HKDF consists of the composition of the HKDF-Extract > and HKDF-Expand steps [RFC5869].' > > 'The symmetric key is derived from the key identifier, the key derivation > key and other data:' > > 'type is set to the constant text string "ACE-CoAP-DTLS-key-derivation" ' > > > Would you be happy with only the specific normative statement you > proposed (which BTW is fine to me) or would you like to see all statements > like this to be replaced with normative text (or can we make a normative > formulation at the beginning of the example indicating that "compliance to > this example REQUIRES the following:")? > > Thanks, > Göran > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
