Subject: [Model-t] Meeting to discuss how (and if) to continue

From: Jari Arkko <[email-masked]>
Date: Wed, 3 Nov 2021 14:18:00 +0200

Hi,

We’ve obviously not made much progress. This was discussed in previous IABOPEN session meeting in the summer, the IAB also discussed it subsequently. 

We could discuss why…. and have to some extent. Long story short, my opinion is that has been due to leadership problem (i.e., me) of not organising the group even to have meeting, despite fairly broad set of contributions. Secondly, in hindsight the original decision to focus on RFC 3552 updates may have been a mistake. IAB activities tend to do well on writing about architectural trends, principles to follow, etc, as we’ve seen with for instance RFCs 8546, 8558 or 8890. Thirdly, IAB activities other than one-time workshops are best done as something where there’s a strong drive and participation from IAB member(s), kind of as an extension of IAB helping to complete something, preferably something very specific.

But we could also discuss what to do now, if anything. I personally still believe this is an important topic, perhaps one of the most important ones in the Internet, at least from my perspective. The question is perhaps how. The good things are that we do have plenty of contributions, we have interested people, we’ve also heard offers from volunteers to help with leading efforts, and so on. But what’s the best way to organise activities, and what activities make sense to begin with? And what to focus on?

If we look at the different drafts, they can in my mind be classified into (1) general observations about attacks and trends with them, (2) architectural or security principles, and (3) updates of IETF guidance in RFCs 3552, 7258, etc. All of this is interesting, but have different nature. I think it is difficult for the program to get to a final result for the third category, for instance, simply because we don’t decide that in the end. And maybe the bar for that is too high anyway. The first category is very useful, but is also very dynamic in nature. And it is unclear to me to what extent there’s research in the academic world that would document some of that. Does someone know? I have a feeling that the drafts are more examples than comprehensive surveys, so more work would be needed. 

But perhaps there is some room for focused progress in the second category, documenting principles. For instance, Martin’s draft (draft-thomson-tmi) is an excellent contribution that addresses “intermediaries” and when/if they need to be involved. And what principles can be applied to ensure the involvement of intermediaries is done in reasonable manner. His concept is broader than middle boxes, by the way, covering even things like routers. I think this might be a potential direction for useful work, documenting principles such as those in Martin’s document. FWIW, I’m not suggesting that we must limit ourselves to that specific document — for instance, I think it would be useful to also discuss the role end-to-end services and how sharing of data with them can be done in a reasonable manner :-) But Martin’s document is certainly the one that in my mind is clearest and furthest ahead in this direction.

Anyway, if we were to focus on more actionable architectural advice, then maybe it would be easier to see what we could do together. For instance, perhaps we could re-define model-t to work on 1-2 specific pieces of advice expressed as principles to follow. I’d personally be happy to work on that or help guide a document forward.

But these are just my opinions. What do others think?

Perhaps it would be useful to discuss this on a call, and also to review documents in light of the above. I’d tentative suggest the following time slot for the meeting: Thursday Nov 25th, 22:00 Paris time, for one hour. This is Thursday Nov 25th, 13:00 San Francisco and Friday Nov 26th, 08:00 Melbourne. Would this be a reasonable time, or do people see major conflicts? If I don’t hear loud objections in the next couple of days, I will set up the call and send a calendar invite.

See below for a list of drafts related to the model-t discussions and my slide deck about the model-t situation from the summer IAB discussions.

Jari

——

draft-arkko-arch-internet-threat-model-guidance	
draft-arkko-arch-internet-threat-model	
draft-mcfadden-smart-endpoint-taxonomy-for-cless	
draft-lazanski-smart-users-internet	
draft-arkko-farrell-arch-model-t	
draft-lazanski-users-threat-model-t	
draft-lazanski-protocol-sec-design-model-t	
draft-mcfadden-smart-threat-changes	
draft-thomson-tmi	
draft-arkko-farrell-arch-model-t-7258-additions	
draft-arkko-farrell-arch-model-t-3552-additions	
draft-arkko-farrell-arch-model-t-redux	
draft-arkko-iab-data-minimization-principle

