Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 15 July 2019 00:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60C01202A1 for <secdispatch@ietfa.amsl.com>; Sun, 14 Jul 2019 17:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Level:
X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 hHRI8AW7qtP7 for <secdispatch@ietfa.amsl.com>; Sun, 14 Jul 2019 17:27:41 -0700 (PDT)
Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 6DFE41200B7 for <Secdispatch@ietf.org>; Sun, 14 Jul 2019 17:27:41 -0700 (PDT)
Received: by mail-oi1-f170.google.com with SMTP id l12so11394286oil.1 for <Secdispatch@ietf.org>; Sun, 14 Jul 2019 17:27:41 -0700 (PDT)
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=FTUIeqZ88mr1G0vLDXqzKSBvmb7ykHZBdLT8a+IxpVM=; b=UFUkys1jXbxcxXVExM0MEX9iOrOq2j1f/VWjbiABHZpNt3jUQU5UbWLmESkSzbvymF eI8Sa97K6cGMo/fn1J8Nbogy4v5TqdWqusEMapSUiY12otHT1722KeUBAaApOsDytDL2 SNYAs+j781TCaxficHtdIluE1ImxXRCq0F8u5BxNujqXA9ScR9ovXDcaXo3xRESSQWXT pR4CfUcI1lHQZjgeZXDUFCEYQliwXIGbiYi++Z6kiww0DAgikre57n0VhYR/9oK8H9Gt l3zrWDXH6cI4qMLZ2LXuEGCZ25A6eWMkdf4fNfYD2D4qh1dRv9YQSfKKD1Bly0DeTcZO SYVg==
X-Gm-Message-State: APjAAAVC65gCsrk7Sx9ACd/Q/yZWjKas62Mux111lfu82Zs3eVfFmhY7 mpRYX5yWrE9sKx0qcamv6BekD0J/dfUAkawRKmM=
X-Google-Smtp-Source: APXvYqwNyH0XBLsIhVbtQEIdFiKiy7uePunZ/RaFdqEwOa5kwI/A7B+JgC2x9biIHK0E/eO+K88Umh0+2t7qXUd1T8I=
X-Received: by 2002:aca:5883:: with SMTP id m125mr12276617oib.58.1563150460652; Sun, 14 Jul 2019 17:27:40 -0700 (PDT)
MIME-Version: 1.0
References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> <CABcZeBNwmitpkJn0fCbNHOJtJ25yXdk6i6U9wK0a-9hwK1Tqcw@mail.gmail.com>
In-Reply-To: <CABcZeBNwmitpkJn0fCbNHOJtJ25yXdk6i6U9wK0a-9hwK1Tqcw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 14 Jul 2019 20:27:29 -0400
Message-ID: <CAMm+Lwim0UK9YOO0vh+O0eOCQjZgsPQLdFZFQgsbpxpFNZChrA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, smart@irtf.org, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Dominique Lazanski <dml@lastpresslabel.com>, IETF SecDispatch <Secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f01188058dad533f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/QQOZqwMJHi92M9DkIi3bw2z9HLI>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 00:27:43 -0000

On Sun, Jul 14, 2019 at 5:25 PM Eric Rescorla <ekr@rtfm.com> wrote:

> I more or less agree with Stephen's position.
>
> First, I recognize that this focus on secure endpoints talking to each
> other is probably the part of 3552 that people are most unhappy
> about. As I was almost certainly the person who wrote that text, it might
> be helpful if I laid out some background.
>
> First, RFC 3552 isn't intended to say that endpoint threats aren't
> real, but merely that they are out of scope because they are hard
> to address. Here's the text in context:
>
>    The Internet environment has a fairly well understood threat model.
>    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.
>

Hmm... restricting the requirements according to what problems we think we
know how to solve seems to be a bit of a systematic problem in the
industry. I remember when the malware issue hit and the anti-Virus vendors
refused to consider it as their problem because they didn't replicate as
viruses.

First, I'm not sure that I agree that cyber attacks on endpoints are
> the greatest threat to the Internet, but even assuming that's so,
> what are the implications of that for work in the IETF? It's one thing
> to change the words of 3552, but what work specifically would we
> do if those words were different.
>

I'm not keen on the focus on the end point. It seems like it is brought up
as a trump card to 'prove' that all security efforts are futile and the
criminals must always win. And I don't think it is true its just defeatism.

The reason we need the IETF is that communications protocols are most
useful when everyone uses the same thing so we can talk to each other. So
communications protocols need standards and hence standards for security.

Endpoints don't require standards in quite the same degree. But that
doesn't mean that nothing we do is relevant to endpoints.

For example, forget 95% of trustworthy computing, the main residual
vulnerability of crypto protocols is the risk of private keys being leaked
off the machine. That is an endpoint security control that provides real
leverage for relatively little cost. But it is a mechanism that can only be
used in communication protocols if they are designed with that constraint
in mind.