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

Eric Rescorla <ekr@rtfm.com> Sun, 26 January 2020 07:37 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75012008F for <architecture-discuss@ietfa.amsl.com>; Sat, 25 Jan 2020 23:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iIncPReHjkg for <architecture-discuss@ietfa.amsl.com>; Sat, 25 Jan 2020 23:37:18 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9BF12008D for <architecture-discuss@ietf.org>; Sat, 25 Jan 2020 23:37:18 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id y4so7317781ljj.9 for <architecture-discuss@ietf.org>; Sat, 25 Jan 2020 23:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=pLQcheJrxL0KKpTqZGvkhurXmEqUM0RsCe4AsoAmyNgJG/vydkCuztvuiRgG/6Hemt 600fKQs8IeggEQFU3loUw2dE3uZ1Sq9bJHrpiGiKsk7hueKfmxB39ZvsxObssxAjuxej lSjnKBs2C6eJUUbTdDnmdRchQQayadCHsD+STlhoUQ+3NP0Wh1W4vxn9QLzTXLEmIcLl m0EGe2cEOg7ZTq6lEDafqLtnvS3d8ryvYjUcDxB/ehv95ip2Zf22FePwe+KZ1M8c6J5h ohFebSx3Ah0FtHjaisn/iH0UNU/DkQYqWfGXsYwPvGmp0UoVhOwguMzkEXj8yo0POvYF UNsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=Zvw/qSUDWqi+2oQ92AxO7Kk5p4P06Jf4nEZpgnxu5J8A7So1o/Vx6MijyzuVAUI2vy G5vSiWts4MMVz0od/MvlYN6FP6foTIdN9AnHtT4NY7mcE5jfgiNy85dfUMtWi8DEG9WI PUAqebIVkajyxBcy11rRKyi6VjHivHZmqfjgkRFw9eoP8xOxFgt9sAHTOXKulbgnfoJJ P4soeiMQaNlm0Q5JsFcdiFT7fCooZANIslh9YQmkjLSW4S9WV/JZ2OC/5pGjY8NUiurx IFROVUdDfvMaL/vRgzfsXEKD8Co/sYKYTpZO6U1klwT5Fhkxhu29Vb893TjURlbH3FR4 N/sA==
X-Gm-Message-State: APjAAAUA7FlQfNbq2GKEkWIaJGclIenSKQp1BrkFsaN5V97Xbok0NaZf EG02ex11C+Tp8Bt0+C1kVepGacrtsiJaScZSzEHtqw==
X-Google-Smtp-Source: APXvYqwETYtdkryvbWSHtFG+kmJSqEe7bYcaLM89AzWDkIC7/YJiyMNrJ/Td+7qzEjJMP5lWogNXXP2s5NH5mm83uN4=
X-Received: by 2002:a05:651c:448:: with SMTP id g8mr6949631ljg.35.1580024236474; Sat, 25 Jan 2020 23:37:16 -0800 (PST)
MIME-Version: 1.0
References: <E2D709DC-DD01-4946-B2F1-7EE0E101DEF0@piuha.net> <dff1c31e-44d4-6045-aaeb-03ac1e855200@gmail.com> <CABcZeBOYsP+SBNdLqc-wmyJAs1A+hvWbKud_XfvDgi9zJVMD+w@mail.gmail.com> <CA+9kkMDFm7nboqQY2OjNvmcWxs_30d_5NtBv8Nd1eLBnWKBaBw@mail.gmail.com> <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <C7FDAD8F-D66A-4618-9F87-B1BB9CEA191B@cisco.com>
In-Reply-To: <C7FDAD8F-D66A-4618-9F87-B1BB9CEA191B@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 25 Jan 2020 23:36:39 -0800
Message-ID: <CABcZeBPKFEEDqQEGXZAD87n5cCsA75+uMGp-brq0JXBoW91LjQ@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Christian Huitema <huitema@huitema.net>, Ted Hardie <ted.ietf@gmail.com>, architecture-discuss@ietf.org, model-t@iab.org
Content-Type: multipart/alternative; boundary="0000000000005a13c0059d060f22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/_NVzjsKlV4sUJJ6ps3M_fRA34K4>
Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 07:37:20 -0000

It's probably useful to put the text in 3552 in context, which was
primarily about designing COMSEC protocols. Our ability to build two party
protocols which survive one of the parties being compromised is fairly
limited. We *do* have some praxis for building N party protocols which
gracefully degrade when some of the nodes are compromised (for instance
consensus protocols). Of course, the exact properties of those protocols
can be difficult to succinctly state.

I'm not quite sure I understand what you mean when you say "They are the
source of just about all compromise attacks." I'm not saying it's not true,
but perhaps you could elaborate.

-Ekr


On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear <lear@cisco.com> wrote:

>
>
> On 25 Jan 2020, at 02:56, Christian Huitema <huitema@huitema.net> wrote:
>
>
> Phrasing that as "don't trust the endpoints" is probably inappropriate.
>
>
> Why?  They are the source of just about all compromise attacks.
>
> My personal worry is the cascading impact of end-point compromise. Take
> the example of a large network. Large network means multiple routers. If
> the multiple is high enough, we have strong risks that one of those will be
> compromised at some point. If we merely "trust the endpoints", then a
> single compromise of one of the endpoints means the game is over. But it
> does not have to be so. In an ideal world, implementations of the routing
> protocol should be able to detect aberrant behavior and isolate the
> compromised node. In practice, that's really hard.
>
> We sell product that does this today.  But it is hard, which is why people
> pay us.  Of course, it gets harder with encryption, but we even have
> product for that.  I prefer the other approach: tell us what good behavior
> looks like (manufacturer usage descriptions).
>
> But there are still general principles like "least amount of privilege" or
> "need to know basis" that could help.
>
> Indeed.
>
> I would really like that protocol designers think about that too, instead
> of merely asserting trust in the endpoints.
>
>
> How much is this the protocol and how much is the application?  The
> protocols most apps are using today are, ermmm, HTTP.
>
> Eliot
>