---

From: Ira McDonald <[email-masked]>
Date: Wed, 3 Nov 2021 10:37:40 -0400

Hi Jari,

Thanks for a good summary of the existing contributions to Model-T.  I hope
most all of this work
will be saved and dispatched to an appropriate IETF or IRTF WG.

FWIW - Thursday 25 November is the US Thanksgiving Day holiday - you're not
likely to get many
US attendees.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Wed, Nov 3, 2021 at 8:19 AM Jari Arkko <[email-masked]> wrote:

> Hi,
>
> We’ve obviously not made much progress. This was discussed in previous
> IABOPEN session meeting in the summer, the IAB also discussed it
> subsequently.
>
> We could discuss why…. and have to some extent. Long story short, my
> opinion is that has been due to leadership problem (i.e., me) of not
> organising the group even to have meeting, despite fairly broad set of
> contributions. Secondly, in hindsight the original decision to focus on RFC
> 3552 updates may have been a mistake. IAB activities tend to do well on
> writing about architectural trends, principles to follow, etc, as we’ve
> seen with for instance RFCs 8546, 8558 or 8890. Thirdly, IAB activities
> other than one-time workshops are best done as something where there’s a
> strong drive and participation from IAB member(s), kind of as an extension
> of IAB helping to complete something, preferably something very specific.
>
> But we could also discuss what to do now, if anything. I personally still
> believe this is an important topic, perhaps one of the most important ones
> in the Internet, at least from my perspective. The question is perhaps how.
> The good things are that we do have plenty of contributions, we have
> interested people, we’ve also heard offers from volunteers to help with
> leading efforts, and so on. But what’s the best way to organise activities,
> and what activities make sense to begin with? And what to focus on?
>
> If we look at the different drafts, they can in my mind be classified into
> (1) general observations about attacks and trends with them, (2)
> architectural or security principles, and (3) updates of IETF guidance in
> RFCs 3552, 7258, etc. All of this is interesting, but have different
> nature. I think it is difficult for the program to get to a final result
> for the third category, for instance, simply because we don’t decide that
> in the end. And maybe the bar for that is too high anyway. The first
> category is very useful, but is also very dynamic in nature. And it is
> unclear to me to what extent there’s research in the academic world that
> would document some of that. Does someone know? I have a feeling that the
> drafts are more examples than comprehensive surveys, so more work would be
> needed.
>
> But perhaps there is some room for focused progress in the second
> category, documenting principles. For instance, Martin’s draft
> (draft-thomson-tmi) is an excellent contribution that addresses
> “intermediaries” and when/if they need to be involved. And what principles
> can be applied to ensure the involvement of intermediaries is done in
> reasonable manner. His concept is broader than middle boxes, by the way,
> covering even things like routers. I think this might be a potential
> direction for useful work, documenting principles such as those in Martin’s
> document. FWIW, I’m not suggesting that we must limit ourselves to that
> specific document — for instance, I think it would be useful to also
> discuss the role end-to-end services and how sharing of data with them can
> be done in a reasonable manner :-) But Martin’s document is certainly the
> one that in my mind is clearest and furthest ahead in this direction.
>
> Anyway, if we were to focus on more actionable architectural advice, then
> maybe it would be easier to see what we could do together. For instance,
> perhaps we could re-define model-t to work on 1-2 specific pieces of advice
> expressed as principles to follow. I’d personally be happy to work on that
> or help guide a document forward.
>
> Perhaps it would be useful to discuss this on a call, and also to review
> documents in light of the above. I’d tentative suggest the following time
> slot for the meeting: Thursday Nov 25th, 22:00 Paris time, for one hour.
> This is Thursday Nov 25th, 13:00 San Francisco and Friday Nov 26th, 08:00
> Melbourne. Would this be a reasonable time, or do people see major
> conflicts? If I don’t hear loud objections in the next couple of days, I
> will set up the call and send a calendar invite.
>
> See below for a list of drafts related to the model-t discussions and my
> slide deck about the model-t situation from the summer IAB discussions.
>
> Jari
>
> ——
>
> --
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t
>

