Clarifications relative to RFC1464 (including need to better specify key=value encoding)

[enygren]

We reference and use RFC1464 in the metadata sub-section but unless I'm misreading there inconsistency here, and the resulting syntax doesn't match RFC1464 and is under-specified and has some ambiguities.

In particular:

• RFC1464 doesn't actually define the comma-separated scheme we specify. Unless I'm misreading it, the "token=XYZ,expiry=ABC" would just result in "XYZ,expiry=ABC" being the value of "token". There seem to be lots of different approaches here (eg, DNS-SD / RFC6763 has them as separate length/value units while DKIM uses ";"as a separator, and I suspect other approaches exist).
• We first recommend just using the base64uri-encoded token, but in the following metadata section we recommend using token=. Should we be consistent and always recommend a RFC1464 token= mechanism?
• As base64uri is often going to have trailing "=" as padding, we may want to include this in examples and make sure this is unambiguous as far as escaping/encoding goes. Otherwise this could be a common interop issue.

[moonshiner]

From reading the text in -04 version, it expands on base64url to include base32 and base16, and adds a paragraph of text on the encoding.

SOmeopne else should confirm this has been addressed.

[enygren]

We expanded on the encoding, but I think we still need to clarify that the RFC1464 reference is not adequate on its own to define the syntax.

[moonshiner]

Good point Erik and I never found a good example in 1464 of steps to generate.

I do get on my high horse on examples. apologies

[moonshiner]

Soooo - I have been down the rabbit hole of TXT record formats numerous times. I went and dumped all the TXT records at the zone apex for the alexa top 1000 domains. While this is not everything, when I combine it with things from the Underscore registry I have more thoughts. not many records use the semi-colon (DMARC/DKIM mainly) the majority are

as SVCB uses format of "tag=value tag=value" etc I feel we should continue with these style as resolvers can leverage the existing code uses. https://www.rfc-editor.org/rfc/rfc9460.html#name-zone-file-presentation-form

most tag=value have just one

total TXT records: 9173

tag=value 6045

== 133 spf 901 tag: value 133 (examples include "yandex-registration: " a number of examples like this "fastly-domain-delegation-b7wfficndvihh4xc7g4z-782253-2024-06-25" "ZOOM_verify_ao6wpWCOQNGoTv0Wo-mkxg" and the rest appear to be of the "random string" --- suggestions formats should be tag=value .... (which can also be "value") base64url (the "ssss==") thoughts? I can suggest text

[moonshiner]

I am also an idiot. Dawned on me it is Service Providers who will validate these records.

[moonshiner]

"Should we be consistent and always recommend a RFC1464 token= mechanism?" YES, but I also think just the value is fine, so I can not make up my mind

"As base64uri is often going to have trailing "=" as padding, we may want to include this in examples and make sure this is unambiguous as far as escaping/encoding goes."

How about examples of all three - here is example.com

base64 ZXhhbXBsZS5jb20uCg==

base32 MV4GC3LQNRSS4Y3PNUXAU===

base16 6578616d706c652e636f6d2e0a0a

yea? nay?

[enygren]

The biggest problem with the current text is that we reference rfc1464 but are in explicit conflict with it. It only supports space separation, not comma separation.

Switching from commas to spaces in the example is fine as long as we only ever have token per resource record. (ie, using the "long string" model from RFC 1035 introduces ambiguity)

If rfc1464 is specified then token= MUST be present, as otherwise a base64 value ending in = or == has specific handling and would get split up by the rfc1464 encoding.

Perhaps:

• We switch to space-separated to match rfc1464 (and update examples accordingly)
• We have a SHOULD on a tag=value format to allow for extensibility and to cover cases like including both a token and an expiry
• We mention that if the token isn't prefixed with token= then rfc1464 encoding/parsing MUST NOT be assumed
• We are clear that if multiple tokens are present in an RRset, they MUST each be in a separate RR to match them up with expiry and any other attributes, and mention the overall limit of 255 characters.

[moonshiner]

Oh these are all things I can agree on. Do you have time for some text or shall I?

[moonshiner]

I'll work on some text and have y'all review

[moonshiner]

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/132