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

Brian Dickson <> Wed, 12 May 2021 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 950893A12BE for <>; Wed, 12 May 2021 13:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uh9XTZZkIG9z for <>; Wed, 12 May 2021 13:28:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DEC83A12C2 for <>; Wed, 12 May 2021 13:28:34 -0700 (PDT)
Received: by with SMTP id 131so5829839ljj.3 for <>; Wed, 12 May 2021 13:28:33 -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=AdvjeR7O0TXgwMkHH/2LsV4BPO+TwwEgpAqm5euQnTY=; b=IEKsYFH6Qlo5yWmeX3/xEZPb8E8vozSAzLVok9sCYIR3XDa6A4BFjiyCfA/usdH3l8 q1kpnyOTAOTALjiIRJ8y12vg7iBijxNaPJXB6em5gVU1A2Au3sENHe8xYYCI2VE8Nbxs Ew/OWLOGN6kjfQzRCYGBqwuV0K+TzkJCOn5BuAgXITdjNuprZIAh2p8k7ZFrFA1aQXuE oJNrE912UEC019RiLbvqXagknw4OFPiZM90evzpgOA3K9Ez+bZoa4cSO6+NDTdWgg3G7 feT9yy1KvWnU3rXAcKtvhy8xZ/FSJ4hItTnLSF4Flz8BlaNmLUF+PGuiYMAjzObdC+Lz vD2Q==
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=AdvjeR7O0TXgwMkHH/2LsV4BPO+TwwEgpAqm5euQnTY=; b=s+Oei8UaAJ1ztvFw5sAL8Qkz3VaQcEadxcjmshpA7M5HP0ZHyjfmDB3J0EdhpCBQ0Y 4aBHxm//qCy5jsN9OQLxItzyUa3qDWTqAkyFLP5cQfgyPwc3BynvXVjp0l4XKWYoPwp0 6smLrA8G6pEKGEp8YhZ2GKdj+9GxDA8NkBJ0XpRj3HP7yGRA+aUUwvp7effKJHzrTG8G HXvjLlDLz2Kb3uN/4mal9jblAuR7oVA3RiL8xtUgH77xGEXs2yDUFxRf0nmQWOW751tL 3rL8Ml43EI8ABzDKVAWEEhAvTQeTHOT9zbNuE71qQ/iIBMc6uSf2BDpMHpfFn9VcKbGM I1hw==
X-Gm-Message-State: AOAM5323TzneZYAcroj8nGDvg0/LbvBjHoleF4R5wdvcQesC8ockByhK n/24q/Cv1qHdvsqJ/txstcNnLpaXbtQhKDMjzgp4ltWP5+I=
X-Google-Smtp-Source: ABdhPJyRfBj5os9g0Ih2ZcHV9m2fRBxTgnCB4ATv6eTlvabeg8a9fFYVRBndeYuGxrYcbW3Fvv1BUQfyBKspmEiiXzs=
X-Received: by 2002:a2e:9e57:: with SMTP id g23mr6880016ljk.148.1620851307340; Wed, 12 May 2021 13:28:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 12 May 2021 13:28:15 -0700
Message-ID: <>
To: Eric Orth <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="00000000000068642205c227dabd"
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: Wed, 12 May 2021 20:28:39 -0000

On Wed, May 12, 2021 at 12:28 PM Eric Orth <ericorth=> wrote:

> I have no strong opinions on any of the discussions regarding escaping in
> presentation mode because I don't have much involvement in dealing with
> presentation mode of DNS records.  The client I work with parses wire
> format directly into its internal structures.
> From my wire-format-only perspective...
> I strongly oppose breaking out the key/value pairs of the current proposal
> into separate records within an RRSet.  The "independently meaningful"
> records argument in favor of per-endpoint records isn't just some small
> nice-to-have but is actually rather crucial to avoiding
> inconsistent/missing-data issues that could easily become security issues.
> Per-key/value records opens things up to too much error-proneness where the
> separate records get cached separately (with potentially differing TTLs),
> so there's a lot more room for clients to end up receiving/handling only
> some parts of endpoint data without a clear indication that other parts are
> missing.  Could be much more problematic than just getting a partial view
> of the endpoint options.  Easily becomes a security issue, e.g. when a
> client gets most of the records for an endpoint but misses the record
> containing the ECH config.

Sincere apologies in advance for any offense you may take from this.


You are completely mistaken in this concern.

The DNS RFCs collectively, and in their entirety, forbid any of the

   - Breaking up RRSETs
   - Having RRSETs with Resource Records that do not have identical TTLs
   - Servers sending anything that does not comply with this
   - Clients accepting responses with any of these problems (clients are
   required to ignore such responses)

In short, none of the things you present as concerns can occur if the
resolvers or authority servers are at all RFC-compliant.
There is no need to design your protocol to defend against these issues, at
(This is documented clearly in RFC2181, and further referenced for clarity
purposes in the DNS Terminology RFC, RFC8499.)

Responses including partial RRsets are as unlikely (and as illegal) as a
response to a query for SVCB being a TXT record saying "I'm a teapot".

Please take it as read that queries for an RRTYPE will always return an
RRSET which is complete and has uniform TTL values.

Concerns over MITM tampering of results can be addressed by use of DNSSEC,
where the RRSIG (signature) is over the complete RRSET and included with
the RRSET itself. It is literally impossible for a MITM to tamper with a
signed response which will pass the validation by the recipient.

A MITM can just as easily modify the singular RR containing all the
key/value pairs together, so the concern is either moot or invariant
regarding single vs multiple records.

IMNSHO, the wire-format discussion should not be excluded as a result of
your concerns, if the RRSET integrity is your only concern.