Subject: [Model-t] Possible 3552 changes

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Feb 2020 18:00:41 +0200

Working backwards for a bit, I wanted to take a look of the possible options we have for an eventual update of RFC 3552. I was able to identify three possible approaches to these changes.  See below for them.  Do people have a feel of what kind of eventual update style would be desirable? The exact wordings below are examples, but there seems to be possibilities to do a very minimal change and a very large, lengthy guideline change.

OPTION 1. Simple

For instance, ddraft-arkko-farrell-model-t-02 section 6 suggests this:

  OLD:

      In general, we assume that the end-systems engaging in a protocol
      exchange have not themselves been compromised.  Protecting against
      an attack when one of the end-systems has been compromised is
      extraordinarily difficult.  It is, however, possible to design
      protocols which minimize the extent of the damage done under these
      circumstances.

   NEW:

      In general, we assume that the end-system engaging in a protocol
      exchange has not itself been compromised.  Protecting against an
      attack of a protocol implementation itself is extraordinarily
      difficult.  It is, however, possible to design protocols which
      minimize the extent of the damage done when the other parties in a
      protocol become compromised or do not act in the best interests
      the end-system implementing a protocol.

----

OPTION 2. Adding more material about endpoints and core issues

In draft-arkko-farrell-model-t-02 this is also in section 6.

   NEW:

      The design of any Internet technology should start from an
      understanding of the participants in a system, their roles, and
      the extent to which they should have access to information and
      ability to control other participants.

   NEW:

   3.x.  Other endpoint compromise

      In this attack, the other endpoints in the protocol become
      compromised.  As a result, they can, for instance, misuse any
      information that the end-system implementing a protocol has sent
      to the compromised endpoint.

----

OPTION 3. Adding even more material about guidelines, areas of concern,
recommendations of techniques to use.

We  have not seen proposals for this yet at least.