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

Ben Schwartz <> Thu, 13 May 2021 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D026F3A1072 for <>; Thu, 13 May 2021 11:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmDtndzAvqt1 for <>; Thu, 13 May 2021 11:23:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 018C33A106F for <>; Thu, 13 May 2021 11:23:01 -0700 (PDT)
Received: by with SMTP id v12so27738294wrq.6 for <>; Thu, 13 May 2021 11:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mwOhpgC/Ux+wKhFaZehXFRu1Hv7Tj8jxFQ1FlvamIWc=; b=mRgnNWdHzfS1zx76ftkne/4Ftw+ths1RCzCURTjKebFZDa+MnUHMrtHC76USm/IhPT JUzc9CdLxyjPNgKVZYhn/szL0TcIUtYpszxHgT3bLix1H56KxZwyZYyLWZY+UcJchGou qgp+/d6P5XMfWYJxdpaP3+k/aAByJ3AiOfeeu7AejwHc8EfHPpSPaFaRATCKBbDo5uJi OGiSId4mHRH68UID22H0J3J9UuNPLyOts1WA8VPjoYSp6FChNpb3UONIGDS8ELJf/Ds1 zT5FTn+zd6ubLVrXqC8cd5tFndDSQW2emu+hwnXvE0sZD80lkO6pmg3bsou3BCQl0QUZ 9b6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mwOhpgC/Ux+wKhFaZehXFRu1Hv7Tj8jxFQ1FlvamIWc=; b=YY6wLHT7xe/973goT1RzF7bzQf2c3ACyOAh6FUvp4Ta5xFTfII0Q+bQ4wOS7zrbcyq qR8IYBE1d2LhPlRbiG3ucXyyNM80BVFT8ex0EsyK/+F//5V56gHAIQnCD47x8pJtHCiQ pXH8fUVcUMqmUG2c6E36XQ1oGvswFjFDqakIecxkCuvKa1YmowVfTK5UmNL104uCQNt4 3446cCavAxsa4GHhcj1mp0deY8UjpRNVjYlZrG3iRonnhlxsCcXdANtSgMywHsv81Xq1 Gh0dDMZS8+MozEiLO3+SB2ccqFEsaMN47jofwM4xo9DORYDbJNVkQGilpEdnguDyFuMb SNjg==
X-Gm-Message-State: AOAM530my5mWppa+21rs0QtuYEEc1iVR1nxK7hg5cMaWcy2BvF93KnIQ 6qVYT8o6/elwuJcEqSeoAln2oBFZhegK14WIr6A8Ug==
X-Google-Smtp-Source: ABdhPJwvPQBf1z2FjxdvyGJkC27Aq60Yn2/Z1GMACn92SzBO4DT0j2aB6x7AAfovmd0Jhk0Djp1Bu/2EJefTXNGG8/M=
X-Received: by 2002:a5d:564b:: with SMTP id j11mr22556192wrw.258.1620930179572; Thu, 13 May 2021 11:22:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 13 May 2021 11:22:47 -0700
Message-ID: <>
To: John R Levine <>
Cc: Brian Dickson <>, dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000948bd805c23a37c3"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 May 2021 18:23:07 -0000

On Thu, May 13, 2021 at 10:59 AM John R Levine <> wrote:

> On Thu, 13 May 2021, Ben Schwartz wrote:
> > SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
> > 6763); it is not new to DNS users.
> Hey, wait a minute.  DNS-SD just sticks the "key=value" strings as-is into
> text fields.  Now that I look closer, I see what Brian's objection is and
> I have a lot more sympathy for it.
> No other RRTYPE has master file processing anywhere near as complicated as
> this:
> ~>  - sort the SvcParams by key
> >  - verify their uniqueness
> >  - deal with list of fields nested in other fields (this includes the
> > discussed comma escaping)~
> If you put the SvcParams into text strings and let the client sort it out,
> I think the objections would go away.

That's possible, of course, but it would be much less efficient.  HTTPS
records are intended for use at the start of every HTTP connection;
eventually they could be almost as frequent as AAAA.  They can also contain
relatively large binary objects (e.g. public keys for Encrypted Client
Hello).  A text-based format was deemed insufficiently compact for this use

Pushing text processing onto the client does not reduce the complexity; it
just moves it to people who are less likely to be reading DNSOP.  Notably,
it moves that responsibility to a place where typical text processing
errors are far more dangerous, and malicious inputs are far more likely.

In addition to being safer, performing parsing at the authority also
improves early detection of typos and syntax errors.  In a textual format,
errors would be much more likely to be detected only after they cause an
incident, or to be overlooked entirely if the failure is silent.

The complexity of the zone file format is significant, but the existence of
multiple production implementations suggests that it is not unmanageable.