Subject: [Model-t] Next steps from Tuesday's breakfast meeting

From: Robin Wilton <[email-masked]>
Date: Thu, 21 Nov 2019 03:34:46 +0000

Hi everyone, and thank you Dominique for listing those follow-up actions.
I noted a few more, though they were of varying degrees of firmness/detail…

Please would those identified in the list below check to see if I have misrepresented their intent, and correct as appropriate?

Agenda Item 1.3: Who, when

Contributions:
Stephen F, Jari A: continue draft
Dominique L: continue draft
Ali R: survey of CDEs, collate some data about threats
Dirk K: will write up the thing he’s going to write up (!)
Tommy C: “aware of”: CLES endpoints draft; malware study
Robin W: will be producing a high-level vulnerability analysis in "crypto as a system” materials (1H2020, probably 1Q2020)
Christian H: will write up a couple of attack scenarios
Melinda S: trust comes from different sources in the world of decentralised apps, and that isn’t coming to the IETF… will write something
	Other:
		[Carsten B: IoT RG will be keeping an eye on thi as it evolves]
		[JA: “trust boundaries” - would MT or EKR contribute?]
MT - I have a half written thing

Timing:
Interim call in late Jan/Feb
Deferred decision on whether to meet at IETF107 (Vancouver, March 2020)

Best wishes,
Robin Wilton

---

From: "Rezaki, Ali (Nokia - DE)" <[email-masked]>
Date: Thu, 21 Nov 2019 05:53:45 +0000

Hello Robin, All,

Thanks very much for our Tuesday morning meeting and for the summary of the follow-up actions.

Just a short update on my action item please:

Ali R: Document the attacks that exploited vulnerabilities in IETF protocol specifications, covering also implementation and deployment vulnerabilities that modified specifications might have mitigated; starting with a survey of the CVE database.

Safe travels all.

Best regards,

Ali

From: Model-t <[email-masked]> On Behalf Of Robin Wilton
Sent: Thursday, November 21, 2019 4:35 AM
To: [email-masked]
Subject: [Model-t] Next steps from Tuesday's breakfast meeting

Contributions:

  *   Stephen F, Jari A: continue draft
  *   Dominique L: continue draft
  *   Ali R: survey of CDEs, collate some data about threats
  *   Dirk K: will write up the thing he’s going to write up (!)
  *   Tommy C: “aware of”: CLES endpoints draft; malware study
  *   Robin W: will be producing a high-level vulnerability analysis in "crypto as a system” materials (1H2020, probably 1Q2020)
  *   Christian H: will write up a couple of attack scenarios
  *   Melinda S: trust comes from different sources in the world of decentralised apps, and that isn’t coming to the IETF… will write something
            Other:
                        [Carsten B: IoT RG will be keeping an eye on thi as it evolves]
                        [JA: “trust boundaries” - would MT or EKR contribute?]

  *   MT - I have a half written thing

Timing:

  *   Interim call in late Jan/Feb
  *   Deferred decision on whether to meet at IETF107 (Vancouver, March 2020)

Best wishes,
Robin Wilton

---

From: Melinda Shore <[email-masked]>
Date: Fri, 22 Nov 2019 08:14:10 +0800

Thanks, all, for the notes.  One thing I don't think we've discussed
is the ultimate disposition of the work.  I'm not clear whether this
is going to be progressed as an IETF consensus document, an IAB
document, ... ?  I'm also not clear on the process for synthesizing
these individual drafts into a coherent statement and it may be
worth spending a few minutes on that, particularly in the case of
drafts with overlapping subject matter.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Nov 2019 02:40:06 +0000

Hiya,

On 22/11/2019 00:14, Melinda Shore wrote:
> document, ... ?  

I think, in the success-case, we'd be producing:

- a short (1-2 page of content) draft that we offer to the
IETF as a possible update to BCP72

- as many documents as are relevant that are explanatory
or background materials related to the above. Those might
or might not be I-Ds/RFCs or other kinds of document.

> I'm also not clear on the process for synthesizing

I don't think we can know how to handle that until later,
as it'll depend on the work that gets done and from which
we may be trying to select/generalise a few short nuggets
of wisdom.