---

From: Mallory Knodel <[email-masked]>
Date: Wed, 3 Nov 2021 10:46:16 -0400

Hi Jari and all,

Thanks for starting this conversation. I agree that it's an important 
topic to keep open but that the options on how to proceed aren't clear. 
Maybe a synchronous session would be the best way to figure it out.

I'm available at the day/time you mention but am also open to exploring 
other options if not everyone is keen to hold it on a US holiday,

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Jari Arkko <[email-masked]>
Date: Wed, 3 Nov 2021 17:25:25 +0200

A quick follow-up after being told about the Thanksgiving holidays :-) Apologies for my unawareness of this. I will come up with another suggested date.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Thu, 4 Nov 2021 10:23:58 +0100

I'm interested as well.  I would prefer the discussion to be somewhat 
wide-ranging.  There are a lot of technology improvements that are worth 
examining that are coming down the pike, especially when it comes to 
trusted computing, that perhaps should deserve some of the board's 
attention.  I think this also goes to some of Malory's work with regard 
to e2ee.

What does a security model look like in a world full of TEEs, some of 
which are trusted, others of which are not, some of which are infected 
with malware, others of which are not.  And what precisely is an endpoint?

One thing the board might consider is whether there is enough work to be 
done here to refer the matter to the IRTF to encourage / collate 
research in this area.

While I see no need for us to run fast here, any movement in the 
discussion would be an improvement.

Eliot

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 4 Nov 2021 12:08:58 +0100 (CET)

> Il 03/11/2021 13:18 Jari Arkko <[email-masked]> ha scritto:
> 

I'd be happy to continue the discussion, and I'm starting to think that perhaps we should discussing about threat model*s*, not just about a single one. It is becoming increasingly hard to tell "technical" threats from "societal" threats, and different environments tend to adopt different threat models for the same situation, prioritizing different types of threat. 

For example, centralization is perceived as a bigger threat in parts of the world where it is likely to happen into the hands of non-local entities, while it might be less of a problem elsewhere. Some parties consider in-transport attacks more harmful while others focus more on possible bad endpoint behaviour (and I think you can't really avoid considering endpoint behaviour, or the IETF's threat analysis will just look skewed to people in other circles). Depending on which threats you prioritize, you may get to radically different architectures and technical choices.

So perhaps a strategy could be to consider multiple conflicting threat models since the beginning.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Dominique Lazanski <[email-masked]>
Date: Thu, 4 Nov 2021 11:15:01 +0000

Just to add my bit - I am, of course, interested in a further discussion on model-T. As the author of several documents I think that there is a lot of good work in all of the documents and it is a matter of discussing and focusing the work for the future.

Looking forward to speaking soon!

Dominique

> On 4 Nov 2021, at 11:08, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Nov 2021 11:40:13 +0000

> On 4 Nov 2021, at 09:23, Eliot Lear <[email-masked]> wrote:
> 
> I'm interested as well.  I would prefer the discussion to be somewhat wide-ranging.  There are a lot of technology improvements that are worth examining that are coming down the pike, especially when it comes to trusted computing, that perhaps should deserve some of the board's attention.  I think this also goes to some of Malory's work with regard to e2ee.
> 
> What does a security model look like in a world full of TEEs, some of which are trusted, others of which are not, some of which are infected with malware, others of which are not.  And what precisely is an endpoint?
> 
> One thing the board might consider is whether there is enough work to be done here to refer the matter to the IRTF to encourage / collate research in this area.

