Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Roman Danyliw <rdd@cert.org> Fri, 03 September 2021 14:13 UTC

Return-Path: <rdd@cert.org>
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 68A613A1FEA for <dtn@ietfa.amsl.com>; Fri, 3 Sep 2021 07:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.com
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 Da9KAEOg82OZ for <dtn@ietfa.amsl.com>; Fri, 3 Sep 2021 07:13:13 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0139.outbound.protection.office365.us [23.103.208.139]) (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 51DBE3A1FE7 for <dtn@ietf.org>; Fri, 3 Sep 2021 07:13:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=cEwBmJx260RpfMMQ/0HAPyGeoWEySi+k0/4N8VMGLaeskIeNhGZ5A1iPENwR/cT4lvb+Cb0inXifwC4/9IPeZ3+Im9EEPP07xYMnic9PpIat8OuNHH1tftQ0hB0COYkRTRUGWBLgXhjMXwLLIRp6CgRuJzuZBd4qgkEGzFhMWYX+l4hBGZxzsV6ItKdXbRSiYSD4ad7Pb1TgebvkwGjkzzMG5UfEi3pdEGlig4+Od6cRXV0sOygp6gURDAdnMvmo0WjwfmQuX81HHBFtfMzSIP3wsCpUFd0NIZPns8nH+YVip/MRG40sto8hBxO7/6p528278Z3EReagGmGzwQeYfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Co5ANO2OOr4Vy2fLBYPa5xuarJW4x8JWxhRkLz6AbwM=; b=vcttWloPBnB5yNnavn+oZB0YrHnI8uRLEuAx8q3W3nn4szDWKsAFgI7zzza7Rcaan8VcWsRZ1SZg+9eZFZ8iJ2l4u4w1b249rnaIPGHF7FRA8fDGmCXqQway4DUw+Mc6n2/WLgeCYSHcGZcNInU4xY0Cbr6YgJumYEOBtE5CuRXxEH9KIATEXHNEUTWXvQ6feVgWK3p18QlYH8P/hOII2QHnwA59g7fw2qQwmPcFn/eVUcT+Zr5Nv7x6bLh/RCkmip/mSlFFirW7aHKhpb792EkOol/fzuUx4PCJyT24pM8FA54tPWueG3U3Jgm0w1dBvgs0MMOY2CAA+gK7EWMhoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Co5ANO2OOr4Vy2fLBYPa5xuarJW4x8JWxhRkLz6AbwM=; b=NgPioTXLgyUpfOyGGs92KtdTh9BmUo0n0jnC4zAald6cjfnLwgDvNQWzQx3gassxMzeEu7hIwHuBLIb2RjZzoUCajhChuDZ25wdwdnYTpmbwB3TmMZvRlLcBl5Y4geIj+eALmq9mhLRvP1JlD+tH+0pElyq7ADq9u+rzI6cKIEo=
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:134::12) by BN1P110MB0577.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:135::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Fri, 3 Sep 2021 14:13:09 +0000
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650%5]) with mapi id 15.20.4478.022; Fri, 3 Sep 2021 14:13:09 +0000
From: Roman Danyliw <rdd@cert.org>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft
Thread-Index: Adegxqku/cncZNW+RCm6mw0bRz/vhg==
Date: Fri, 03 Sep 2021 14:13:09 +0000
Message-ID: <BN1P110MB093974F5B749DB68A304FBD2DCCF9@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bbaaa2c9-def3-418d-42b9-08d96ee4f548
x-ms-traffictypediagnostic: BN1P110MB0577:
x-microsoft-antispam-prvs: <BN1P110MB05770B25C94F012907641BF3DCCF9@BN1P110MB0577.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: n50uxuH1xeNf2aL+pGjMDpY/Rn9ABvMHGO5TNumbHga2ZAzqsq2QHWjuvS6Qb5LVsolDMxdFX5LKrFmAP5rCruwTre7C1uiM8IDswu/sr6sPzP2iWtX2enkojSaidV3b/iAWBlhqxi2l6ZWtpbpltiSLxeBz07jVMlUp3jKSZPp4fanETGihk6kFQ7QkaPdIVXDWP8SIi7lSj4E7V5JQmT12ezY56fKfvvwEBsKPLcMnK09pIKCmmDQnikOQgHOevawn37KIRQBjDGF8DgG6BSTT/XE3TgJYbWCrY8tYZQOsLAC7VLK5+Yb5rDt8/dts34/n5t+3P0vMUUfFboi/evcy7AFXDN/R7RUvILnUJh5kfRDJnsGmuE0krvWJz4ZLy+pID4Y3h0JUy71mU1/jjNfGsVa6+/IZgNr6GGEoo5/uzDsD4RZJlvCI2yMcF2yUY18EfhQLr6bjBSIvNVzyBFjlkGhk+34wnu3RqES7WI3Iiaj6JfxCluG/Yh1pBJ/LNtZoR/3gmZIB330ihFgztHCgJDo1K/GHQy6W72v54DvYgwNYk9ra91YPguFIWg8y2WHm/EQRkXs8KfubBQBXJvhDKA//z17jeufQGajPfozTswGaK/UI9KxyiPiLX4th/FmL6BYh8zJXhR8U6uwvuuXMuj/SteXGFEafqZd7hGGujGMUd0shy9xosGX/1RIvquE00MCFmOq5kiaYXE52qw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(966005)(122000001)(66574015)(7696005)(9686003)(83380400001)(52536014)(30864003)(38100700002)(498600001)(55016002)(33656002)(86362001)(66946007)(66446008)(64756008)(38070700005)(66476007)(53546011)(6506007)(186003)(5660300002)(26005)(8676002)(76116006)(6916009)(2906002)(8936002)(66556008)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: cFs21xOfFV6XFMO9iIDFje6hAF2tubDZIAvzuaEetWkB9RkA3WFc3cyVAVg3nbIveLx0h20qO4lL19Uk9JtLoDOZAEon3dkjm9P1Gl0sOcoLQOr7mIsXJYUiXlmPTVoukHOA6AUULM5w/axyVZO/475PMLIBvc30NedD1U+y2fuNTSJqMEHUsR363FuDQ9kusrn3AfbZLQ8y1lwQPgV4tQwHOHw60AZoxrvIh2VxCw7wGhAJdz200FUL2x8pDyfRN8bNrZHNDSMQTHpLCA7pRR00VkDntRMdJM1oWAm658qJyMwCo8AvAGTz1jvhxGRbp42LObTUXM9uR7ju7E4ZHrf7W8gskNNNEAtHjT+9D5DvG8Rtxhw4e/GPupY+zbjlTXWAkngg6stv8qrIUBheTA8QCEHD3/eMrCYtrGh9mypHoiCHE5L586/B7wPqJ21tN74RwyRbp0xnoaliK3TP+hZ6r1AOEQ56nYC+yIx3J1j7lK2RmOZUsI7l3E1a/mLYZzc2BQdf8iuPKdI9jiyainAeDjgW3XbQI1ufckfPocup8nO90bTnShuz0SV+LnzI2w2yGuDYI/G4y4tXcbmFbKTWwo6CIUS+O6wu0Vm+jQNxzgWRl0kayWDNA1MYo79L5+zorgFSRcS1ixzWP+AZizSYtSsQmi1SpBDctM4htTi6O+BVpdOuv9v6gcsSCgXmkFlIT8Y5SmGcXUlDiGLBBA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bbaaa2c9-def3-418d-42b9-08d96ee4f548
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2021 14:13:09.4699 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0577
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/C-f5NstIb5vzLg12RhBV6rwVFXw>
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft
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: Fri, 03 Sep 2021 14:13:19 -0000

