Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat <[e-mail]>]

On 10/26/20 4:21 PM, Benjamin Kaduk wrote:
> 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).

Ben, having raised the point, and knowing that you understood it, I am 
satisfied with whatever changes you do or don't decide to make to 
address it.

	Thanks,
	Paul

> 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" <[e-mail]> wrote:
>>
>>      Hi Paul,
>>
>>      On 2020-09-17, 17:26, "Paul Kyzivat" <[e-mail]> 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 <[e-mail]> 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
>>
>>
>>
>>