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

Brian Sipos <> Tue, 01 October 2019 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AD12120800; Tue, 1 Oct 2019 06:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cu7sDTREBBGC; Tue, 1 Oct 2019 06:53:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08252120828; Tue, 1 Oct 2019 06:53:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=ILxDITji7a9F28XHbS5tQmE+M9C85BMWoxrb4PFABq44zbZH18lFWvBFBxVK/g70xQ7JnQFdasJfO6YfN51nKl7TEPnsg0vXMfbnlcjbqaavOOmlXnW8RACLuygc3wv7OJKg4oTi9Gk+9vwZ6+9TRQ4tjjyjVeVvcNX9VyXk1E/MJhjvcTZUpPrc96vI4QZ3RrawFzqgOYQMCp0pwh+sRE2hYczwI8qpnamCTANKlScwwGGcbfaTxHQ73bZDjVOkD19OAz2LBP231S5G+SDfZ9Y7p9arN0eA/M3PyAyHzytSs1ZdMSgpWrG0MOVBs2PkvznE0p+6F2Ee/eX5SemmMQ==
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=wlS3c584Sa5nlOtxqQt3ZK9cIByg+9mhEsp/x9XPzys=; b=PgJ0MyGJDTKOuRPrxRlflUiIPSb409HCCFocVxM2nbDsK2/Hm3NPLnyCKzwWOkNWSG3T/KsTig3jc9puEyhMMmsFM44Qo57h7R2xTrrn4iuQV8KblGYSa/4uwJrNrNpFy/ePLRQ0zNxsXBByegkZXX13FE/vJfk2Z8DGzrifKGNwSOqqNCCmPBlSf4hk8pbKou5K0mbkd7NGHcmDr9q5pNW6p0uPKVhvwD0DQiMisE0qCcq5JcSGJWdn4cZwUcuCwXbAT+/s02QFgzWDtrqEWsF/ndtQy00IzYoYF537ydqKq6aKdxZ8394uwbxgAkeN082tyZ7Sx3/kv93Z0qmbDg==
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-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wlS3c584Sa5nlOtxqQt3ZK9cIByg+9mhEsp/x9XPzys=; b=ml5LUx99t0Ll9v5qhynoxQtC6AM2qey17By3UR0bQFFcE5MMgraftvENjJDT0NnKOeU3iDqfWNUMO8UhvE1raiYP3cXY1ty16cC3cRw8TJE1xTnKHkVlwuV7hcCsiSYaoUChFKxESA1z3zn4wzWwM67WRuB3I+VXUlq4c8KQbF4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Tue, 1 Oct 2019 13:53:10 +0000
Received: from ([fe80::d1fb:dec5:245c:aef5]) by ([fe80::d1fb:dec5:245c:aef5%7]) with mapi id 15.20.2305.022; Tue, 1 Oct 2019 13:53:10 +0000
From: Brian Sipos <>
To: Magnus Westerlund <>, "" <>, "" <>, "" <>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVeFbgHKOa78ZpIk6t5wl2zEE/bQ==
Date: Tue, 1 Oct 2019 13:53:10 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d165c7af-6913-4ffe-ddae-08d74676b228
x-ms-traffictypediagnostic: BN8PR13MB2817:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0177904E6B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(366004)(39830400003)(136003)(199004)(189003)(7736002)(7696005)(2906002)(26005)(8676002)(74316002)(19627405001)(66556008)(6506007)(81156014)(80792005)(99286004)(64756008)(102836004)(66446008)(105004)(55016002)(54896002)(86362001)(9686003)(66946007)(53546011)(81166006)(76116006)(66476007)(6116002)(3846002)(71200400001)(71190400001)(52536014)(8936002)(6436002)(2501003)(508600001)(25786009)(5660300002)(256004)(229853002)(66066001)(316002)(476003)(14454004)(186003)(6246003)(33656002)(486006)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR13MB2817;; 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: lfPwdA7QBR4YEqpxop61IKTllCNdYDJHf0aJV89sAiE3jRRmd8cokzGT//UqLA8r/z1H9A/vvni1ryW6pOGElUA473AlOvPvcDwIlcThw1ndWM7SGvlqLIGiE7/UkLfTRsBKyycGX2MfB2fhIoer6uPwmymZSfSIdkZrkCNE0UBoGCK8lNgOvuyfuumMiFtgDdK1F81TdBbS5EfaWrs+QbZIHKj45KgJxVYptwXH6ucYKt8nCpdCV9135wsYWIrnkBPNWSItsd1efsm8UNrYQJ8tBbfNaVgzPb6hDIoNA7rjXTzHMV4Qk7vkcMaqXosG0UwLJ0dUR5Y+uXTp6vtaTYADyeL+XMY2SchWD7NzFghh/r2saBxmWXWsvygdawzHnQvkpjZqcsfMeNuS1tY5HDJx77TiYtng9s+5e55sLwE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR13MB2611EBEC6AD53B306914DC7F9F9D0BN8PR13MB2611namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d165c7af-6913-4ffe-ddae-08d74676b228
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 13:53:10.3253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4eSa6/0rnp4IHubTYfrSPhpJFn1EJjRNkrW+90a0RydtN0vCRgShQJ4h2NXV55DUSAunmCaYFkwTeo9P2OsxOA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR13MB2817
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 13:53:28 -0000

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 no
> 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 never
have been used to establish the TCP connection, that assumes a DNS or similar
name lookup schemem to find the peer. Secondly, I think it needs to more direct
say that you include the host name that are associated with the intended peer's
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: