Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Rick Taylor <rick@tropicalstormsoftware.com> Tue, 27 October 2020 17:07 UTC

Return-Path: <rick@tropicalstormsoftware.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6E03A120F for <dtn@ietfa.amsl.com>; Tue, 27 Oct 2020 10:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 IO6MFZARIj6K for <dtn@ietfa.amsl.com>; Tue, 27 Oct 2020 10:07:28 -0700 (PDT)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB84E3A1219 for <dtn@ietf.org>; Tue, 27 Oct 2020 10:07:27 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0487.000; Tue, 27 Oct 2020 17:06:46 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "rja.lists@gmail.com" <rja.lists@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
CC: "kaduk@mit.edu" <kaduk@mit.edu>
Thread-Topic: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Thread-Index: AQHV53ZaPZuZQYZx2kKGIAZXsCZceKg7HDWAgUgvpACAKQ2MAIAAuUiAgAAlqwA=
Date: Tue, 27 Oct 2020 17:06:45 +0000
Message-ID: <0dde765b0cd41a4cba76be091ef68ba6eb247292.camel@tropicalstormsoftware.com>
References: <158215235500.17580.7759757155303566523.idtracker@ietfa.amsl.com> <50c5dae1bc26ade7d0fcd9388873665868f7284c.camel@rkf-eng.com> <20201001015416.GE89563@kduck.mit.edu> <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com> <783E2375-CDBE-4BCC-B550-5B0A40D3FF51@gmail.com>
In-Reply-To: <783E2375-CDBE-4BCC-B550-5B0A40D3FF51@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Evolution 3.36.4-0ubuntu1
x-originating-ip: [2a02:1648:4000:120::5]
Content-Type: text/plain; charset="utf-8"
Content-ID: <CDB8026ED629FA4283D7EA786239EB5A@home.tropicalstormsoftware.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/6q2NEpM10hARUKgzW6p47dM4Tzg>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 17:07:30 -0000

Ran: +1

I completely agree.

As I understand it there are 2 main use-cases where there is push back
against BPSec and/or TLS:

1. Where it is undesired due to perceived implementation
complexity/computational load.

2. Where there is other security in place that negates the efficacy of
BPsec and/or TLS.

Both use-cases are addressed by an *administrative switch* to turn off
the behaviour when a deployment needs it disabling, but the function
MUST be there to disable at runtime.

It is also worth remembering that although an RFC may mandate
behaviour, there is no way the IETF can enforce this behaviour,
especially in a private network.  By not meeting the requirements of a
given RFC, an implementation is waiving the right to claim that it is
fully interoperable with any compliant implementation.  For some user
groups that may be okay - as they believe they understand what they are
doing, and I don't think we should spend cycles attempting to do
anything other than present what we consider to be the right thing to
do: Implement security but make its use runtime configurable.

See RFC6919 - "MUST (BUT WE KNOW YOU WONT)" - but possibly a newer,
stronger "MUST (PLEASE, IT'S NOT AS HARD AS YOU THINK THESE DAYS)"

Cheers,

Rick

On Tue, 2020-10-27 at 10:52 -0400, R. Atkinson wrote:
> > On Oct 26, 2020, at 23:49, Brian Sipos <BSipos@rkf-eng.com> wrote:
> > 
> > For my own purposes and for public network use TLS would be
> > expected, so I don't have a full idea of when TLS would be
> > desirable to negotiate away.
> 
> A trivial example — which I stress is purely hypothetical:
> 
> 	DTN could be used to communicate between a military ground
> station
> 	and some military satellite in some orbit.  In this case, very
> probably there
> 	would be a military-grade link encryptor installed on both ends
> and ALL
> 	communications over the RF link would have military-grade
> encryption.
> 
> 	In that case, TLS probably could not improve security and it
> ought to
> 	prevent link-layer data compression from working as intended
> (since 
> 	any encrypted data blob ought not be compressible from first
> principles 
> 	of Information Theory).
> 
> Yours,
> 
> Ran
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn