[DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model

["Sipos, Brian J." <[e-mail]>]

All,
I'm replying to a non-specific message in this chain just to mention that, similar to what Lorenzo brought up, any translation of identifiers (names or addresses) will be fraught with problems related to security and should not be done. There can be translation or mapping that happens in a way not visible to users/clients, but whatever identifiers are visible to the user/client need to have stable meaning across any network.

Naming authorities, such as PKIX CAs, need to rely on the fact that once a user proves ownership of a specific identifier that same identifier will not be used by other users (at least not simultaneously over a short time interval). Part of the reason why public CAs such as Let's Encrypt will not issue certificates for IP addresses is the prevalence of IP NATs, even though IP identifiers are allowed by the CA/Browser TLS baseline [1].

[1] https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.5.pdf

> -----Original Message-----
> From: Scott Johnson <[e-mail]>
> Sent: Wednesday, July 24, 2024 4:44 PM
> To: Marc Blanchet <[e-mail]>
> Cc: Lorenzo Breda <[e-mail]>; DTN WG <[e-mail]>; dnsop
> <[e-mail]>
> Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model
> 
> APL external email warning: Verify sender [e-mail] before
> clicking links or attachments
> 
> Hi Marc,
> 
> On Wed, 24 Jul 2024, Marc Blanchet wrote:
> 
> >
> >
> >       Le 24 juill. 2024 à 11:42, Lorenzo Breda
> >       <[e-mail]> a écrit :
> >
> >
> > Why are you against leaving the current TLDs implicitly on Earth by
> > default?
> >
> >
> > Right. One do not need a special TLD for space. We can use what we
> > have and it just works fine.
> 
> I do not disagree with this notion as respects my proposed architecture.
> 3rd level domains mapped to off-world domains works just fine, for the low low
> price of annual domain renewal.  a tld representing each remote world is
> preferable, however, because it is just "cooler;" easier to use and more
> memorable than a much longer domain.  This, however, assumes we are talking
> about the same proposal, which we are not.
> 
> > One has just to be careful on remote resolution so that it contains
> > what is needed: trust chain, local names, ...
> >
> 
> Lets be clear here, Marc.  You are talking about a completely different solution
> than I am; one predicated on IP only.  Your comment on this thread, without
> context, only serves to confuse the other participants.
> 
> For example, you are talking about using F-root, right?  That is a very different
> thing than the functionality which I am describing, with significantly more
> network resource usage requirements.  My solution uses BP in some network
> segments.  Personally, I don't think your method will ever fly, primarily due to
> security reasons, but I don't troll your threads about it in a manner which would
> muddy the waters of those considering your proposal.  I don't mind healthy
> competition of ideas, but I do expect fair play.  If you wish to contrast the two
> methods, thats fine, yet unproductive, IMHO.  Just make sure the reader knows
> you are talking about your proposal, and not mine.
> 
> ScottJ
> 
> 
> 
> > This is discussed in:
> > - running IP in deep space (noBP<->IP):
> > https://www.ietf.org/archive/id/draft-many-deepspace-ip-asse
> > ssment-01.txt
> > - running DNS in remote places:
> > https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-network
> > s-01.txt
> >
> >
> > Regards, Marc.
> >
> >
> >
> > --
> > Lorenzo Breda
> > _______________________________________________
> > dtn mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> >
> >
> >