Re: TLS on disconnected/intermittently connected networks

Keith Moore <> Fri, 05 March 2021 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DDFD3A1A4B for <>; Thu, 4 Mar 2021 16:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rb7KjNENxtEv for <>; Thu, 4 Mar 2021 16:37:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F5C73A1A4A for <>; Thu, 4 Mar 2021 16:37:27 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id D74285C00A1 for <>; Thu, 4 Mar 2021 19:37:26 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Thu, 04 Mar 2021 19:37:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4cQw6/lYVXs2Ls2I4uCRdKKrbMO/r4ZuNpHEg/gyx co=; b=Cvxj8esfE/cIl8DlTtdWv8WqFlbYghjzJf1HBZL63IcSgkWwX5ydx3Um3 smqjwzyp6oml1mhh3CJpRY4fP3VxPsSG0621/t/T8HJQkvSGzG39+2kHQTEI++4N Zh1HDTLLh4xoCifpSAHG30In3O8ewcsQdgquVwGrFniL0xJVJ0UtFz9maO0XzYVS Q9TVr71pPNoJNR6H/cZc2Ot9pYMt8Y/41njnB6My7tGmu2mILTCgtBl3RLBk2+7Z /Puw4XYHwkGnVMI9d/bN9pOJBaW9B+Xn1t+u2tD3oXeNdU4o/fKGu18x3ufMOGMr l74570Q/2b6vEzOdYbXV0EBoxuYgA==
X-ME-Sender: <xms:RX1BYH_P9VjTLnPuQacMcGfxVRIjrrLX2WHGXoTkLDpuEyKWCGcv2w> <xme:RX1BYDr0noyOmodvKlCTvinT_iBhhfqKLF7UAm-lyRWsrBoukTdZIPxZ0Wo84FnAz t3-X45Otj2n0Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddthedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:RX1BYB4Ot8GK49aw94l7UsA6V-hcXhXPAUjLe2axtQ8RSYyH8Bxy5A> <xmx:RX1BYLPj8rpkUEUTsKNY931d44pkOy8ylPHKbQFn6afrVihtsbKV3g> <xmx:RX1BYLPOAAS2dcusN-pbm_msfb8y0JRyMUjkr_xh3UZprhvHCx7jyQ> <xmx:Rn1BYK2qUuqgMQVSna8c7z0staCej_c-aiqKIbZUvnFvWA8zdUoWDQ>
Received: from [] ( []) by (Postfix) with ESMTPA id 333C71080069 for <>; Thu, 4 Mar 2021 19:37:25 -0500 (EST)
Subject: Re: TLS on disconnected/intermittently connected networks
References: <20210302010731.GL30153@localhost> <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Thu, 4 Mar 2021 19:37:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Mar 2021 00:37:29 -0000

On 3/4/21 5:02 PM, Sam Hartman wrote:

>      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.
I can only report what I've seen in my own experience, from circa 2007 
up to and including 2020.
> 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.

I'd love to hear you make that argument to some of the customers I've 
talked to and see what their responses are.   Maybe they'll eventually 
come around, but different communities have developed different ideas of 
what makes for good operational practice, based on their own 
requirements and experiences.   Meanwhile, trying to tell customers that 
they should do things differently than they "know", that your experience 
from a different environment trumps their experience with their own 
environment, seems like a pretty ineffective way to sell product and a 
pretty good way to market for your competitors.

>      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.

Glad we agree on that.  I only wrote it because lots of IETF people who 
might respond to this thread seem to insist that part of the right 
solution is for all of these networks to connect to the public Internet, 
perhaps through a firewall, so that they can query the public DNS, and 
get firmware updates and root cert updates along with those, perhaps 
CRLs also.

I do get your point that we're better at providing reliable 
infrastructure than we used to be, and maybe someone will figure out how 
to package this really cleanly so that it doesn't require a lot of 
expensive hardware to support in the field.   But I'm not sure how much 
that would address these customers' concerns.   It's pretty hard for IP 
address lookup to fail if you start with the IP address.   And they're 
not renumbering their hosts so they don't need DNS or similar service to 
have stable endpoint names.