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

Eric Orth <> Wed, 12 May 2021 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0410F3A15C2 for <>; Wed, 12 May 2021 14:03:52 -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 npw31yRm4gDh for <>; Wed, 12 May 2021 14:03:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A75E3A15BB for <>; Wed, 12 May 2021 14:03:49 -0700 (PDT)
Received: by with SMTP id s37so7909227ybi.6 for <>; Wed, 12 May 2021 14:03:49 -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=7GNjsTbIONS3Le/OUQXUCL5/7rInm5fA1F0rN3qHtts=; b=bXUD8ijG+jGa2U74nI2RqLI5N8qNamPFfH1GnCArca0+J8kzsW9mTxq7CtjqcEtbc1 kMOwUh1YrTBjsFHAvHah/eh1MEtsINsSC5sZ09nm/b9mZfebdqXNBnJw7UKnCY0duLH2 b70UmjN92O8ydSSNFMrAz1ZTNUh5M5WJZTxWq50h+CTPWbvOvDnRCBUd/2ebUZ+4Al2N wZpo5tbjGPKZ1GOFOX/I2mZOEQXZW/gXDK/bBl/xlggwHrVbb2SXwLgyHbATfCDQAGp/ nauYBqT8V64BqAgYya2fbckxl3G3+G+rEEwbFxn5Iz5qIM98SAUakUH4Vprn5JYQz/G6 9STw==
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=7GNjsTbIONS3Le/OUQXUCL5/7rInm5fA1F0rN3qHtts=; b=cRblzpc931aTXvDZauDFVCFMj75oPIhxC/xCYd4fohGsGPbWrztouiJtEDIZl4VqRq FEvymNK09RfPOsPZ7wG8V8JhfnzisrN3R6iO2MR4eFjrG22dMQk6VrhB2Oam88eiIHAc dc/GM7hGM32mA9o7nCMY4mKiM0sqezoDShAC3WjGjNlYkHyVFOhq4ntSnU13sVxcf247 lcorofgpGTfEIF5hsKCWdA/oc1Kxk7EmTKb7Zh6hPRbPpKydmR1wodmpkCjficMMLwmd RZVOF/yux6WlVrHAXv+ybHvglKmUas5D3LJqN9gECIfwfGxzKHWGfm2rzasSIvKS0E8+ Qi4g==
X-Gm-Message-State: AOAM530nGMS9wPCwBulG8Hxq0Rl44zoroK4NSjFR7CM0TjgQMUnE3h4Y vgUrfP2pUw4FIxMfyQP3sF/xO6BC5kxWPbz+rv7dICWg1nURvw==
X-Google-Smtp-Source: ABdhPJzHfGw75nmuGXm94FFt6HIkUiA9hJBr/MgHgSz4S2wgwbDER8rsS62WDdnnwoGvb6HUz9f9sMIUdWEsB7qii2M=
X-Received: by 2002:a25:cdc4:: with SMTP id d187mr3791093ybf.168.1620853428382; Wed, 12 May 2021 14:03:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Wed, 12 May 2021 17:03:36 -0400
Message-ID: <>
To: Brian Dickson <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000d5833605c2285850"
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 21:03:52 -0000

On Wed, May 12, 2021 at 4:28 PM Brian Dickson <>

> 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.
> However...
> You are completely mistaken in this concern.
> The DNS RFCs collectively, and in their entirety, forbid any of the
> following:
>    - 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
> all.
> (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".

Agreed that there is no such issue with either wire format if all parties
in the ecosystem are bug-free and RFC-compliant.  But with all the many
layers and implementations caching DNS, I have a low level of trust that
everyone has read and understood all applicable RFCs and is capable of
applying it all correctly in an implementation.  Thus I still stand by my
point that one wire format here is much more susceptible to potential
caching bugs than the other, and that such issues, while arguably just as
"illegal", are way more likely than receiving a spurious teapot record
(that would be a very impressive bug).

> 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.
> Sincerely,
> Brian