Re: TLS on disconnected/intermittently connected networks

Sam Hartman <hartmans-ietf@mit.edu> Thu, 04 March 2021 22:02 UTC

Return-Path: <hartmans-ietf@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B93A1797 for <ietf@ietfa.amsl.com>; Thu, 4 Mar 2021 14:02:55 -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, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=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 QrXkHD9Ydzmm for <ietf@ietfa.amsl.com>; Thu, 4 Mar 2021 14:02:51 -0800 (PST)
Received: from mail.suchdamage.org (mail.suchdamage.org [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A153A1792 for <ietf@ietf.org>; Thu, 4 Mar 2021 14:02:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id C4603302FF for <ietf@ietf.org>; Thu, 4 Mar 2021 17:02:47 -0500 (EST)
Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zNnfhgGMamW for <ietf@ietf.org>; Thu, 4 Mar 2021 17:02:47 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (cpe-24-165-19-20.hawaii.res.rr.com [24.165.19.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA for <ietf@ietf.org>; Thu, 4 Mar 2021 17:02:47 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1F8CDCA87F; Thu, 4 Mar 2021 17:02:46 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org
Subject: Re: TLS on disconnected/intermittently connected networks
References: <20210302010731.GL30153@localhost> <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com> <YECpybvczdbKHvHx@puck.nether.net> <CAMm+LwiiySi5O1_WDc4-F9x1XfMFFvE-rEbc4uw+31DHJNEHEA@mail.gmail.com> <3f4db10c-dd92-354b-4fc9-6f14f4383454@network-heretics.com> <809967EB-F315-48D9-A301-73DFA4212FDE@dukhovni.org> <f9ad3bdd-3768-8c5f-a98c-73249f9a5ac3@network-heretics.com> <tsleegufxpl.fsf@suchdamage.org> <fcd8515f-5ccf-49ef-2fb5-fbbe57c6349f@network-heretics.com>
Date: Thu, 04 Mar 2021 17:02:45 -0500
In-Reply-To: <fcd8515f-5ccf-49ef-2fb5-fbbe57c6349f@network-heretics.com> (Keith Moore's message of "Thu, 4 Mar 2021 16:05:21 -0500")
Message-ID: <tsla6rifugq.fsf@suchdamage.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lDd1yqaX3mmheHMqt5H4buWgsow>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2021 22:02:55 -0000

>>>>> "Keith" == Keith Moore <moore@network-heretics.com> writes:

    Keith> I've written code for a variety of environments like these
    Keith> for the last 13 years or so: gas pipeline monitoring,
    Keith> broadcast television operations, traffic signal
    Keith> monitoring/control, factory monitoring/automation, avionics,
    Keith> cryogenic dewar monitoring for various kinds of environments,
    Keith> and some others that don't come to mind immediately.   For
    Keith> the environments I've worked with, any of that kind of stuff
    Keith> would be a non-starter.     DNS is rightly seen as yet
    Keith> another reason for things to fail, and factories, gas
    Keith> pipelines, etc. are intolerant of lines being shut down
    Keith> because some IT guy wanted to use a name rather than an IP
    Keith> address. Static IPs work just fine for these situations.  

We're not really in agreement here.
I suspect that was true 20 years ago.
I suspect that was believed to be true 10 years ago, and was possibly
true in important cases.

But over time we've gotten better at providing redundant automated
infrastructure for things like naming etc.

I think we've reached a point now where the advantages of having naming
outweigh the disadvantages.

If for some reason that's still not true, the same infrastructure
advances that make it plausible to provide infrastructure like naming in
these environments also give you the mechanisms to go distribute a hosts
file everywhere or to issue certs with a IP SAN if that's really how you
want to go.
I don't think there's much point in the two of us talking past this
point: we are both appealing to our experience and the set of situations
we've studied and we have reached conflicting conclusions.
We've given our input; it's now time for others to chime in.

    Keith>     Keith> External connections are also regarded as security
    Keith>     Keith> threats

I'm disappointed to see  you bringing a red herring like this into the
conversation.
We were both explicitly talking about disconnected/intermittantly
connected networks.
Appealing to external connections would clearly not be the answer there.