Re: [T2TRG] [core] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?)

[Göran Selander <[e-mail]>]

From: Michael Richardson <[e-mail]>

Carsten Bormann <[e-mail]> wrote:
    > I assume most people are mostly in holiday mode already.

a bit.

    > I have put up 9 potential meeting slots this week:
    > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7e45b11ea3df9a0f&q=1&e=d35fe755-7487-44c5-97d7-2f7f0d483c98&u=https%3A%2F%2Fdoodle.com%2Fpoll%2F7e76k335hd6d28k3

I have mutable plans Tuesday, but I could be persuaded to change them.

    > This week’s meeting is mostly for planning and, first and foremost,
    > discussing the scope we want to communicate.
    > The actual first meeting of a seccore activity would probably then be
    > in 2022W2, but that is one of the things we want to discuss this week.

Understood.

    >> CoAP can be used in various settings beyond simple REST. How do we
    >>adapt existing security requirements and solutions to these new modes of
    >>operation? Some work of this kind is already in progress in the IETF but
    >>some issues go beyond the individual IETF WGs, or could benefit from
    >>additional contributions from a wider audience, reviews and information
    >>sharing.
    >> Examples include:
    >> - Rekeying with PFS vs. stateless operations [2]
    >> - Firmware updates using group communication
    >> - Efficient and secure tunnelling of CoAP in CoAP
    >> - Notifications surviving rekeying
    >> - Progressing pub-sub with CoAP

I guess this is really CoAP focused around OSCORE :-)
I'm not saying this is a problem, but it certainly explains "seccore" as a name.
[GS] The scope is for discussion but the proposal is security in settings making use of CoAP, and to start with the problem rather than specific solutions. "seccore" is some sort of abbreviation of "security in constrained RESTful environments".

If we produced a few roadmaps (or a less interestingly, a roadmap with a few
options), which explained some specific choices, I think that would be
useful.
I think that two or three Informational RFCs would be appropriate.
I prefer multiple RFCs rather than one RFC with three sections in order to
make procurement clearer.
[GS] Maybe someone else thought about roadmaps, I was more thinking about concrete problem statements. If the outcome is a T2TRG draft or a new IETF WG draft (or neither) may depend on the problem.
Göran