Subject: [core] Updated CoAP option template and OSCORE handling

From: Christian Amsüss <[email-masked]>
Date: Wed, 9 Dec 2020 15:28:23 +0100

Hello CoRE,

it is custom so far with all RFCs that introduce CoAP options to
summarize their options in a table like 

 +--------+---+---+---+---+-----------+--------+--------+---------+
 | Number | C | U | N | R | Name      | Format | Length | Default |
 +========+===+===+===+===+===========+========+========+=========+
 | 16     |   |   |   |   | Hop-Limit | uint   | 1      | 16      |
 +--------+---+---+---+---+-----------+--------+--------+---------+

With OSCORE, its [table 5] introduces two more columns that, when
plainly added, but their naming conflicts on "U" as noted in the Genart
review[1].

As "how is this handled with object security" is a good thing to have at
hand, I propose 

 +--------+---+---+---+---+-----------+--------+--------+---------+---+
 | Number | C | U | N | R | Name      | Format | Length | Default | O |
 +========+===+===+===+===+===========+========+========+=========+===+
 | 16     |   |   |   |   | Hop-Limit | uint   | 1      | 16      | U |
 +--------+---+---+---+---+-----------+--------+--------+---------+---+

annotated as "O: OSCORE classification (U: unprotected)", and intend to
use this with echo-request-tag (ERT).

The practical alternative is to leave that information out of the table,
and only have it present textually; I think that would make it harder
for an implementer to grasp at one look how the option is supposed to
behave.

KR
Christian

PS. Yeah I know this is not something that needs WG-wide agreement on or
  would be binding for anyone registering an option, but still we can
  contribute to a consistent ecosystem here.

[table 5]: https://tools.ietf.org/html/rfc8613#page-17
[1]: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-11-genart-lc-robles-2020-12-02/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 09:09:11 +0000

Hi Christian, 

As we need to capture both E ad U for OSCORE and the need for consistent use of "x" to tag a given characteristic, another approach would be:

+--------+---+---+---+---+-----------+--------+--------+---------+---+
| Number | C | U | N | R | Name      | Format | Length | Default | O |
|        |   |   |   |   |           |        |        |         +-+-+
|        |   |   |   |   |           |        |        |         |E|U|
+========+===+===+===+===+===========+========+========+=========+===+
| 16     |   |   |   |   | Hop-Limit | uint   | 1      | 16      | |x|
+--------+---+---+---+---+-----------+--------+--------+---------+---+

But given the conflict with the already used "Unsafe" column, I tend to prefer not overloading the existing table, but have a dedicated table that mimics Figure 5 of RFC8613: 

                   +------+-----------------+---+---+
                   | No.  | Name            | E | U |
                   +------+-----------------+---+---+
                   |  16  | Hop-Limit       |   | x |
                   +------+-----------------+---+---+

If this approach is followed, we will update the new-block draft to include this NEW table:

                   +------+-----------------+---+---+
                   | No.  | Name            | E | U |
                   +------+-----------------+---+---+
                   | TBA1 | Q-Block1        | x | x |
                   | TBA2 | Q-Block2        | x | x |
                   +------+-----------------+---+---+
          Table 2: Protection of Q-Block1 and Q-Block2 Options

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Christian
> Amsüss
> Envoyé : mercredi 9 décembre 2020 15:28
> À : Core WG mailing list <[email-masked]>
> Objet : [core] Updated CoAP option template and OSCORE handling
> 
> Hello CoRE,
> 
> plainly added, but their naming conflicts on "U" as noted in the
> Genart review[1].
> 
> As "how is this handled with object security" is a good thing to
> have at hand, I propose
> 
> O |
> U |
> annotated as "O: OSCORE classification (U: unprotected)", and intend
> to use this with echo-request-tag (ERT).
> 
> The practical alternative is to leave that information out of the
> table, and only have it present textually; I think that would make
> it harder for an implementer to grasp at one look how the option is
> supposed to behave.
> 
> 
> KR
> Christian
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 13:31:20 -0000

Hi Christian,

Med's suggestion looks good to me - especially as there is potential for
lines being too long in the existing table if that was extended.

Regards

Jon

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 10 December 2020 09:09
> To: Christian Amsüss; Core WG mailing list
> Subject: Re: [core] Updated CoAP option template and OSCORE handling
> 
> Hi Christian,
> 
> As we need to capture both E ad U for OSCORE and the need for consistent
use
> of "x" to tag a given characteristic, another approach would be:
> 
> But given the conflict with the already used "Unsafe" column, I tend to
prefer
> not overloading the existing table, but have a dedicated table that mimics
Figure
> 5 of RFC8613:
> If this approach is followed, we will update the new-block draft to
include this
> NEW table:
> +========+===+===+===+===+===========+========+========+=========
> +==
> > =+
> _________________________________________________________________
> ________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> If you have received this email in error, please notify the sender and
delete this
> message and its attachments.
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core