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

[John C Klensin <[e-mail]>]

--On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern"
<[e-mail]> wrote:

> I am a bit concerned by the emphasis on what appear to be
> application policy, business policy, or government policy.  To
> the degree that these are decoupled from the technology we
> define, my impression is that the IETF is neither skilled at
> nor influential with regard to these topics. We can spend a
> lot of time and energy on them.  They are interesting topics.
> But are they really our business?

Joel,

I've been trying, not very successfully, to follow this very
lively discussion, but two observations which I hope are not out
of context:

(1) I think that "neither skilled nor influential ... [and
therefore] not our business" leads us down a path whose
destination is irrelevancy.  Even for link encryption (and
perhaps more so when the scope is broadened), we should probably
recognize that mounting pressures from law enforcement (both
associated with governments some of us like if they like any
governments at all and those they don't like or who are viewed
with more suspicion) could easily lead to regulations for
government access to keys or other backdoors or even to outright
bans on public use of cryptography.  Even noting that arguments
from the technical community had major influence on killing the
Clipper Chip effort and that making those arguments was very far
from "not our business", it seems to me that good engineering
requires that we not put our heads in the sand and pretend that
the world is different then it actually is or might be becoming
when we design protocols.   In particular, that may mean that,
in some places, we should be writing specifications less in
terms of "if you want to have privacy, you MUST do X" and more
in terms of "...SHOULD do X unless that is not feasible but, if
it isn't, then the fallback approach SHOULD include Y and Z".
In the real world, "feasible" may include political of other
constraints, not just constraints imposed by physics.  We may
not always be able to figure out good alternatives to our
preferred recommendations, but I suggest that making a balanced
and good faith effort to understand the problems and the
environments in which we expect our protocols will be used will
lead to better design even when we don't have good solutions.  

Or, to put it more negatively, if we fail to understand and try
to account for those environments, we risk being put in a
position in which _we_ are the ones responsible for Internet
fragmentation and/or for protocol work moving to bodies other
than the IETF because regulators make conforming implementations
of IETF protocols illegal or commercial firms discover that
conforming implementations cannot be developed and sold.

(2) If I correctly understand the issues that Eliot, Watson, and
Kathleen are exploring, the key involves the rather classic
security issues of authorization and authentication --who should
have access to particular information and how do we tell they
are who they claim to be?  In a way, maintaining and enforcing a
non-trivial list of authorized parties but keeping everyone and
everything else out (the example of some doctors and the
patients themselves is very helpful for thinking about this) is
a lot harder than keeping everyone out except those who control
the endpoints (whatever that means).   But most of that problem
is technical and, if we don't have the expertise (I'm tempted to
say "any more") that is a problem for us.

In both cases, it seems to me that an IAB Program (or at least
one or more serious workshops) are exactly the right model for
addressing these problems for at least two reasons:  The IAB is
in a much better position than, say, an IETF WG, to recruit
specific expertise to cover perspectives and areas of expertise
that are not widely available in the IETF.  It is also perfectly
reasonable for such a program to produce recommendations about
issues that need to be considered even if they have no good
solutions or even if they are convinced that there are no
solutions out there.  I can only hope that the IAB will hold
itself to a very high standard of including multiple
perspectives (even perspectives with which IAB members and their
perception of IETF consensus are in significant disagreement)
and a broad range of expertise in the Program and that the
community will hold the IAB accountable if they do not.  If the
way the IAB were to recruit Program members involved asking for
volunteers from within the IETF community and then further
narrowing the Program's perspective by selecting people from
among those volunteers who agreed with the IAB's own views, the
Program would likely be a waste of time or worse.

    john