Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Magnus Westerlund <> Tue, 01 October 2019 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 058AC12006E; Tue, 1 Oct 2019 13:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9PPq0Ca_oWbW; Tue, 1 Oct 2019 13:15:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04F3B120043; Tue, 1 Oct 2019 13:15:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=QdLgOtyJSUVSUOQpoBG2dDTsXg+grc6gAnm1yvjfm3HIAc35DoFDMAVvVbgXjlh0BtQz7adXrOToPtP9B2eAbClv2soFj0ykhjHT1UGFvyBKKwb19izUahtdqeb4KCbiw9sVeO4tRQ7da2nRh1wcrOMnW7Ug9bvX+dbnxr7J7V43k97Bh3P2lqmqfIfWA/EnfzDCgFrN/tWA6zm8ImmNgGphuigmLmp3nUmzWH1/VoXtmS4if22YKxs5NRIS5veR1eUHRV2npOsIWJQoPtOkstmCFTY/i/j+jcoErpe7WcIc7hhRtdxi7TQgPmfVIJnWg3XGIT6+dSwyzXyK8iVzDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+o9MykQon5bQ1fB8/fmcb21V/X2pYmWsI2NpF1+0nTw=; b=Od+iTTHKZWf0k8HKqPfaH+fd/0HMRQkalebw9npI4khy7YYAfefNURLQhYmUTIgBRJHje4zWYXow12+RXFIVXzAP5dz8VsSDRwYivyavYQl9Y808BjYN4PGdVIjgLWeUlIc4PDtaJ84tqnlfwYNvmjWl2Ha9kpnkpoOkV6zfDIkxgVMI8l5hcBT64GH2hMabLjk+xLhaE1qS+OWgn9qKkWZ7yqM4/Jn4MLrLMB4saQGzpixpdv4wzXG9ji4dT2VpS8/YJACBPV4eG+CqB9xvIRPT/m2GkKQ3sUCLHm0cO5BEPZCmeL24igeIrBeqZmO+vniLr9QDqXSAYzs8EVn5uw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+o9MykQon5bQ1fB8/fmcb21V/X2pYmWsI2NpF1+0nTw=; b=c+MqTDVWnccjHYnAAY2coLKhPUrXTtFc3EGdoZaN44t/8Jyo4082XGh4OOlLrW0TrVesbZy2F6XQ4tQ0+BV6tsmVnX0y9jHUYwFUeXooM5Ac9cEY3eThQKL6T8YQZR2LxZZLe7U+rK0k3GASzp6hscUFyVq0rk/3WY4fxFwm8Ow=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Tue, 1 Oct 2019 20:15:05 +0000
Received: from ([fe80::e48c:a942:9682:2ce4]) by ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 20:15:05 +0000
From: Magnus Westerlund <>
To: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVeFbgHKOa78ZpIk6t5wl2zEE/badGMzKg
Date: Tue, 1 Oct 2019 20:15:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa7f6059-c90a-4d4a-eb18-08d746ac0ca5
x-ms-traffictypediagnostic: DB7PR07MB4903:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0177904E6B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(376002)(39860400002)(136003)(366004)(199004)(189003)(66446008)(64756008)(66556008)(66476007)(66616009)(7736002)(316002)(86362001)(66946007)(74316002)(81156014)(110136005)(81166006)(8676002)(33656002)(2501003)(66066001)(8936002)(99286004)(7696005)(25786009)(476003)(99936001)(71190400001)(256004)(6246003)(53546011)(229853002)(102836004)(486006)(6306002)(9686003)(44832011)(14454004)(71200400001)(186003)(6506007)(26005)(11346002)(5660300002)(236005)(76116006)(52536014)(76176011)(790700001)(14444005)(2906002)(55016002)(6436002)(54896002)(3846002)(6116002)(478600001)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4903;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IDJIQhjCsoGwVp/dUTGAJX541wy9j7cRUykYsFIzpH6qGdSwl6l0jfc6LlFC0fJYtkH06yCMcabdMnuEjkRobiPHcX0s+t0PLrC7jUyBgpcWptoG1aPz+aB25BpsvoUz2z/Www59JAWhMMhgy+seGKQSG6gcAsutfER4kkEVanGYg36ULgsmwhip/PbqnlLkVhoJ+hAVIkzi1cqcM7ZfzPRPEL8SUnwWQAYZNX0+KyHSrg9C7pTUz55VqJ7uOl7P/pw6tNTl/zC3AaYfX5yz+dOnIRoIjenfFYzuLF3BsjjYjKM9x6S2dflj/UNu0vCbAa08EIPT/PzEhERIL60o8jbKvRyaftpw7DOdGlGXShKzbT0+hDISRqxXd9wBJYnBrs6NIsIiU9GzcCQllKi0JeV8Z+yMuGM2J7PKw64pG5s=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_009F_01D578A5.ACACCB40"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fa7f6059-c90a-4d4a-eb18-08d746ac0ca5
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 20:15:05.4815 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LlF7jhhm5JhirhIClvoTcOVdOGBoMAlyJTGYK8ecBYdXpNqFUnk6oub19r770JU+PTaLCnDSeXLiCzEDCwrhjgOI2q+q+goTysGBgv3szwg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4903
Archived-At: <>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
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: Tue, 01 Oct 2019 20:15:12 -0000

