Re: LSD0001 review

[Schanzenbach, Martin]

> On 7. Feb 2022, at 20:02, Schanzenbach, Martin <mschanzenbach@posteo.de> 
> wrote:
> 
> 
> 
>> On 7. Feb 2022, at 12:37, Maxime Devos <maximedevos@telenet.be> wrote:
>> 
>> Hi,
>> 
>>> Name
>>>   A name in GNS is a domain name as defined in [RFC8499] as an
>>> ordered list of labels. The labels in a name are separated using the
>>> character "." (dot). Names, like labels, are encoded in UTF-8.
>> 
>> Does that mean, no punycode, unlike DNS?  Does GNUnet's GNS<->DNS code
>> handle punycode conversion?
>> 
> 
> Yes. It MUST handle conversion when DNS gets involved. The spec should state 
> that
> on the respective sections.
> 
>>> GNS TLDs are typically part of the configuration of the local
>>> resolver (see Section 7.1), and may thus not be globally unique
>> 
>> This reads to me as ’it is forbidden for them to be unique’,
>> whereas I assume it was meant ‘and thus are not necessarily
>> globally unique’ -- if I name a TLD, say, maximed-943438-foobar, then
>> it's probably globally unique.
>> 
>> It's clear from context though, and this sentence can be read
>> in the latter way as well.
>> 
> 
> Ah interesting you read it in this way. What it actually means is that even if
> I have a TLD configuration for maximed-943438-foobar, it does not necessarily
> delegate to the same zone as your configuration.
> Hence names (with delegation) are may not be unique even if the names
> are equal (0 == strcmp (name1, name2))
> 
>>> In order to further increase tolerance for failures in character
>>> recognition, the letter "U" MUST be decoded to the same Base32 value
>>> as the letter "V".
>> 
>> Does this mean that, if I point a browser at a zTLD with a 'U',
>> then the browser should change it to a 'V' (if the browser has GNS
>> integration)?  How does this interact with the domain name in TLS and
>> HTTP?  If the server expects a certain (subdomain of a) zTLD, does it
>> need to recognise equivalent encodings?
>> 
>> Likewise for 1IiLl, Aa, Bb, ...
> 
> Reading this again, I think the table is wrong.
> I think the "U" (and "u") should ne next to "V v" in the decode symbol column.
> Then, the _encoded_ string should always be a "V".
> Should the browser or the application make a "V" out of a U when it 
> encounters it?
> That is a good question. I think maybe the encoding may need to be 
> "normalized"
> in such a case to "V".
> 
>> 
>>> TIMESTAMP
>>>   denotes the absolute 64-bit date when the revocation was
>>> computed. In microseconds since midnight (0 hour), January 1, 1970
>>> in network byte order
>> 
>> Do leap seconds count? What timezone is this?
> 
> UTC. I guess we should add a posix reference here.
> 
>> 
>>> DNS NAME
>>>  The name to continue with in DNS. The value is UTF-8 encoded and >
>> 0-terminated.
>>> DNS SERVER NAME
>>>  The DNS server to use. May be an IPv4 address in dotted-decimal
>>> form or an IPv6 address in colon-hexadecimal form or a DNS name.
>> 
>> How is using a DNS name for the DNS server supposed to work, how are
>> we supposed to resolve the name of the DNS server without a pre-
>> existing DNS server?  This seems rather cyclic.
>> 
>> Perhaps the ‘standard’ DNS root servers need to be contacted
>> (indirectly, via the ISP's DNS servers)?
> 
> Yes. The system stub resolver should be used.
> 
>> 
>> If the peer doesn't have DNS set up, or it does have DNS set up
>> by redirecting it to GNS, what is supposed to happen?
> 
> See section 7.3.2
> 
>> 
>> Can I use localhost or loopback as IP address?
>> If I can use localhost or loopback here, how is that interpreted?
>> The peer that initiated the GNS query?  The peer that contacts the DHT
>> system?  The peer that created the GNS record?
> 
> If the zone owner that created this record put the loopback in there then
> it will point your resolver to YOUR local host, of course.
> So: Yes, you can use it. Maybe there a use case for it actually where
> you have a special DNS server running locally to resolve special DNS names 
> (without the ICANN root, for example).
> 
>> 
>>> It
>>> may also be a relative GNS name ending with a "+" as the rightmost
>>> label. The implementation MUST check the string syntactically for an
>>> IP address in the respective notation before checking for a relative
>>> GNS name. If all three checks fail, the name MUST be treated as a DNS
>>> name. The value is UTF-8 encoded and 0-terminated.
>>> 
>>> NOTE: If an application uses DNS names obtained from GNS2DNS records
>> in a DNS request they must first be converted to a punycode
>> representation [RFC5890].
>> 
>> I'm not sure what this note means exactly.  Does this mean that DNS
>> NAME and DNS SERVER NAME must be in punycode?  Or do they not need
>> to be in punycode, instead the name in the record should be converted
>> into punycode before contacting the DNS server?
> 
> No they are in UTF-8 as it is stated. But when you resolve this record and 
> want to USE it
> for anything related to DNS, you need to convert it to punycode.
> A resolver MUST of course also convert to punycode when continuing with DNS, 
> for example.
> Now that I write this, this information is missing from section 7.3.2 :)
> 
>> 
>> Are IPv6 addresses with surrounding [] or without?
> 
> Without. Only colon-hexadecimal form.
> [] is only really used for URLs, I think 
> https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2
> 
>> 
>>> LEGACY HOSTNAME
>>>   A UTF-8 string (which is not 0-terminated) representing the
>>> legacy hostname.
>> 
>> What happens if it contaings \0, or ends with two dots, does that mean
>> the LEHO record is invalid and must be rejected?  If it is in punycode,
>> why say ‘A UTF-8 string’ instead of ’an ASCII string’?
> 
> It is not in punycode. It is just a UTF-8 string.
> Why is it not 0-terminated? TBH I am not sure, probably to save a byte :)
> 
>> 
>>> NICKNAME
>>> 
>>>  A UTF-8 string (which is not 0-terminated) representing the
>>> preferred label of the zone. This string MUST NOT include a "."
>>> character.
>> 
>> Can I have a nickname "SOME-ZTLD"
> 
> Yes.
> 
>> , "@"
> 
> Ah good catch. Yes. But nobody will accept it.
> 
>> , "foo<nul byte>bar"
> 
> Yes.
> 
>> , "foo;bar",
> 
> Yes
> 
>> "foo@bar"
> 
> Yes
> 
>> , "@"
> 
> again? Yes
> 
>> , "an UTF-8 string not in canonical form",
> 
> Yes
> 
>> "special<characters"
> 
> Yes
> 
>> or "" (zero-length string)?
> 
> Yes
> 
> You can do whatever you like with your string.
> You cannot expect it to be used :)
> 
>> 
>>> PURPOSE
>>>   A 32-bit signature purpose flag. For a RRBLOCK the value of this
>>> field MUST be 15. The value is encoded in network byte order. The
>>> value of this field corresponds to an entry in the GANA "GNUnet
>>> Signature Purpose" registry.
>> 
>> What should happen if unrecognised flags are encountered?
> 
> This is an instruction on how to create the signature. So:
> The signature cannot be verified if it is changed.
> It is not part of the wire format, strictly speaking.
> You do not actually "see" it in a message.
> You build this header when verifying/creating the signature.
> 
> But the pupose may still be removed from the spec.
> 
>> 
>>> 7.3.3. BOX
>>> 
>>> When a BOX record is received, a GNS resolver must unbox it if the
>>> name to be resolved continues with "_SERVICE._PROTO". Otherwise, the
>>> BOX record is to be left untouched. This way, TLSA (and SRV) records
>>> do not require a separate network request, and TLSA records become
>>> inseparable from the corresponding address records.
>> 
>> What happens if try to run a web server at
>> "http://_SERVICE._PROTO.domain.tld"; (assuming there's a AAAA record
>> or something there) and the user points the browser
>> at "http://_SERVICE._PROTO.domain.tld";? Success, failure?
> 
> This is an interesting question. I think currently the GNS is implemented in 
> this way:
> 
> If the remaining name to resolve is of the format _SERVICE._PROTO, ONLY
> a BOX record will be accepted (no _PROTO delegation, for example).
> This is currently not reflected in the spec
> 
> To answer your question: It will currently fail in practice, but is undefined 
> in the spec.
> 

Actually, I checked and the behaviour is correctly specified:

For example, if you have the name _443._tcp.gnunet.org, then the record
set for "gnunet" in the zone "org" will determine the processing.
So if "gnunet" does NOT have a BOX record it must be a delegation record such
as PKEY.
This will result in _tcp and then _443 to be resolved like regular labels (no 
BOX involved).
If "gnunet" does have BOX records AND they match the service and protocol, the 
boxed
record is returned.

In your example (unless you are talking about DNS) it is not clear which case 
you mean.
But both work and will return whatever is boxed or located under the label _443.

BR

> Thanks for the pointers! Very helpful.
> We will try to address them.
> 
> BR
> Martin
> 
>> 
>> Greetings,
>> Maxime.

signature.asc
Description: Message signed with OpenPGP