Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Paul Wouters <[e-mail]>]

On Mon, 10 May 2021, Ben Schwartz wrote:

> It would also require a dramatic rewrite of a specification that is now widely deployed.

The IETF is not a rubber-stamp factory for corporate proposals though.

The tendency for corporation to bring up something at the IETF that is
"too far gone" for modifications during the IETF process as a trend
is worrying, and does make me personally feel less sympathetic towards
those kind of deployments.

Did you reach out to SecDir for an early review request? I cannot find
anything in the SecDir archives related to HTTPSVC or SVCB.

DNS records have been using _prefix labels for a while now to split up
RR information to be more specific related to targetted DNS requests.
This RR type is unfortunately not using that, and thus the complexity
and securtity issues are popping up now.

> To see why I favor two-pass, consider a SvcParam whose wire format value is defined to be CBOR, represented as JSON in the zone file.  JSON is defined as UTF-16, and allows strings
> containing any character from the Basic Multilingual Plane.  It also allows various kinds of backslash escaping including " \" " for quotes within strings, and "\uD834\uDD1E" for
> extended unicode codepoints.  A one-pass parser must somehow integrate this into the flow of zone file parsing.  The easiest way is to simply disable all RFC1035-style escapes

Or to simply disable all JSON/COBR/UTF-16 et all ? Do we really need
emoticons in our transport definitions ?

> I also think these behaviors would be confusing to users, who would have to try to understand how this new integrated escaping works in order to author zone files

If that is the main argument, what's wrong with plain ascii limitations?

Anyway, I think this issue deserves a full discussion, without taking
into account the current wide deployment. Also bacause everything out
there that does not support SVCB also continues to work, so it is not
the end of the world if SVCB needs to go through some changes. But
as Mr.Abley said (and I paraphrase) "we can burn an RR type allocation
easilly".

Paul