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

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Dec 2021 10:40:18 +0100

I assume most people are mostly in holiday mode already.
We did want to have a chat this year about setting up a T2TRG activity around research issues in securing IoT (tentatively called “seccore”), similar to WISHI, but probably with a different core group of people attending.
Some background for that in Göran's mail cited below.

I have put up 9 potential meeting slots this week:
https://doodle.com/poll/7e76k335hd6d28k3

If you are interested, please choose slots you can still make.
I plan to close this COB US today, so please click quickly.

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.

That link was https://doodle.com/poll/7e76k335hd6d28k3 ...

Grüße, Carsten

> On 2021-11-29, at 17:15, Göran Selander <[email-masked]> wrote:
> 
> Dear T2TRG,
>  
> As reported from the CoRE applications side meeting below, there seems to be an interest in progressing topics in the area of security for constrained RESTful environments, and a proposal to host that work in T2TRG.
>  
> * What?
>  
> 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
>  
>  
>  
> * Why?
>  
> To progress applications of CoAP in different security settings which "touch standardization in the IETF" [1] but are not necessarily in scope of a single working group like CoRE, ACE, SUIT, COSE, LAKE, etc.
>  
>  
> * How?
>  
> Through a "sister" of WISHI:  A recurring meeting series under the T2TRG umbrella about topics on security for constrained RESTful environments. Working name: seccore (which apparently may mean "dryness" in some Italian context; not intended as a characterization of the content :-)  Frequency and topics open for discussion.
>  
>  
> * Comments?
>  
> What do people think?
>  
> Should we try to have a first meeting before the upcoming holiday season?
>  
>  
> Göran
>  
> [1] Thing-to-Thing (t2trg) - (ietf.org)
> [2] [core] KUDOS, PFS and operations considerations (ietf.org)
>  
>  
>  
> From: core <[email-masked]> on behalf of Christian Amsüss <[email-masked]>
> Date: Tuesday, 16 November 2021 at 15:57
> To: [email-masked] <[email-masked]>
> Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)?
> 
> Hello,
> 
> On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Amsüss wrote:
> > based on the feedback that arrived, a small group will meet tomorrow
> > (Thursday) 10:00 UTC in the hackathon area to look through some
> > applications (pubsub, problem-details), possibly doing examples or check
> > out how things align with current CoRAL.
> 
> the small group was not all that small and very lively -- thanks
> everyone for participating!
> 
> I've attached the minutes here in case the pad we used[1] goes away.
> 
> While we figure out how to best make more of the CoRE ecosystem publicly
> visible at coap.technology, we can already start collecting material at
> the wiki[2].
> 
> Best regards
> Christian
> 
> [1]: https://notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA?view
> [2]: https://protect2.fireeye.com/v1/url?k=f4bbca08-ab20f04d-f4bb8a93-867b36d1634c-1b783ca428431080&q=1&e=a3621d21-f226-4875-acd7-faaf5c694f88&u=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fwiki%2Fwiki
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Dec 2021 09:54:27 -0500

> I assume most people are mostly in holiday mode already.

a bit.

    > https://doodle.com/poll/7e76k335hd6d28k3

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:

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.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Göran Selander <[email-masked]>
Date: Mon, 20 Dec 2021 15:53:58 +0000

From: Michael Richardson <[email-masked]>

a bit.

    > 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

Understood.

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

