Re: [Ace] DTLS profile - Open points

[Olaf Bergmann <[e-mail]>]

Hi Göran, Marco,

(Adding the COSE mailing list for potential comments.)

please see inline for my thoughts on this.

On 2021-05-21, Göran Selander <[e-mail]> wrote:

> Hello co-authors,
>
> (cc: Marco and ACE co-chairs)
>
> Returning to the subject in our recent mail thread I asked Marco to
> summarize what he thinks remain to be addressed, see below. I think
> these are valid points that each merit at least a note in the
> specification. Do you agree?
>
> Should we ask Marco to repeat this on the ACE mailing list or is it
> enough that we resolve them for the next version of the draft?
>
> Thanks
> Göran
>
>
> On 2021-05-20, 17:48, "Marco Tiloca" <[e-mail]> wrote:
>
>     Please find below a summary of the four open points.
>
>     All of them refer to Section 3.3.2 "DTLS Channel Setup Between Client 
>     and Resource Server", and specifically to the paragraph before
> and the
>     paragraph after Figure 9.
>
>     The original mail thread has subject "Conversion of access token to 
>     psk_identity".
>
>     Best,
>     /Marco
>
>
>     a) Clarify that the elements of the structure in Figure 9 of Section 
>     3.3.2 have to follow that exact order. This ensures that the
> result and
>     its following encoding are deterministic. This can't be taken for 
>     granted from a CBOR implementation building a CBOR map.

I do not see why we would need to mandate this order. Although this
could help with optimized parsers, it violates Postel's theorem and
therefore should be avoided IMO.

(That we indeed might have to say in the document is whether duplicate
keys are allowed. As we are just using data represenations from other
sources such as COSE and the CBOR-OAuth mappings, I would expect these
specs to define the restrictions on the deterministic CBOR; I did not
check that, though.)

>     b) In Section 3.3.2, refer to RFC 7925 not only for the case where 
>     psk_identity is the token (see the paragraph following Figure 9), but 
>     also for the case when psk_identity is the structure in Figure 9
> of the
>     DTLS profile (see the paragraph before Figure 9).

No, the uploading case is different because the client itself constructs
the cnf structure shown in Figure 9.

>
>     c) In Section 3.3.2, the text before Figure 9 says: "This
> structure then
>     is included as the only element in the "cnf" structure that is
> used as
>     value for "psk_identity" as shown in Figure 9."
>
>         I think it should be clarified what "is used" actually
> means. This
>     can be either:

Commit be8ac2c now clarifies that the serialized CBOR structure is put
into the psk_identity (option i).

>         i) using the binary serialization of the structure "as is"
> with no
>     re-coding, just like for the case when psk_identity is the token (see 
>     the paragraph after Figure 9); or
>
>         ii) saying that the specific way of "using" it for
> psk_identity is
>     up to the C and RS to pre-agree somehow, while still giving a 
>     recommendation like the one above; or
>
>         iii) see next item (d), trying to address implementations without 
>     "full support" for binary psk_identity.
>
>     d) Regarding psk_identity, RFC 7925 has the intent to *not require* a 
>     UTF-8 character string, which remains in general possible to use as 
>     valid opaque byte string. The ultimate goal is to tell to TLS 
>     implementations "don't try to parse" that string, since it may not be 
>     UTF-8 compliant.

Yes.

>     So, character strings are not *required* but they may 
>     still *be used*.

I am not sure what this sentence means. Is this about sequences of
multibyte characters such as UCS-2?

>     If so, they just have to be treated as opaque bytes 
>     anyway by DTLS.
>
>         As in point (c) above, the profile currently says that: if 
>     psk_identity is the token, its binary serialization is used; if 
>     psk_identity is not the token, the "cnf" structure of Figure 9 "is 
>     used", without further details.
>
>         It seems that implementations (e.g., Californium) don't fully 
>     support non-UTF-8 psk_identity values all the way up to an application 
>     needing to retrieve it, like in the case of an ACE RS.
>
>         In Californium, DTLS itself works with a non UTF-8 psk_identity 
>     (through a discouraged workaround), but the server eventually stores 
>     that identity to be accessible for the application as a UTF-8 character 
>     string anyway, thus making the original binary identity not available to 
>     the application. This results, in this case, in failed access to 
>     resources. A detailed explanation of this issue in Californium is in the 
>     mail I sent on 2021-05-07, at 12:55 CEST.
>
>         An admittedly arguable change in the profile to address both points 
>     (c) and (d) can be:
>
>            - When the token is used as psk_identity, then psk_identity is 
>     the base64 serialization of the token, which results in a UTF-8 
>     compliant string.
>
>            - When the "cnf" structure is used as psk_identity, then 
>     psk_identity is the base64 serialization of the binary encoding of the 
>     "cnf" structure, which results in a UTF-8 compliant string.
>
>            - The above can be the recommended option, unless otherwise 
>     pre-agreed by the Client and Resource Server.

There has been a longer discussion about this (including my note that
you could use UTF-8 for serialization to possibly save some bytes
compared to the more expensive base64.)

However: The major question is if we take this as an opportunity to fix
the non-compliant Cf rather than specifying an IoT-protocol that wastes
bytes on the wire although there is a clear recommendation in RFC 7925
that psk_identity is not be parsed as UTF-8?

Grüße
Olaf