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

Eric Rescorla <> Thu, 30 January 2020 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC32212016E for <>; Thu, 30 Jan 2020 07:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uprrGk0_DCJE for <>; Thu, 30 Jan 2020 07:32:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0151120168 for <>; Thu, 30 Jan 2020 07:32:21 -0800 (PST)
Received: by with SMTP id q8so3841159ljb.2 for <>; Thu, 30 Jan 2020 07:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=m4TwXyftWbb07OTNJyENFAj7lbRZogp0uZu779O0SG5nKdgd6mfXsl49ZTX2CRqAiP jlTtCOf6fXP1IWsreKT5yYPft5yv0U7K7ydHCyC38vHXy65eil0TSXIHQAnXZz5W9NqZ Lps6QIA9rLm3lspmSFnWlHxR8rk6EQwyM03ocwHCCK+/muwxRZZIsQ3/vKrnwPqFB3ND W1+49rOA+E6nB/BTywNpmCJWK7ylcJqniHKlCiu13gSuR50mQZoofQFQ8QLayF7HHmSH uBADcGfAV7J93thMMj6aYtFXCZouRRNIcZOoaxYTVaPVbBQ/sbooZQXOivq7a9NlgKRL hNeA==
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=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=FMlKqKZLFve7WFHsKtYkKT2w7NVb+PtKvyeCG01L4N0wPFbVHDA2W+Y3+EPhCcF6JE ABqWmZfneXGYtKvf5uPDPWOOn10nHUzmdqBQJzWbsvTZ8Xp8xhbuUpYG4hnRru9Rd+nK H4CDEmbcwmu8U73XI8AgGLcDGbOEtg2SvibeKwWGlnre3oV3U59GvuJSEPsvi2w/aqgb tJTFqxXMq0Utk4v6N4VxZhgFbJkYiQBghZX5FUeukiJOlVU9XH5H2+B5ZuaQ7+Qb7zVI W4p9QjQtvugX+k+nEiOz4TFDs//JJP/nb9rEoviBmPKHCqCSitcAwGmpkYmMkMZb7dJn 0ObQ==
X-Gm-Message-State: APjAAAVBxF8QetRVTTuqzm1zU814zj6CDYny3ZcK64O+wTkVXgPLJVPJ aFLNOzg3SNIEOevmNDoTEOPk4ZwXqO7vhtVSnlZF0h2wAeK0Nw==
X-Google-Smtp-Source: APXvYqykCM3n6eRC652luis3NmHyg9/PKJeRQVjD/CRUuPRbvdJxmTYGZM2aj/p/dvPEoV4pLnLyYS9yZRbvpHiNo6k=
X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr3132179ljn.162.1580398339850; Thu, 30 Jan 2020 07:32:19 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 30 Jan 2020 07:31:42 -0800
Message-ID: <>
To: Jari Arkko <>
Content-Type: multipart/alternative; boundary="000000000000a69801059d5d2930"
Archived-At: <>
Subject: Re: [arch-d] 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: Thu, 30 Jan 2020 15:32:24 -0000

> There is relatively broad agreement that the roles and trustwortiness
> of different endpoints in a protocol exchange are important
> considerations. In specific cases there may be quite different
> perspectives on the tradeoffs involved, e.g., to what extent privacy,
> information centralisation, or the needs of enterprise networks should
> be considered as the highest priority. And no doubt, other equally
> valid perspectives exist.

Actually, it's not clear to me that *any* of these are valid
things to put in a threat model. Recall what 3552 says a threat
model is:

   A THREAT MODEL describes the capabilities that an attacker is assumed
   to be able to deploy against a resource.  It should contain such
   information as the resources available to an attacker in terms of
   information, computing capability, and control of the system.  The
   purpose of a threat model is twofold.  First, we wish to identify the
   threats we are concerned with.  Second, we wish to rule some threats
   explicitly out of scope.  Nearly every security system is vulnerable
   to a sufficiently dedicated and resourceful attacker.

But none of the things you list are really part of a threat model.

Rather, they are weights one applies to various design considerations,
but that's a consideration but that's a form of analysis that happens
*after* you have a threat model, not part of the threat model itself.
For instance, I don't think anyone thinks that privacy threats (e.g.,
traffic analysis) aren't part of our threat model (and they're clearly
part of the 3552 threat model). Now, as a matter of protocol design,
we have often opted not to do much about these threats for practical
reasons, but that's a different matter.

As Brian said, the purpose of 3552 is to force protocol designers
to describe the security properties of their protocols and the purpose
the threat model section is to provide a common starting point for
that analysis. IOW, it is an essentially tutorial function So to the
extent to which an update for 3552 is needed, its purpose should be to
make clear considerations which aren't otherwise obvious from the text
in 3552. But that's not about a new threat model or about balancing
but rather about documentation.


On Fri, Jan 24, 2020 at 3:50 AM 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.
> Stephen & Jari
> _______________________________________________
> Architecture-discuss mailing list