As I said at the brekkie, a lot of the above seems to me
to follow from the target here being something that could
be a credible update to BCP72 understandable and consumable
for any random IETF participant developing or updating
some protocol.

Cheers,
S.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Nov 2019 12:09:06 +0800

Thanks Robin and all.

On Melinda’s question — the following is my personal opinion:

First off, I think we need to produce IETF outputs. It is great that the IAB has kicked off work and is hosting the mailing list, but I ultimately this is primarily IETF results. Definitely the 3552 change needs to be.

Secondly, as Stephen says we’ll benefit from some parallel and independent works at the moment. That being said, I think there’s some value in brainstorming a bit even in the short term about where the different pieces of work might develop into. I’ve also chatted with some of you about this. From the document that me and Stephen have, we’re going to do one round of introducing additional materials, already in ÷  on our editor’s version but not yet published. Things like taking into account points made in our meeting this week and at the SAAG meeting last time. But moving forward, I think I see our document evolving/split into different parts:

* Analysis of why things have changed & architectural considerations (the bulk of our current doc)
* Suggested edits to 3552 (we have some of that now, but I suspect at some point someone is going to write a cleaner and better standalone document about it)
* Guidelines for designers on what to do avoid some of the issues (we have some of that, but again might be better as standalone document, or perhaps with competing proposals)

But in addition to this, there are many other parts that might benefit from having independent documents. E.g., a discussion of attacks and issues that we’ve seen that support the case for more careful consideration of these issues (Dominique or Ali perhaps). Or, a document on trust and where that comes from and plays with architecture (Melinda or Ted/Martin perhaps). A vulnerability analysis (Robin, perhaps). And I don’t mean to say we should avoid competing documents, those are very welcome at this point as well. But it is still worthwhile to think about the different aspects that one might want to write about, and focus a particular piece on a chosen angle.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Nov 2019 04:30:55 +0000

Hiya,

I agree with all below except I'd not say "competing." The
way I think about it is people are working independently on
more or less the same thing but from different perspectives
and bringing different backgrounds. And that's a good
thing.

So I hope we don't think about this in terms of competition
but rather as a set of people taking different paths to
what we hope might be the same destination.

Cheers,
S.

On 22/11/2019 04:09, Jari Arkko wrote:
> First off, I think we need to produce IETF outputs. It is great that
> the IAB has kicked off work and is hosting the mailing list, but I
> ultimately this is primarily IETF results. Definitely the 3552 change
> needs to be.
> 
> Secondly, as Stephen says we’ll benefit from some parallel and
> independent works at the moment. That being said, I think there’s
> some value in brainstorming a bit even in the short term about where
> the different pieces of work might develop into. I’ve also chatted
> with some of you about this. From the document that me and Stephen
> have, we’re going to do one round of introducing additional
> materials, already in ÷  on our editor’s version but not yet
> published. Things like taking into account points made in our meeting
> this week and at the SAAG meeting last time. But moving forward, I
> think I see our document evolving/split into different parts:
> 
> * Analysis of why things have changed & architectural considerations
> (the bulk of our current doc) * Suggested edits to 3552 (we have some
> of that now, but I suspect at some point someone is going to write a
> cleaner and better standalone document about it) * Guidelines for
> designers on what to do avoid some of the issues (we have some of
> that, but again might be better as standalone document, or perhaps
> with competing proposals)
> 
> But in addition to this, there are many other parts that might
> benefit from having independent documents. E.g., a discussion of
> attacks and issues that we’ve seen that support the case for more
> careful consideration of these issues (Dominique or Ali perhaps). Or,
> a document on trust and where that comes from and plays with
> architecture (Melinda or Ted/Martin perhaps). A vulnerability
> analysis (Robin, perhaps). And I don’t mean to say we should avoid
> competing documents, those are very welcome at this point as well.
> But it is still worthwhile to think about the different aspects that
> one might want to write about, and focus a particular piece on a
> chosen angle.
> 
> Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Nov 2019 12:50:45 +0800

Yes, that’s what I meant to say…

Jari

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Nov 2019 01:56:35 -0800

> what we hope might be the same destination.

To pull in a word from Dominque's earlier message: "efficiency" may come at
the cost of missing some creative thoughts that would have been expressed
in a more independent development.  Or, at least that's my interpretation
of what is being said.

-Ben