[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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Dec 2021 12:22:50 -0500

Göran Selander <[email-masked]> wrote:
    GS> Maybe someone else thought about roadmaps, I was more thinking about
    GS> concrete problem statements. If the outcome is a T2TRG draft or a new
    GS> IETF WG draft (or neither) may depend on the problem.

I think of a document that says:

When you have condition1,condition2,condition3,
then a solution like: RFCXXXX suite 1, with RFCYYYY section 4, and use of
RFCZZZZ ... would make sense.

So, I think that the first part of the document is definitely a problem
statement, or perhaps more correctly called an applicability statement.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Dec 2021 18:46:07 +0100

On 2021-12-20, at 18:22, Michael Richardson <[email-masked]> wrote:
> applicability statement.

That word is taken (Section 3.2 of RFC 2026), so please don’t use it unless you actually do mean this (rather unsuccessful) form of specification.

https://datatracker.ietf.org/doc/html/rfc2026#section-3.2

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Dec 2021 12:58:17 -0500

> That word is taken (Section 3.2 of RFC 2026), so please don’t use it
    > unless you actually do mean this (rather unsuccessful) form of
    > specification.

    > https://datatracker.ietf.org/doc/html/rfc2026#section-3.2

I think that I really do mean this word in exactly the context given.
I agree that they have often been unused or ill-applied, but also often do
work.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Dec 2021 19:01:34 +0100

> On 2021-12-20, at 18:58, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

As an informational document, sure.  In the RFC 2026 sense, hmm.

Note that the activity discussed in this thread is really trying to organize an activity of the T2TRG, and RGs don’t do standards, so any RFC 2026 ASs would need to be done elsewhere.  But research identifying good (and not so good) combinations does make a lot of sense here.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Dec 2021 11:26:16 +0100

> https://doodle.com/poll/7e76k335hd6d28k3

The doodle was in favor of 1600Z today (1100 EST, 1700 CET, 1800 EET).

Webex info:

Meeting link:
https://ietf.webex.com/ietf/j.php?MTID=md00b3797e6b5d123cd2689f53b076f11 
Meeting number:
2428 335 7567
Password: 
constrained

I hope to have an agenda prepared in a few hours.
As I said, this is going to be an informal chat in preparation of the real work.
Talk to you then!

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Dec 2021 16:24:09 +0100

Some initial slides at

http://tzi.de/~cabo/t2trg-chat-2021-12-21.pdf

We will collect notes at

https://notes.ietf.org/notes-t2trg-chat-2021-12-21

See you in 35 minutes…

Grüße, Carsten

> On 2021-12-21, at 11:26, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Dec 2021 18:17:30 +0100

So we had the first hour of discussion, and it was interesting to see how many areas of potential work we could actually make out beyond what I had prepared.  See notes referenced below.

We decided we would spend some time individually, grouping the activities listed (and our favorite additions) into

— short term (do now)
— mid term (examine and turn into one or more short-term items during year 2022)
— long term (same, but really with a longer outlook and some “freezer” semantics for now).

So we’ll try to have a few short emails (“documents”) out with this by Monday, 2022-01-10, and meet again 2022-01-11 at 1600Z again to merge and make this more concrete.

An actual work meeting, with prepared discussion points (“presentations”, but really mostly for discussion), would then be next.

Grüße, Carsten

> On 2021-12-21, at 16:24, Carsten Bormann <[email-masked]> wrote:
> 
> Some initial slides at
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Rene Struik <[email-masked]>
Date: Thu, 23 Dec 2021 11:42:18 -0500

[resending prior offline communication, but now to the list]

Hi Carsten:

I dialed-into this chat (but had to log-off, due to schedule conflict 
11.30am EST).

During the call, you mentioned that EAP-NOOB seems un-implementable (or, 
one of your students thought so). If you could articulate what is good 
and what is bad (in terms of feature set, user experience, etc.), that 
would be good to know, as would be whether you think this can be 
remedied or whether one can improve the protocol with a minor tweak. In 
other words, what is missing and what would you ideally like to see here?

Best regards, Rene

On 2021-12-21 10:24 a.m., Carsten Bormann wrote:
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Dec 2021 18:38:34 +0100

Hi Rene,

> During the call, you mentioned that EAP-NOOB seems un-implementable (or, one of your students thought so). If you could articulate what is good and what is bad (in terms of feature set, user experience, etc.), that would be good to know, as would be whether you think this can be remedied or whether one can improve the protocol with a minor tweak.

I haven’t really looked at the protocol, only briefly at the implementability of the signing inputs after a student alerted me to issues he had.

Re the protocol, I’ve heard rumors that a simpler protocol could be invented that solves the same set of problems, but I know nothing about that.

Re the implementability: I sent some notes to Mohit; I’m sure the student will also write up something but it is a quiet time here in Germany right now.

I think that the RG would benefit from an analysis of NOOB, both with respect to technical details such as signing inputs, and with respect to players, trust relationships, outcomes, etc., and how the protocol addresses these.

Grüße, Carsten

---

From: Rene Struik <[email-masked]>
Date: Thu, 23 Dec 2021 13:38:04 -0500

Hi Carsten:

Thanks. If there is a brief problem statement on what problem is solved, 
both stated and in real life, I am happy to reflect on this: I have done 
quite a bit of protocol analysis, including fixes, but this starts with 
a clear description about what one wishes to achieve (at least, on the 
crypto level with existing protocol soup distractions removed for the 
moment). A good use of yet another cooped-up time window or simply next 
to the Christmas tree. {if not completely clear/complete yet, please let 
me know offline -- I can fill in part of the blanks if not that many}.

Best regards, Rene

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 27 Dec 2021 12:08:34 -0600

On Thu, Dec 23, 2021 at 11:39 AM Carsten Bormann <[email-masked]> wrote:

> one of your students thought so). If you could articulate what is good and
> what is bad (in terms of feature set, user experience, etc.), that would be
> good to know, as would be whether you think this can be remedied or whether
> one can improve the protocol with a minor tweak.
>
> I haven’t really looked at the protocol, only briefly at the
> implementability of the signing inputs after a student alerted me to issues
> he had.
>
> Re the protocol, I’ve heard rumors that a simpler protocol could be
> invented that solves the same set of problems, but I know nothing about
> that.
>
>

> Re the implementability: I sent some notes to Mohit; I’m sure the student
> will also write up something but it is a quiet time here in Germany right
> now.
>
>
Which part is the problem? EAP part with 802.15.4 interface or NOOB
out-of-band channel with blinking LED, its encoding on an Android
smartphone?
I  think in the implementation as reported they have used specific software
like Contiki-NG, hardware like Zolertia Firefly motes and the board and if
you don't use them or have a different version, etc. the assumptions may
not hold true.

I think that the RG would benefit from an analysis of NOOB, both with
> respect to technical details such as signing inputs, and with respect to
> players, trust relationships, outcomes, etc., and how the protocol
> addresses these.
>
>
+1

Behcet