Re: [arch-d] Possible new IAB program on Internet trust model evolution

a) My conclusion from Brians point is that the planned charter should 
   be more explicit about its planned topics:
   1) investigate / examine security/trust in todays context
   2) Propose update direction for rfc3552 only within a pragmatic realm
      to direct RFC writers.
   3) Propose any output not suitable to rfc3552bis to other documents,
      to the extend that they are more architectural than specifications,
      IAB might even take lead on such documents. If spec, then its
      obviously IETF.

b) We had a good amount of IETF investments into security re. privacy/
   perpass, and i am sure there is enough community in IETF/IAB to
   add anything that might be missing re. those aspects in rfc3552.

   But for the also quite top-of-mind issue of trustworthyness of
   critical network infrastructure outside of privacy/perpass, i do see
   if/how this would be considered beyond the tactical protocol detail
   aspects we have in 3552.

   For example, i do not see any classifying of the dependencies and impact
   of attacks in relationship to the purpose of a specific protocol, or the
   impact and possible benefits of automation, published source code that
   can be matched to running binaries, size/complexity of operations
   (validation) code size, and device-level security expectations.

   Consider the simple example of specifying a distributed routing protocol
   that can run in 20,000 lines of code that vendors publish, and which
   operates automatically without nerd knobs . Security analysis of the source
   code is feasible, absence of nerd knobs should eliminate the ability to bring
   it down from the management plane, and simple heuristics of number of prefixes 
   forwarded could limit impact of individual bad players. Then compare
   this with 10  million lines of PCE+SDN controller software 50% from 30 open
   source projects, 50% never published vendor code controlling an OF
   forwarding plane.

   My rough approximation of security is that i can deploy the first distributed
   system pretty safely after not too costly code analsis without otherwise having to
   trust the vendor, whereas in the second case, the poor vendor would be badly
   advised to trust even his own product due to all the integrated third party
   software, and as a customer i'd either have to be state actor with enough tax
   payer money to spend on code analysis or wait and hope for better AI
   in the future.

   Not sure what or how much of such security aspects could/should be in
   rfc3552bis, but it would be nice if these type of architectural considerations
   would be in scope. Especially because the industry is on a track to an
   ever more complex, fragile and hence security challenged infrastructure designs.

Cheers
    Toerless

P.S Full disclaimer: of course this mail is self-serving from the
perspective of working on ANIMA, but i hope that does not make it any
less useful.

On Sat, Jan 25, 2020 at 08:46:46AM +1300, Brian E Carpenter wrote:
> Hi,
> 
> I'm confused. What we have in RFC3552 is very intentionally guidance for
> RFC writers on what they need to cover in their RFCs. Its specific purpose
> was to get rid of "Security considerations are not discussed in this memo." 
> Its purpose was not primarily to define an abstraction like a "trust model"
> or a "threat model" (the draft charter seems a bit vague about which of those
> it means).
> 
> I really do not want to see the pragmatic purpose of RFC3552 lost in the
> effort to define these abstractions. I don't think that is the intention,
> but the text seems to imply that RFC3552 was mainly a description of a
> generic threat model, which it wasn't.
> 
> I am not against an IAB effort to analyse how the threat and trust models
> (plural) have evolved since the security workshop [RFC2316] that ultimately
> led to RFC3552. That seems like a good idea. An update of "Guidelines for
> Writing RFC Text on Security Considerations" also seems like a good idea.
> But the draft charter text seems to conflate these two separate lines of
> action.
> 
> Incidentally, while writing the above it occurred to me why the phrase
> "IAB program" has always slightly disturbed me. Really the proposal is
> a virtual IAB workshop (whereas RFC2316 came from three days in a room
> together in Murray Hill, NJ). A good idea, but not a program.
> 
> Regards
>    Brian
> 
> On 25-Jan-20 00:49, Jari Arkko wrote:
> > 
> > The IAB are considering starting up a programme on Internet
> > trust model evolution as described in the link at the bottom of this
> > email.
> > 
> > We'd like to get feedback on that idea and the text. As you may
> > be aware, in 2019 a number of documents were published on
> > this topic and discussions held (on the mailing list, SAAG, side
> > meeting at IETF-106, workshops, etc). There???s also a virtual
> > meeting coming up on February 14th.
> > 
> > To be clear, any output from this program would be text offered 
> > to the IETF for consideration - it is not within the IAB's remit, nor 
> > that of an IAB program, to modify a BCP. Nonetheless, an IAB 
> > program offers a good venue for this work, as it perhaps allows 
> > for more focus on the evolving architecture aspect within this space.
> > 
> > The plan is for the new program to be entirely open for participation,
> > similar to how the current work has already been. That is, the mailing
> > list is open for all interested to join, meetings are open and listed
> > in the public agendas. The IAB will find a chair or chairs for the
> > group to stay organised.
> > 
> > There's no specific deadline for this, but the IAB will consider this
> > further in the next few weeks, so if you could take a few minutes 
> > to share your thoughts on this that'd be great.
> > 
> > https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
> > https://www.iab.org/mailman/listinfo/model-t
> > 
> > Stephen & Jari