Type of connection identifiers

[gselander]

Proxying question from Stefan:

Is there a strong reason to define the encoding as bstr/int. Is it not enough to have just int? From my perspective to allow one of both bstr or int depending on the user makes not only the the implementation more complex but as well the EDHOC API more user unfriendly.

This would reduce the number of identifiers of a given size. Perhaps this could be a constraint in the applicability template / application profile.

[emanjon]

I think the number of identifiers of a given size are as follows

bytes        bstr        int
1               1         48
2             256        464

Only int would likely be acceptable.

[marco-tiloca-sics]

The above holds for the EDHOC identifiers, which are exchanged on the wire only during an EDHOC execution.

Things are different if we think of what that means in terms of OSCORE identifiers, which are supposed to be exchanged on the wire several times later on when using OSCORE.

If we consider:

• The EDHOC==>OSCORE conversion rules from -lake-edhoc at [1]; and

• The OSCORE==>EDHOC conversion rules from -core-oscore-edhoc at [2], to deterministically and optimally select one specific EDHOC identifier among the two equivalent ones for the same OSCORE identifier;

Then we have the following number of available OSCORE identifiers, as shown in the second and third column.

Size N in bytes    When EDHOC ID is a bstr     When EDHOC ID is an int
 of OSCORE ID      on the wire (N+1 bytes)     on the wire (N bytes)
     0                          1                          0
     1                        208                         48
     2                      65072                        464
    ...                       ...                         ...

Thinking of an EDHOC endpoint when offering its own EDHOC identifier C_X as bstr or int, it can be admittedly non-trivial (I would not say difficult) for an implementation to optimally check if it is possible to offer first any available EDHOC identifier that yield an available 1-byte OSCORE identifier, before moving on to considering the next pool of EDHOC identifiers yielding 2-byte OSCORE identifiers.

However, the optimal selection above does not have to necessarily be performed. Regardless, in order to avoid any possible complication and keep the offering of EDHOC identifiers very simple, an EDHOC endpoint may simply choose to offer only numeric identifiers, which is already possible to do today.

At the same time, I think it is good to continue expecting that an EDHOC endpoint is at least able to correctly receive and process a byte-string valued EDHOC identifier when offered by the other peer. This preserves a large number of short OSCORE identifiers that remain possible to select and use later on with OSCORE.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-A.1

[2] https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-02#section-4.1

[gselander]

Now we mention the option for an endpoint to select only integer or only byte string connection identifiers.

@marco-tiloca-sics Did I capture your comment?
@StefanHri Is this good enough? If not, please provide more details of the problem.

[marco-tiloca-sics]

Overall yes, thanks. Two comments on the new added text:

One simplification is to restrict to only use integer or only byte string connection identifiers.

I suggest to replace "use" with "select", also consistently with other just added text as intended to apply to what is offered to the other peer, not used overall.

An endpoint MAY choose to select, for example, only numeric connection identifiers which then are equivalent if and only if the integer value is the same, thus simplifying the comparison.

I can't fully parse this sentence. The word "equivalent" is defined a few paragraphs above as applicable to two equivalent connection identifiers (one bstr and one int) yielding the same OSCORE identifier and hence ambiguous. The word was not intended to be used for two int connection identifiers.

Also, the numbers in the table are the result of applying both the rules in the {{edhoc-to-oscore}} section and the companion rules in draft-ietf-core-oscore-edhoc , which is probably better to mention. That's what ensures that, when selecting an available OSCORE Recipient ID, only one of the two equivalent corresponding connection identifier is deterministically selected.

Perhaps here you mean that, due to the above, there is only a limited number of eligible integer connection identifier for each identifier size (e.g., 48 for 1-byte integer identifiers). Due to the rules in the {{edhoc-to-oscore}} section, those are the identifiers whose CBOR encoding is equal to the corresponding OSCORE ID, which indeed simplifies a comparison.

[gselander]

Updated after discussion with @marco-tiloca-sics: 4f56898

[marco-tiloca-sics]

Looks good to me.