Hi Brian, 


I think we are getting very close to what the text here needs to say. What I
think is missing is being explicit that the peer acting as TLS client if it
includes the SNI, it needs to include the hostname related to the Node ID.
Being clear that it will be up to the deployments and their addressing and
naming schemes to make this relation explicit if it exist. 


The TLS authentication part already have the same implication when it comes
to hostnames and Node IDs so I don't see that you get rid of any potential
pitfalls here regarding the hostname and Node ID relationship, that is
anyway present. 


Maybe the way of resolving this is simple to add a paragraph earlier in the
draft to discuss the hostname to Node ID relationship that likely exists in
a deployment utilizing this CL. 




Magnus Westerlund




From: Brian Sipos <> 
Sent: den 1 oktober 2019 15:53
To: Magnus Westerlund <>om>;;;
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12



You are correct that the SNI is only meaningful when an actual host name
(likely resolved via DNS) is used to establish the TCP connection. For stand
alone one-BP-agent--one-TCPCL-entity--one-host-name uses, the SNI will serve
no purpose. I expect that the more typical case is where each TCPCL entity
has only one X.509 certificate which authenticates a single Node ID (and
possibly, but not necessarily, a stable host name or IP address).


The SNI use is to handle what I would consider to be more rare circumstances
where one TCPCL entity is used with multiple DNS names in a "virtual host"
kind of situation. Or where PKI policy disallows multi-name or wildcard
certificates but the TCPCL entity might be accessed via multiple address or
multiple host names, and so has to present a different certificate depending
on how it was addressed by the TLS client.


The reason why I included it in the spec is that many TLS-using libraries
(including the two I used for my own implementation) send an SNI anyway and
there is no harm in providing an SNI that the passive peer (server) ignores.
If this all seems like too much of a specialized use case then I'd rather
remove then SNI language and leave it up to the network administrators to
work out situations like this. I'm sure that there are many more odd
situations caused by PKI or network policy decisions.



From: Magnus Westerlund
Sent: Monday, September 30, 2019 05:23
To: <> ;
<> ; <> ;
Brian Sipos
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12 


Hi Brian,

On Fri, 2019-09-27 at 18:23 +0000, Brian Sipos wrote:
> Magnus,
> From your earlier message regarding BCP 195, that is excellent news that
> change is needed.
> Regarding SNI, your expectation is correct and the current phrasing is not
> explicit enough. Where it says:
> > The SNI SHALL contain the same host name used to
> > establish the TCP connection.
> it should more accurately say:
> > The SNI SHALL contain the host name of the passive node 
> > which was used to establish the TCP connection.

I think this formulation is a bit strange. The host name may first of all
have been used to establish the TCP connection, that assumes a DNS or
name lookup schemem to find the peer. Secondly, I think it needs to more
say that you include the host name that are associated with the intended
identity. This both for TLS server certificate selection, but also traffic
routing to the correct bundle protocol level entity. 

There exists to me a chain here that looks like this:

host name -> TLS Server Identity -> a set of Node IDs


Magnus Westerlund 

Network Architecture & Protocols, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: