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" <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
