Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

Ben Schwartz <bemasc@google.com> Tue, 20 August 2019 15:59 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 253501200EB for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 08:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VyKVqNTzpD7S for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 08:59:12 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 624EB1200E5 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 08:59:12 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id e20so13224541iob.9 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 08:59:12 -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=igLC2NA7YWDXE8ayOvL3nv4q4pE0saDBGK33gWZjd84=; b=stZAMW0SlxEnAmQ5I3pjjK2iOWfPuRwWlm03PJGEomnN/IqRSGJQFayxmA9fKmeiAk S8DW4JrlsT0z4b1XWkaM7espnA5lUnSDff7Uy6TG+hrswbkmACZe6A4GaRtdEOlSZiYb 1l6n/5fNUvWTMIXkaAYhRPx1sMvW+xssKVFhuAFvdKLRg0MT+F9/Nz3ObJje2WJkBE24 OEHnA7Ha/0fqA5oD1repUnGIQKoRJ5H3Kqrmu8rv7iaoy9k+icc1KgTUmCOqxsT/elbF XIZaIc4wHwkmDV7oHuZSpn2Qfse2FA5MW6JT6Z9tGmOZIp5MKVKHm8UXsz/OuzR9uMVC NQdA==
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=igLC2NA7YWDXE8ayOvL3nv4q4pE0saDBGK33gWZjd84=; b=sVF/AG23MrSf/h1i12kfVUQ1vNJ5AdfN3Hhpklfqt+LyfPdHIFK3W7PpGmq3zU6gdg HVF0K4pZm4n1UA32UnRtvpCWievLF0qMFS9uY/u3YLRQ33kNDMqFmXKyaqC1VGlymUdN wHsFE9ThlUSXtkhnBuTdOjgWrhz9k+Tl9cC/A+NzuBiaM/04AefXgT0R55fppDWrM9S4 qJOIbLDM7EaF66mj4ztD3i6myxV85ZwCyC8hkGAmnPq+qRIVRMxGx7F+R2BmJUFTfSu0 ML63QJOF99M2BO913ornq18SxZLaKYKj/xPzj+RXPwgmeTjHQOMp9X8boDoxDty9WZ11 6gjg==
X-Gm-Message-State: APjAAAV+cgzbBxSo+xJeinyYodnaiNjlGwjdlDEB1WiQPIAFYYd5K+ET 82BkHs7jKrGkX3tVRGkFFLv10gDoeTeNspmevmo/Vg==
X-Google-Smtp-Source: APXvYqyOM1PwDvazfAN07uBw0mLb33Ol0/qw6QbJGejlKu5ZJQqm622rbyyTRJlmF1BKlbx1ENzI9xm/Aj6GnSnmarU=
X-Received: by 2002:a02:7f15:: with SMTP id r21mr4568960jac.120.1566316751394; Tue, 20 Aug 2019 08:59:11 -0700 (PDT)
MIME-Version: 1.0
References: <6CD20313-147F-40A9-91D2-16F2E19A4B48@verisign.com>
In-Reply-To: <6CD20313-147F-40A9-91D2-16F2E19A4B48@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 20 Aug 2019 11:58:59 -0400
Message-ID: <CAHbrMsB1btUeuZDFhVhVAseJ+D4meSW8XCGR2Z6PANWUR0_84g@mail.gmail.com>
To: "Henderson, Karl" <khenderson@verisign.com>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "hmco@env.dtu.dk" <hmco@env.dtu.dk>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000009b0d1c05908e895b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/rNH3CiscsRDlOSYC9Lsx4WfYMng>
Subject: Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations
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: Tue, 20 Aug 2019 15:59:15 -0000

On Tue, Aug 20, 2019 at 9:39 AM Henderson, Karl <khenderson@verisign.com>
wrote:

> Hi Ben and Hugo,
>
>
>
> I wanted to follow up and see if my response to Paul satisfies your
> concerns regarding ADoT being a new unspecified protocol?
>
>
>
> To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply DoT
> with a prepended A to disambiguate the path taken.
>
>
>
> Regards,
>
> Karl
>
>
>
> >Hi Paul,
>
> >
>
> >To further clarify, we are not suggesting a change to the DoT protocol
> and are making liberal use of the final sentence in the Abstract of RFC7858
> and echoed in the Introduction of RFC8310: "It does not prevent future
> applications of the protocol to recursive-to-authoritative traffic."
>

I interpret that sentence differently.  I read that sentence to refer to
"future applications" of the [RFC 7858] protocol in the context of a future
standard, yet to be defined.  In the absence of such a standard today,
there is no defined way for a recursive server to speak DNS over TLS to an
authoritative server.

In your draft, I would characterize sections 3.1, 3.2, 3.3, 3.4, 3.7, 3.8,
and 4.2 (a majority of the substantive text) as input to the standards
development process for an ADoT standard, which is indeed part of this
working group's charter.  I think that this input is valuable, and will
help us develop a more useful, complete standard for ADoT.  However, I
don't think drafts whose main purpose is to provide input to the standards
process are generally appropriate for working group adoption.

I fully expect that this working group will define a standards-track
proposal for ADoT, with recommendations that cover the questions you've
raised in those sections.  I think readers might well be confused if both
that standard and this draft were to be published with RFC numbers.


> >
>
> >Regards,
>
> >Karl
>
>
>