Some of this was re-directed from the IRTF, because it’s a conversation the IETF needs to have about what it considers its threat model when designing protocols.

There are obviously architecture and research questions in this space, but there’s a lot of concrete engineering guidance that needs to be reflected in IETF.

Colin

---

From: Eliot Lear <[email-masked]>
Date: Thu, 4 Nov 2021 13:39:27 +0100

> Some of this was re-directed from the IRTF, because it’s a conversation the IETF needs to have about what it considers its threat model when designing protocols.

I don't subscribe to "either/or", and I see this as a two-way street.  
So for instance, how do trust anchors and use of RATS impact the 
Internet trust model?  I doubt that we can standardize that yet.

> There are obviously architecture and research questions in this space, but there’s a lot of concrete engineering guidance that needs to be reflected in IETF.

Great.  Let the conversation be wide-ranging.

Eliot

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Nov 2021 05:48:07 -0700

> > Some of this was re-directed from the IRTF, because it’s a conversation the IETF needs to have about what it considers its threat model when designing protocols.

I think the lack of progress and movement on these drafts isn't going
to get solved if we go to the IRTF. Hic Rhodes, hic salta.

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim

---

From: <[email-masked]>
Date: Sat, 6 Nov 2021 10:43:51 -0400

> I'd be happy to continue the discussion, and I'm starting to think that perhaps
> we should discussing about threat model*s*, not just about a single one. It is
> becoming increasingly hard to tell "technical" threats from "societal" threats,
> and different environments tend to adopt different threat models for the
> same situation, prioritizing different types of threat.

I would agree with this ... I've been working on a threat tree for dc fabrics, for instance, for my "day job." I've not finished it (things have been crazy at my house for the last several weeks, as I'm getting ready to move from Raleigh to the Knoxville area).

Maybe for one meeting we could just discuss the various areas where threat models might be useful.

😊 /r

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Nov 2021 10:47:50 +0200

Updating time to avoid Thanksgiving.

Would Thursday Dec 2nd, 22:00 Paris time, for one hour work? This is Thursday Dec 2nd, 13:00 San Francisco and Friday Dec 3rd, 08:00 Melbourne

Jari

> On 3. Nov 2021, at 14.18, Jari Arkko <[email-masked]> wrote:
> 
> Hi,
> 
> <model-t-status-2021aug.pdf>-- 
> Model-t mailing list
> [email-masked]

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 11 Nov 2021 07:26:03 -0500

Sadly not for me, in part because of the IAB "AID" workshop,

-M

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Nov 2021 17:58:10 +0200

Mallory: I’m in AID workshop too, and I thought I had avoided a collision. On Dec 2nd, AID is meeting UTC 14-17:30. My proposal was Dec 2nd, 21:00 UTC.

Jari

> On 11. Nov 2021, at 14.26, Mallory Knodel <[email-masked]> wrote:
>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Nov 2021 14:19:55 -0800

Hi Jari,
At 04:18 AM 03-11-2021, Jari Arkko wrote:
>We could discuss why…. and have to some extent. 
>Long story  short, my opinion is that has been 
>due to leadership problem (i.e., me) of not 
>organising the group even to have meeting, 
>despite fairly broad set of contributions. 
>Secondly, in hindsight the original decision to 
>focus on RFC 3552 updates may have been a 
>mistake. IAB activities tend to do well on 
>writing about architectural trends, principles 
>to follow, etc, as we've seen with for instance 
>RFCs 8546, 8558 or 8890. Thirdly, IAB activities 
>other than one-time workshops are best done as 
>something where there's a strong drive and 
>participation from IAB member(s), kind of as an 
>extension of IAB helping to complete something, 
>preferably something very specific.

An RFC 3552 update does not fit within an IAB 
program.  The lead issue (if there was one) is 
secondary to that.  The main problem is a lack of focus.

Regards,
S. Moonesamy