Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

Ben Schwartz <bemasc@google.com> Fri, 28 August 2020 14:41 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B283A0C4E for <dns-privacy@ietfa.amsl.com>; Fri, 28 Aug 2020 07:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBr-uhWHHBVc for <dns-privacy@ietfa.amsl.com>; Fri, 28 Aug 2020 07:41:58 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21C53A0C3D for <dns-privacy@ietf.org>; Fri, 28 Aug 2020 07:41:57 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id f75so1031271ilh.3 for <dns-privacy@ietf.org>; Fri, 28 Aug 2020 07:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wjdHWf0CQvHxNcrleTopdfTaHtZGJbpaNtrNObiUNQo=; b=kIWZNXZO9QmFLJBLsub6e+NdITUWXO7sodBF37smijK7EDzfYv6Ww79rkdR8GVdb1d z/YX7DRGpOCI7EJGbKlDp7Sr2hAF1cQB8Lh68LUJIIG+Ehg7eMQrp7+3snS7zy/csFpa Uci8Y03s5UXnMewTFxatAH13f67CgGMH9P9iQuRBhm013g7EGZi2HqrP5jjfphKaLYbx mT/zYhRHoAIEClWShxZheIGRzYU3pInlx2mR6hlAX18me9AOG4xs7gT0qAIoq1uH35Qv GzrkeaAz13Izgn5CdeH8hYUq6J1/2S18LdcCm8ZQWcnJYaMBwduIPlKVqtpymq4MFl+O 3KMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wjdHWf0CQvHxNcrleTopdfTaHtZGJbpaNtrNObiUNQo=; b=s+OJ8xHfrSOfIvsT1GW/0HASpHYzqb/ooxfxJL/JGv6jcX/ZXRlpHjAVO5UxOHAN8O xNZ+ybYLFY+zaEK52qrVkPd8bQb6YqrBZ1KU2caf8af2pmiD0mug2PhePuADV9GJXbYg vCm4s6vPT7Mh1E8joqiAhhy6D/cYcgof/DeoO95LRagwk9Byfh5Ok1hGqRucnTMkPFkb XdpF4l/Eq2gScuG42HFXsMYV+EgeEgxz/W1Cwi4uTqr0KAXkhdOHwAlQSwQpVFtkhJ9+ R8ys9mKjBDDn9h91ygf4ihgg0/vJV6uZhlLZTxbhElFrg8daUIGlUAeR+jmC0tN5ynli FrRQ==
X-Gm-Message-State: AOAM530x/SqxJ0oh11MYC5678oaPj3aroQcaoifVSaMX40kyJqNPAeMk rrUdRrC9F88YOLCL//YstegMqci39V1Ov6rJZYsqdg==
X-Google-Smtp-Source: ABdhPJz/IoNjuWhyVqjKY01BpWf6J6Ti2AF8kILpjufMGUHbRMD4HSD+8I6IsBsZHHppeqrD3ZJyRDRlNVD4vWwXJ2M=
X-Received: by 2002:a92:1510:: with SMTP id v16mr1688094ilk.241.1598625716811; Fri, 28 Aug 2020 07:41:56 -0700 (PDT)
MIME-Version: 1.0
References: <6e071da2-4281-d525-03ba-4d6dfc843a76@innovationslab.net>
In-Reply-To: <6e071da2-4281-d525-03ba-4d6dfc843a76@innovationslab.net>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 28 Aug 2020 10:41:45 -0400
Message-ID: <CAHbrMsB7T+5Y=2n4LfcXwyAZQSnK4x72R44_2mCDsLhh_zD9Vw@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000002f19e05adf10ed8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/iZKNNfqJHwOC3nD2keWUA9erees>
Subject: Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2020 14:42:00 -0000

Some commentary on this draft:

Section 3 proposes that there is an apparent inconsistency within RFC 8484
regarding redirection and URI permissioning.  I disagree: I find the
meaning of the text in RFC 8484 quite clear and consistent on this point.
To the extent that some aspects of client and server behavior are not
specified, this is largely deliberate.  HTTP contains a vast range of
behaviors that clients and servers might or might not support, including
following of redirects (which is optional [1]).

On server push, I think this draft contains a misunderstanding.  RFC 8484
says that clients must not accept and use DNS records that were pushed from
some arbitrary server that is not the client's configured DoH resolver.
(That would obviously be unsafe.)  It does not forbid accepting unsolicited
records that were pushed from the configured DoH server.  (In some
configurations, unsolicited records of this type would live in a local HTTP
cache, invisible to the DNS client layer until a matching query is issued.)

The draft contains two proposals that seem to be minimally related.  I
would consider splitting them into two drafts.

The ".well-known" proposal (Section 6) does what RFC 8484 avoided doing: it
proposes an alternative encoding of DNS records in JSON.  As a result, it
can only represent a subset of DNS information, with standards work
required for each extension.  For example, as currently specified, it
cannot represent DNSSEC signatures or the HTTPS RR type.  I would encourage
the authors to avoid assumptions about specific RR types, and also to
explain why CNAME or Alt-Svc is not sufficient for server changes.

This proposal seems to assume that there is only one DoH service on the
domain that is hosting this JSON file.  This is not required by RFC 8484,
and is already false for some major deployments (e.g. NextDNS).

The 3XX proposal (Section 7) sends DNS records in the body of a 3XX
response.  This is interesting but definitely unusual: "The server's
response payload usually contains a short hypertext note with a hyperlink
to the new URI(s)." [2].  Also, since following redirects is optional, a
server using this mechanism would risk losing any non-redirect-following
clients.  That's acceptable if the query would otherwise have to fail, but
needs to be mentioned in the draft.

[1] https://tools.ietf.org/html/rfc7231#section-6.4
[2] https://tools.ietf.org/html/rfc7231#section-6.4.2

On Fri, Aug 28, 2020 at 8:52 AM Brian Haberman <brian@innovationslab.net>
wrote:

> Hi all,
>      One of the discussion points during IETF 108 revolved around a
> group of DNS-related drafts without a clear place for discussion. The
> DNSOP, ADD, and DPRIVE chairs and ADs convened a few weeks ago to try
> and sort this out. The upshot of that discussion is that
> draft-btw-dprive-rfc8484-clarification should be discussed on the DPRIVE
> mailing list. So, this is a request for WG participants to review the
> draft and provide feedback on the mailing.
>
> https://datatracker.ietf.org/doc/draft-btw-dprive-rfc8484-clarification/
>
> Regards,
> Brian
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>