Hi Brian!

On Wed, 01 September 2021 14:08 Brian Sipos <brian.sipos+ietf@gmail.com> wrote:

> All,
> I have a drafted (but not submitted to the datatracker) redline [1] to
> TCPCLv4 for the NODE-ID encoding changes discussed earlier. It adds one new
> IANA Considerations subsection for the otherName type and updates the one
> paragraph that uses that new type. This can be wordsmithed if anything
> seems vague or under-specified; specifically, there's no text explaining
> the nuance of "it can encode any Endpoint ID but for this PKIX profile it
> must contain only a Node ID". Something similar could be added if helpful.

Thanks for staging this diff.  The explicit mapping of NODE-ID to otherName seems like a good alternative, and it can be cascaded in the related ACME draft.

At the risk of re-opening some of the unrelated text, but in the spirit of being extremely explicit on how NODE-ID (Node ID), DNS-ID (DNS Name) and IPADDR-ID (Network Address) are expected to map into certificates in DTN, I noticed that the text in Section 4.4.1 only provide guidance on NODE-ID and IPADDR-ID.  The obvious is never said about DNS-ID.  Specifically:

NEW TEXT (to be symmetric with IPDADDR-ID)

   This specification defines a DNS-ID of a certificate as being the
   subjectAltName entry of type dNSName whose value is encoded
   according to [RFC5280].

Regards,
Roman

