[Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 28 September 2017 10:06 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9113463D; Thu, 28 Sep 2017 03:06:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: "The IESG" <iesg@ietf.org>
Cc: doh-chairs@ietf.org, doh@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 03:06:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/U8VhKqGFjKYr82U_4icN6O2eso0>
Subject: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 10:06:54 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-doh-00-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


In my first ballot, I mentioned "What I've been failing to understand from the
charter is the rational for DNS over HTTPS? Can you expand on this." Because
I'm not an Web browser and DNS expert, or most likely because the concerns were
not clear in my head, I could not clearly express my thoughts.

So I watched the IETF mailing list with attention.
Mark Nottingham's email summarized the situation

    It's not a matter of constraining the work; the work isn't proposing to
    operate even remotely in the way that you describe. I think we're just
    having a misunderstanding, because people have multiple use cases in mind
    for this protocol, and properties thereof have been mixed up.

    AIUI those use cases are, roughly:

    1. Configure your browser/OS to use a DOH service for DNS resolution (as
    above) -- this will affect browser/OS state, because it's being used for
    DNS; however, it's not being done from JS.

    2. Call a DOH service from Javascript (for some reason) -- note this is
    just like any other HTTP request; it doesn't affect browser/OS state
    outside of the same origin model. Yes, you can still build a
    browser-in-a-browser and mess with things inside that context, but that's
    already true today.

    3. Future handwavy things like making DNS updates over HTTP -- very
    ill-defined and not important for this discussion

Expressing #1 and #2 in the charter would have helped me. #2 is kind of present
now. What about the addition the notion of "browser and/or OS" in the next

The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients and Iterative