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

"R. Atkinson" <> Thu, 19 November 2020 03:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 105813A07DE for <>; Wed, 18 Nov 2020 19:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 0TiQ6dgQNL0O for <>; Wed, 18 Nov 2020 19:38:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C855E3A07DB for <>; Wed, 18 Nov 2020 19:38:59 -0800 (PST)
Received: by with SMTP id f93so3400885qtb.10 for <>; Wed, 18 Nov 2020 19:38:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J+/zIyStnWvIYkUO4GQJ/inuFbs5DdkK78di45RW6pM=; b=ussB+lgyLEpn9K8OxuP/JcufBz67cb4vhcV4meiicGO6TqJMZFNkXCzEap8yrfUNvO VAh/cwCm/JU/XG3OuCC1ve2U6vSJS7ZAYJBmLjQap2b1gI+gjsm9zFICt3ifaVv/RhLC M0uCIy0usGt+X3waAICSSczLGGUkUzXILFbJjuNxRBSSdrO3xj7lu/LshJf2FtT29mxr 5OEfISlL1z/QxREVR7mLCPLaRhNITbZfD+RNWPeJWsfZaWouwbEpjVsilOsDxKTsMRVe 5OBtfkL/xvnEPzbNAhP8AoIUfi+98p6LReC8XVfGifWevhfPD4RtaBLHhFTLCRBD0Eub uThA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J+/zIyStnWvIYkUO4GQJ/inuFbs5DdkK78di45RW6pM=; b=bvy/vZFup4x08plJIoEIyKIREuc2nFqEy2p1O50glYnWeE7vgZ6wVfZPD+9n8r4F6i nDXXW/ax/0Ac6QdUrjROSDojpLzeIIEuHJVPFzOqIIqotBjgEAGeE8Tn4hWOtNDsek9t NEyP4okhvWqy0Jz/6PvskBTHzsQ37e7ZVqYBIN0KAe4deH68Uq3cUN9h52hnOIxoBtBg EN8Bdzg9Hq95dHOoUq40QIgGO5+og+pPoglF9iSBrFVqBaubtNNyzxltqE5Z5SaoIdts ZmosyM3CNVYsp/hqi8zPi2VgSH/4Eqxg5fs67PQ3xJPpy14AzWjSS+DZhHYSuS8MGBx7 acow==
X-Gm-Message-State: AOAM5316tZ5nDasY0K2uyp3LSgMUEvZMP32izEazYwEhvc6+M45Whxjh IEqQZrpyQH4gHWJIjq8gzrrh+AdzoKI=
X-Google-Smtp-Source: ABdhPJytp/Jhp3hLD1vmuGt1e9crxm2TVoCCcZ62QFssUsCsTMsdcmDUQ7Rc59OrA0/KVcr6FDIOVA==
X-Received: by 2002:ac8:221b:: with SMTP id o27mr8340902qto.54.1605757138993; Wed, 18 Nov 2020 19:38:58 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id m2sm17484694qtu.62.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 19:38:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: "R. Atkinson" <>
In-Reply-To: <>
Date: Wed, 18 Nov 2020 22:38:57 -0500
Cc: DTN WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2020 03:39:02 -0000

> On Nov 16, 2020, at 20:10, Benjamin Kaduk <> 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),


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 ?)

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


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

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.