Re: [Tm-rid] DRIP, EPP, RDAP, and the DNS

"Card, Stu" <stu.card@axenterprize.com> Fri, 10 April 2020 16:01 UTC

Return-Path: <stu.card@axenterprize.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B13A03FE for <tm-rid@ietfa.amsl.com>; Fri, 10 Apr 2020 09:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=axenterprize.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 2KY2LuRzKq6f for <tm-rid@ietfa.amsl.com>; Fri, 10 Apr 2020 09:01:47 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507643A03F4 for <tm-rid@ietf.org>; Fri, 10 Apr 2020 09:01:47 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id n188so859824ybc.3 for <tm-rid@ietf.org>; Fri, 10 Apr 2020 09:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6hJPH9ETJ+5LO3pJmOZXECUR8LD5H3EjiUTC8L4aaSA=; b=lTo3vXhJmnN7NX9kAJoEtsL2PevN+vtWsKF724/+uN6MCozpVHuWh7Oi4eBoYUhxGk eT3xJ81WRVC5SxGQM1NdBqkJpW9ivXzEFfdhwdsEodJFJfU6Gk627JTV4Bx06qNnCh6X T6WL1/VUQT2I/6wZ1im2EGcXHKRb8MGRaAStA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6hJPH9ETJ+5LO3pJmOZXECUR8LD5H3EjiUTC8L4aaSA=; b=mAJAyhUhCwB5MJiuh1CThd3wOomNTq3jD1NBQaO8ZJs9vVUFbLF2/yxFrDMtZo2qiX +pm3HDLYsZfWn1W1ilA+lsSvEbJrRR2V/J9GPEYbp3Ba21rfUeTHR9vn0mHVkfwyOApR YpsDzunA2inC4CoYcsVdArN5mTu2SQpsGFGff+sSI6uM4Tu4gQeEM1XmZYX6Tfzj3MM6 5ngRM8Qq9dMsms37hADTgexr8MrpnVa2G64mGymSdRLUrJhkfFD3US9sKonHoFanOtPf drUhYPllecgjBqDQu7OJK0iJvyeBvSGqAWwhZoAmBG7AF9wVPLctMOB3l+lCT+6c1clD xIGA==
X-Gm-Message-State: AGi0PuZ3bAt6AVPAQIHYGAkwcAlzIN8PCmkBI4nZFxOzJEh1eDPylfTI t7Tl3EMiXLQVkVVNuVVaPlhHccuNN9lQLNn/tsNPY5Ke
X-Google-Smtp-Source: APiQypImWmuYsfI/F4IPJm0ec9R/q6jJrdkNrOUaqwEFdFILcqrbZ3g3+w4xx4sbYltl2T3UEz8H4KTF3VYD/NDYyT0=
X-Received: by 2002:a25:d28e:: with SMTP id j136mr8030546ybg.463.1586534505949; Fri, 10 Apr 2020 09:01:45 -0700 (PDT)
MIME-Version: 1.0
References: <0a2945d803314dd9b2bc786ed1075044@verisign.com> <efedc170-45d3-9e5e-406d-e01623b384c6@labs.htt-consult.com> <e2fbdc0bedd746d8990ebf1ed831899c@verisign.com>
In-Reply-To: <e2fbdc0bedd746d8990ebf1ed831899c@verisign.com>
From: "Card, Stu" <stu.card@axenterprize.com>
Date: Fri, 10 Apr 2020 12:01:33 -0400
Message-ID: <CAKM0pYOXWLmUkmKNN0nkEcJ+MvSpHDUr8uErAXzOUQVYCTBptQ@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: Robert Moskowitz <rgm@labs.htt-consult.com>, tm-rid@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a6d14905a2f1d9f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/4RoZHJMjsAyI2m4QzauKSQuEggU>
Subject: Re: [Tm-rid] DRIP, EPP, RDAP, and the DNS
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 16:01:50 -0000

My thoughts on this are not yet fully coherent, but here are some of them...

I think of a HHIT as a name, but it is also an ORCHID, thus a valid IPv6
address. So it could be added to the real DNS (with the main root) for
reverse lookup in <nibble-reversed>.ip6. It is aggregatable only in its
upper 64 bits (RRA, HDA), the lower 64 are a flat address space, so there
could be scalability challenges, but only within the scope of a registry
(HDA). To short-cut the PTR then HIP RR (or PTR then AAAA RR) lookup
sequence latency, we could even register <low64>.<hda-domain-name> (or
something like that) as a FQDN.

As the HHIT is a name needing to be registered, we can use internet domain
name protocols (e.g. EPP), services, infrastructure & business models to do
registration. For it to be a legal UAS ID in a given Civil Aviation
Administration (e.g. US FAA) jurisdiction, the registrar would have to
collect whatever information that CAA requires (international harmonization
is recognized as an issue by the CAAs). Some registrars would offer (and
over time develop reputations regarding) better vetting of this
information, thus could be selected by organizations for reference in the
trust policies that will be followed by their observers, e.g. : observer
receives Broadcast from Alice proving she is in Bob's registry, thus trusts
(to some extent) Alice; same observer receives Broadcast certificate from
Carol proving she is in Doug's registry, thus does not trust Carol.

The use of RDAP/XACML would be on subsequent access controlled lookups of
the Whois PII from the HHIT, whereas minimal strictly public info could be
in DNS.

I say all this from the perspective of someone who has configured DNS
servers to do tricks but never worked for a registrar much less a registry
operator, thus I need further education. :-)

Thanks!

On Fri, Apr 10, 2020, 09:47 Hollenbeck, Scott <shollenbeck=
40verisign.com@dmarc.ietf.org> wrote:

> > -----Original Message-----
> > From: Robert Moskowitz <rgm@labs.htt-consult.com>
> > Sent: Monday, April 6, 2020 10:10 AM
> > To: Hollenbeck, Scott <shollenbeck@verisign.com>; tm-rid@ietf.org
> > Subject: [EXTERNAL] Re: [Tm-rid] DRIP, EPP, RDAP, and the DNS
> >
> >
> >
> > On 4/6/20 9:54 AM, Hollenbeck, Scott wrote:
> > > I mentioned this in Jabber during the IETF-107 virtual meeting, but
> I'll
> > mention it on-list as well: if this group gets around to talking about
> how EPP,
> > RDAP, and the DNS can be used in a DRIP context, there are people who
> > have expertise in those technologies who are following the work here and
> > are willing to help. How can we help, and at what point do you think
> that help
> > will be needed?
> > >
> > > Scott
> >
> > So of the DNS pieces I attempt to cover in:
> >
> > draft-moskowitz-hip-hierarchical-hit
> >
> > And I would really like input on this, as it also has some impact on how
> the
> > RAA bits are divvied up.
>
> Bob, I'd like to check my understanding before making any suggestions. Do
> I have this correct?
>
> The HHIT includes a field (the HID) that's used to identify two
> administrative domains, the RAA and the HDA. The RAA is kind of like a DNS
> root, except that in this model there can be more than one. The RAA
> maintains a DNS zone used to discover HDA rendezvous servers (RVS).
>
> The HDA is assigned an identifier by an RAA. The HDA sounds a bit like a
> TLD registry. It operates rendezvous servers and HIP DNS extension servers.
>
> Is this all correct? If so, is the thought that EPP could be used to
> register an HDA within an RAA and HIP DNS extension information with an HDA?
>
> Scott
> --
> Tm-rid mailing list
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid
>