> [1]
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-dtn-tcpclv4-26.txt&url2=https://briansipos.github.io/dtn-bpbis-tcpcl/draft-ietf-dtn-tcpclv4.txt
>
>
>
> On Fri, Aug 27, 2021 at 5:55 PM Birrane, Edward J. <
> Edward.Birrane@jhuapl.edu> wrote:
>
> Rick,
>
>
>
>   Upon review, I agree with your (and Brian's) statement that NODE ID
> should be preserved but not as a URL.
>
>
>
> DTNWG,
>
>
>
>   This document (
> https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4) is
> currently in the RFC editor "EDIT" state. There will be an update to the
> document as part of responding to editor comments to produce a final
> version of the RFC. This update as part of the editor process can be used
> to correct errors in the document as they are identified.
>
>
>
>   The question, of course, is whether the proposed correction to TCPCLv4
> (for NODE ID use an otherName with a new OID for Endpoint ID) is a
> sufficient technical change to warrant restarting DTNWG technical review or
> whether this is a correction that can take place as part of the existing
> editing process.
>
>
>
>   To that end, if you have a concern that this change requires more DTNWG
> technical review, please say so on this list.
>
>
>
>   Alternatively, if you believe that this change should proceed with other
> corrections in the edit process, please post that as well.
>
>
>
> -Ed
>
>
>
> ---
> Edward J. Birrane, III, Ph.D. (he/him/his)
>
> Embedded Applications Group Supervisor
>
> Space Exploration Sector
>
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
>
>
>
> *From:* Rick Taylor <rick@tropicalstormsoftware.com>
> *Sent:* Wednesday, August 25, 2021 4:07 AM
> *To:* Brian Sipos <brian.sipos+ietf@gmail.com>
> *Cc:* Birrane, Edward J. <Edward.Birrane@jhuapl.edu>du>; R. Atkinson <
> rja.lists@gmail.com>gt;; Brian Sipos <BSipos@rkf-eng.com>om>; dtn@ietf.org
> *Subject:* RE: [dtn] [EXT] Re: Important side issues from ACME Node ID
> Validation draft
>
>
>
> *APL external email warning: *Verify sender rick@tropicalstormsoftware.com
> before clicking links or attachments
>
>
>
> Hi Brian,
>
>
>
> From my reading of BPv7, a Node-ID is just an Endpoint ID with a special
> meaning (it's the EID of the node itself, rather than another service on
> the node, or a multicast endpoint), so I suggest having the "otherName" OID
> registered as "DTN Endpoint ID" type.
>
>
>
> There may be advantage to that flexibility beyond TCPCL, I can imagine
> use-cases where services may need to assert an identity just as a node does
> for TCPCL, and the generic "otherName" is the right tool for that job as
> well.
>
>
>
> Cheers,
>
>
>
> Rick
>
>
>
>
>
> *From:* Brian Sipos [mailto:brian.sipos+ietf@gmail.com
> <brian.sipos+ietf@gmail.com>]
> *Sent:* 24 August 2021 21:35
> *To:* Rick Taylor
> *Cc:* Birrane, Edward J.; R. Atkinson; Brian Sipos; dtn@ietf.org
> *Subject:* Re: [dtn] [EXT] Re: Important side issues from ACME Node ID
> Validation draft
>
>
>
> One remaining technical decision about this is: does the SAN otherName
> allow only Node ID values or any Endpoint ID values. This certificate
> profile will only have a use for Node ID, but this restriction is related
> to the SAN otherName type definition and not how that type is used by the
> profile. From the tool perspective, it seems a little easier to allow the
> type to contain any EID. A non-Node-ID value won't match any CL peer Node
> ID so there's no harm in the otherName value being an EID.
>
>
>
> On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <brian.sipos@gmail.com> wrote:
>
> Ed and Rick,
>
> The fundamental issue is that tools can and do make assumptions beyond the
> already incompatible requirement from RFC 5280 that a SAN URI have an
> internet name (DNS FQDN or IP address), and there are some pre-existing
> issues anyway with tools using SAN URI and PKIX certificate constraints.
> The SAN extension is the right place to put it, but the "
> uniformResourceIdentifier" type . Like some other aspects of IETF
> protocols, where PKIX uses generic "URI" or similar terms what they really
> mean (and what tools/libraries can assume) "internet name URI."
>
>
>
> The change is to redefine what is a NODE-ID (it changes from a SAN URI to
> a SAN otherName with a newly allocated type OID to specifically contain a
> DTN EID value). This will require no change or conflict with RFC 5280 or
> existing PKIX tooling or libraries. It will decouple the NODE-ID definition
> from any earlier/other use of SAN URI. I can draft a modified TCPCL
> document for these changes.
>
>
>
> Rick, you are correct that the current definitions can be used in some
> circumstances (the proof-of-concept implementation works fine with Node IDs
> such as "dtn://node-A/") can run into problems when node names fall outside
> of allowed DNS names (e.g. "dtn://_node_A/" or other disallowed DNS name
> characters "dtn://_&@/") tools can rightfully refuse to either issue or
> accept certificates with these SAN URIs.
>
>
>
> On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <
> rick@tropicalstormsoftware.com> wrote:
>
> Hi Brian, Ed,
>
> I personally agree with the ACME Sec review...  I think subjectAltName is
> the wrong field to be using for Node-ID in the certificate, and using it
> definitely ties our hands with Naming and Addressing to only use Node-IDs
> (and by extension Endpoint IDs) that map to RFC3986 valid formats.
>
> @Brian,  Can you suggest some replacement text for the 3rd paragraph of
> 4.4.1 that meet the ACME suggestion?
>
> Everyone else, do you consider the change to use a different field/type in
> the certificate to be a change that requires returning TCPCLv4 to the WG.
> Note that doing this will delay BPv7 and BPSec as they are all bound
> together.
>
> With my chair hat on, I would suggest that the current text specifies the
> wrong field to use, rather than specifying something functionally incorrect.
>
> Cheers,
>
> Rick
>
>
> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Birrane, Edward J.
> Sent: 23 August 2021 17:12
> To: Brian Sipos; R. Atkinson
> Cc: Brian Sipos; dtn@ietf.org
> Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID
> Validation draft
>
> Brian,
>
>   If I am reading the TCPCLv4 document correctly (
> https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26) then the
> NODE-ID is optional, and instead a DNS-ID/IPADDR-ID may be used.
>
>   If the bundle EID scheme (there may be more than dtn://) does not map
> cleanly to a fully qualified domain name or IP address, my intuition is
> that the DNS-ID/IPADDR-ID construct would need to be used instead.
>
>   Since this is a TCP convergence layer, we already need to map a domain
> name or an IP Address anyway.
>
>   If that is the correct interpretation, it may be useful to strengthen
> the wording in the draft, but I don't think we need a technical change.
>
>   Am I missing something here?
>
> -Ed
>
> ---
> Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group
> Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
>
> From: dtn <dtn-bounces@ietf.org> On Behalf Of Brian Sipos
> Sent: Friday, August 20, 2021 3:36 PM
> To: R. Atkinson <rja.lists@gmail.com>
> Cc: Brian Sipos <BSipos@rkf-eng.com>om>; dtn@ietf.org
> Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID
> Validation draft
>
> APL external email warning: Verify sender dtn-bounces@ietf.org before
> clicking links or attachments
>
> All,
> After further discussion in the ACME WG (security area), based on a need
> to avoid the requirements on DNS-name/IP-address and to avoid both valid
> and invalid assumptions made by tools/libraries about SAN URI contents, the
> strong recommendation is to avoid the SAN uniformResourceIdentifier
> entirely in favor of a new SAN otherName type-id OID which is used just for
> DTN EID (and thus Node ID) claims.
>
> Unfortunately, this would require editing of a portion of the TCPCLv4
> draft now in the RFC editors queue, and a new IANA registration for the OID
> under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [6].
> Is this late edit an acceptable path for the document?
> It would avoid many potential interoperability issues that were brought up
> in the ACME discussion and require only slight change to a DTN
> implementation to use a different SAN type (but identically encoded value).
>
> [6]
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8
>
> On Wed, Aug 11, 2021 at 11:20 AM R. Atkinson <rja.lists@gmail.com> wrote:
>
>
> > On Jul 26, 2021, at 21:04, Brian Sipos <BSipos@rkf-eng.com> wrote:
> >
> > The second issue is unfortunately more technical; the "dtn" URI scheme
> has been set in stone and is already in use, but the PKIX profile in [4]
> specifically requires that when any SAN URI which includes an authority
> part (the "dtn" scheme does, it is the node name) that authority is either
> a DNS name or IP address. And we know that a Node ID is _not_ going to
> contain a network-level name but some other name. This technically breaks
> the profile in [5] as well as [2], which both use SAN URI as Node ID
> authentication. Because neither RFC5280 nor RFC6125 require to dereference
> the SAN URI and the DTN PKIX profiles explicitly avoid the URI-ID
> definition of RFC6125, the only risk is really that some application may
> inadvertently try to DNS probe the node name (or something like that). I
> don't yet know how much of a blocking issue this will be, and it's
> unfortunate that it wasn't noticed earlier.
>
> Brian,
>
> DNS Operations folks consider "noise" DNS queries (such as an application
> trying to use DNS to resolve the node name or something similar) to be a
> significant operational challenge - because the volume of "noise" DNS
> queries already is high.
>
> I imagine the DNS Operations folks would be greatly unhappy at the
> prospect of the DTN URI scheme being the cause of additional "noise" DNS
> queries.
>
> A prospective change would be to update the PKIX profile in [4] to make
> clear that a dtn URI is neither a DNS name nor an IP address - ever.
>
> In short, this looks like a real-world operational problem that will need
> _some_ form of solution, even if different from the prospective change I
> outlined just above.
>
> Yours,
>
> Ran
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>
>