On Wed, May 19, 2021 at 7:15 PM Mark Andrews <ma...@isc.org> wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters <p...@nohats.ca> wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing "," > or "\\", zone file implementations MAY > >> disallow these characters instead of implementing the `value-list` > escaping procedure. > > > > Sorry, an implementor cannot predict the future of the IANA registry. > They > > can't write code to confirm to this requirement other than NOT allowing > > the MAY. > > > > Even if they were silly enough to _first_ check the IANA registry before > > parsing SVCB records, they would still have to write all the the parsing > > code without CVE's for both cases, just in case the IANA registry would > > gain these characters in the future. > > Or detect them and switch to key1=“…” instead of alpn=“…” when displaying > entry would need to be using keyXXXX format until the software was > upgraded. > > alpn=“h1\\,h2,h3” (or alpn=“h1\,h2,h3” I’m not sure where the consensus > lies) > vs key1=“\005h1,h2\002h3" >
I don't understand why any of the comma-escaping is needed at all, honestly. RFC1035 has the definition of <character-string> encoding: A bunch of characters without any internal spaces, or A string beginning with " and ending with ", and anything else in between except " which must be escaped. So, alpn=<character-string>[,<character-string>]* is unambiguous. Restricting the character-string format used to the kind surrounded by quotes, removes any ambiguity regarding commas. Parsers need to be sufficiently well built to not treat commas internal to character-string values as special. No escaping of anything other than double-quote characters within a single value (an ALPN) is needed. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
