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

Benjamin Kaduk <kaduk@mit.edu> Thu, 19 November 2020 10:57 UTC

Return-Path: <kaduk@mit.edu>
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 959423A03FB for <dtn@ietfa.amsl.com>; Thu, 19 Nov 2020 02:57:00 -0800 (PST)
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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ng6Gc_X0r0_Z for <dtn@ietfa.amsl.com>; Thu, 19 Nov 2020 02:56:59 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FEC3A03F3 for <dtn@ietf.org>; Thu, 19 Nov 2020 02:56:58 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AJAuqE1006935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 05:56:56 -0500
Date: Thu, 19 Nov 2020 02:56:51 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "R. Atkinson" <rja.lists@gmail.com>
Cc: DTN WG <dtn@ietf.org>
Message-ID: <20201119105651.GB39170@kduck.mit.edu>
References: <158215235500.17580.7759757155303566523.idtracker@ietfa.amsl.com> <50c5dae1bc26ade7d0fcd9388873665868f7284c.camel@rkf-eng.com> <20201001015416.GE89563@kduck.mit.edu> <MN2PR13MB3567B7727DF06411E47A826A9F160@MN2PR13MB3567.namprd13.prod.outlook.com> <6D6A8A1F-69C2-4B2B-B8B3-464C680D9A3D@gmail.com> <20201117011009.GA39170@kduck.mit.edu> <F3214A44-2F53-46F4-B45C-DF511E962E6E@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F3214A44-2F53-46F4-B45C-DF511E962E6E@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/Uuqb5VqfsNVnnCYPODOaaWvKNOo>
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: Thu, 19 Nov 2020 10:57:01 -0000

On Wed, Nov 18, 2020 at 10:38:57PM -0500, R. Atkinson wrote:
> 
> 
> > On Nov 16, 2020, at 20:10, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > If we say that TLS support is "mandatory to implement" (do we?  I couldn't
> > find such text in a quick search, but thought we had talked about it),
> 
> Hi,
> 
> I don’t see any text saying that TLS is “mandatory to implement” in the TCPCL I-D.  
> 
> I believe the TCPCL I-D should have text, probably in Security Considerations, saying that:
> 
> "TLS is mandatory to implement for all TCPCL implementations, but TLS is optional to use for a given TCPCL session."
> 
> I imagine the WG would be comfortable with words generally along those lines, but I am not sure whether a formal WG decision has been made. (DTN Chairs ?)

I would be very happy if something like that could be added.

> > it would require some very convoluted reasoning to come up with a scenario
> > where an entity is "not capable of exchanging messages according to TLS
> > 1.3" -- it would be right in the spec that your implementation needs to
> > have the capability to do so!  
> 
> Agreed.
> 
> > Yes, we could come up with some explanation about local policy clamping the implementation's capabilities, but it seems like it would be simpler to use a slightly different wording here, like
> > “if the entity is configured to enable exchanging messages according to TLS
> > 1.3" that does not set up an apparent conflict between "capable" and
> > "implements”.
> 
> That text edit would work for me.  
> 
> Effectively those edits would mean that all TCPCL implementations would need to implement TLS (which implementation really is easy since OpenSSL exists and could be used) but that local configuration might mean TCPCL is not in use for some TCPCL sessions.

Agreed.

> As an aside, many commercial vendors use OpenSSL as the basis for their TLS implementations, in part because OpenSSL already has a FIPS-140 approval from US NIST.  This makes compliance with both US and non-US buyer requirements easier for vendors.  FIPS-140 is commonly required by non-US financial institutions and a range of countries other than the US, so it is not really a US-specific sales/acquisition issue.

Stepping aside even further, for my day job I work on OpenSSL, and the
existing FIPS-140 certificate is for a module that only works with an
OpenSSL version that is no longer officially supported.  We (mostly not me
personally) are making a bit push to get a new one along with the 3.0 major
release (currently in alpha), and the people doing most of the work are in
Australia, the UK, and Sweden -- not the US!

-Ben