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

Kathleen Moriarty <> Tue, 28 January 2020 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56D9D1200E5 for <>; Tue, 28 Jan 2020 08:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ch33kIGrqu5Q for <>; Tue, 28 Jan 2020 08:50:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C30D1200D5 for <>; Tue, 28 Jan 2020 08:50:39 -0800 (PST)
Received: by with SMTP id v19so1053582oic.12 for <>; Tue, 28 Jan 2020 08:50:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=XnA3rOpEGlLCGxJ5LizuYC9Lo5NSGdCUXxsA3Qix+cv5cEzXVOozZCZ1jAEQt8vf3W yFEuOY4vQCapEgyhc83YbNYEE+c/ooDVK5CFul6eX9y8w4nYv4g4ouRrUEhxRlW1+y0J 2WeIZn5VVQw06Pwso/qRLGePsqJOYEgleTgTDIFL0ARs0XT8zBbLc3lNOkPsJA/rAoUt XWi0IftufhKlK3c+PBej8ANiU4A2XIIrRDvOuGp8GaBj3fROxs1ySVhSUE3lqkgWbcdZ U6FSzyEf9L1AZh/PWWGH6poPSSscwjLNbZkj48Awda1eJaR621XtyKPk1tEbhrCP8cN5 QQkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=A6GNiQDNvUE/1gvR15ITpvYMLncFP4DUhY+0gvGLqcW56ue28udiuDxU0SjsWCoco2 Ig2sdRskE3fNVlJrWUQHOsMNYkcSCzwXRWONYX1F04KsQFnwWZ0T3vC6voONdglK3HpE mXP8Eiv2wYV+CSVRjk7x5R5gQrrtyoapGa2QicxSyf7RagrkTWRW6Mx+OcnGfBd4zL1Z AhRIR2VkIM/fNRcm+bHHQCDia4drcTs+Ex5FNrRM1cR8m5gUjELLsb3aFx9hl9c6tAN3 XoYXu4AYZDh0dugUW8L812FX/FKn0k4cL7zpFk+jSjZdmm3G/3kaI3W95B2AJq7QMiQg drkQ==
X-Gm-Message-State: APjAAAVHUpbTCNQDROz0E+oBPsv0rso5VHh2mXj5jnP19DtrTNTU//e/ ifWuFDZl2ARLfqfoIQQ3rkZYeaH1sVf04KQhROk=
X-Google-Smtp-Source: APXvYqy6X86IIaM+SILpTaPA+OKTKBuvjt+BffdwCRvFwRG89+3u+UaR3r8hOJq09opRgLdLPqNconSXtD0D5Jtgubg=
X-Received: by 2002:a54:4f04:: with SMTP id e4mr3268167oiy.111.1580230238340; Tue, 28 Jan 2020 08:50:38 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <78E09CC1706F7D66D5F8DE1E@PSB>
In-Reply-To: <78E09CC1706F7D66D5F8DE1E@PSB>
From: Kathleen Moriarty <>
Date: Tue, 28 Jan 2020 11:50:02 -0500
Message-ID: <>
To: John C Klensin <>
Cc: "Joel M. Halpern" <>, Eliot Lear <>,,
Content-Type: multipart/alternative; boundary="000000000000050a88059d3606a6"
Archived-At: <>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2020 16:50:45 -0000

On Tue, Jan 28, 2020 at 11:21 AM John C Klensin <> wrote:

> --On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern"
> <> 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.

A number with expertise in this area are engaged in the SACM, RATS, TEEP,
and SUIT working groups.  More were starting to come for SMART, but that
was shutdown.  Personally, I think engaging those who have expertise in
this area is important and some draft authors who came for SMART should be
engaged.  They are on the front lines of malware and other system level

Best regards,

> 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
> _______________________________________________
> Architecture-discuss mailing list


Best regards,