Re: [Add] What to do in this potential working group

Ted Hardie <ted.ietf@gmail.com> Wed, 21 August 2019 18:11 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA0120DFA for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rsrI4zcJLKAL for <add@ietfa.amsl.com>; Wed, 21 Aug 2019 11:11:39 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 CF911120DE4 for <add@ietf.org>; Wed, 21 Aug 2019 11:11:39 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id j5so6437951ioj.8 for <add@ietf.org>; Wed, 21 Aug 2019 11:11:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DZiD/P5JBTbLMI4X3crrdtM268caiEMYP2dwmW8e7qg=; b=OgGaHuab2n7DrR13KUEEhL/PHHQnpAp/4MdYR5QAwnhDy/hNmA/znnPaNFMvlvpKVa vY3mps/sJ21IKcNNdJJpIEDFvaVu1FWoUipqxOXLKO8JarbNkL0jNe3LNhDyLp5F1m1P PYTkKaju7xzOjC0b5F+CnVm5i5obEmEgrHhvtvz64CsW8d4Vz3f3OcguY+lBS5Gh7/CJ PhBJ4cEH3hNIhwgBdFVyxGRcaDPT9QsrJrtEiT9iozBxO8hlQgBtOX7SmWG3IYUwaz2u T7x58iEu5iw36KSRbpgOvC/63jP5teHGihSWHNFWaA6CXFnhP4siYM6IaETXUmHctj8D aA+w==
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=DZiD/P5JBTbLMI4X3crrdtM268caiEMYP2dwmW8e7qg=; b=jXaikxpHNRyLV3XP0F0fH27t8Vtf+SY6lsGoc4LUBU6g1xCtQZ7NsrMGLS0sLTaah+ hw/bm6S0s471h9NUeT7x7x1FCjmDM3AGHq7Ha9uvWC1B4CpkjoMDKU19INGGRri8vCjD 4qj5k5BsiGq+7FloM5V67sDkFQas3JAjIBjHU3YlHNCl2uj7jCrHQnUmGwD8dBuISuEm /GRJSKzvlNipscv1wA4Kxw0Y67pPFYjiSceqli5ruerGks1fXdnmZs/J/LZH7mAB9znL zVUGGyADMANkNeAPRnwxnUyaRlQq/9y4/hYmlzyiwetwgnl9h0fgQHycLF33ofy1JFrk 3vpw==
X-Gm-Message-State: APjAAAUlXBXPBFtYVkC3utYQJMQ/m+RkoRJYUFRg0uacxGMaHCiBH9E2 jXxjglWOM3xaI0aPY897Bk4iEBln1kjAJiZoOHU=
X-Google-Smtp-Source: APXvYqw2yuvE0uMNslxGmFIwVNe2TVo4NIIO8q4W46Kpk2RKqUpc56Mte1X08pUKlOf03NtgaeKpG23sKlKfBYwHBzU=
X-Received: by 2002:a02:cc6c:: with SMTP id j12mr11103601jaq.29.1566411098855; Wed, 21 Aug 2019 11:11:38 -0700 (PDT)
MIME-Version: 1.0
References: <A1128702-1E19-4657-9740-E84AE09992F2@piuha.net> <CABcZeBMfOTjq-8hDDoKMtJvfHUA5nC8o60zuk-2Xe-ZhfwriJQ@mail.gmail.com> <766112E1-F532-4C6B-8CA8-A096671E02EE@piuha.net> <CA+9kkMAfuOwJu8_qJTuhAY4mUwR+tVUxr+k3QFHBk3byV672Ow@mail.gmail.com> <A7EA862E-8E80-40E3-834D-E628988C0A24@virtualized.org>
In-Reply-To: <A7EA862E-8E80-40E3-834D-E628988C0A24@virtualized.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 21 Aug 2019 11:11:11 -0700
Message-ID: <CA+9kkMDJmvRd7d-7iFySfrgkCP+sfj7vYwLAOFFRxT0vpFczXA@mail.gmail.com>
To: David Conrad <drc@virtualized.org>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001e9eb70590a481d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/_ZmI9wvmM4aVrSnKMhDTpBinZno>
Subject: Re: [Add] What to do in this potential working group
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 18:11:42 -0000

Hi David,

On Wed, Aug 21, 2019 at 10:59 AM David Conrad <drc@virtualized.org> wrote:

> Ted,
>
> Not Jari, but wanted to point out one thing:
>
> On Aug 21, 2019, at 10:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> The second threat model is that a resolver may provide an untrustworthy
> answer (e.g. captive portal). The use of DoT and DoH can help with this if
> the client device, application, or user selects a trustworthy resolver**
> and uses the TLS certificate to verify they have reached that service.
>
>
> You probably need to define “trustworthy answer” here.
>

I tried to finesse that saying by saying it is up to the client to decide
this.  If there is an objective reality to "trustyworthy answer", though, I
think "true to the data supplied by the zone maintainer" may still be it.
I'm not sure there is, though, if you have any belief in the use of the DNS
as a control surface.  In the case of household using a DNS filtering
service, the answer may be that the "trustyworthy" resolver provides the
data supplied by the zone maintainer after the application of the filters
to which the subscriber has agreed.


>  Traditionally, a “trustworthy answer” was the data originally supplied by
> the zone owner of the domain being looked up. DNSSEC was created to ensure
> this. However, network operators (e.g., CDNs) playing “stupid DNS tricks”,
> resolver operators providing filtering, etc. may have changed what is a
> “trustworthy answer” over the years.
>
> With that said, and assuming you’re using the traditional interpretation
> of “trustworthy answer”, then DoT/DoH do not ensure a “trustworthy answer.”
> DoT/DoH provide transport protection. The only way to truly ensure a
> trustworthy answer is to protect the actual answer. Which is what DNSSEC
> does.
>
>
Evidently I was unclear, sorry.  It doesn't assure you that the answer is
trustworthy; it can assure you have reached the resolver that you intend.
If you trust that resolver (for whatever value of trustworthy you have),
that may help.

Thanks for pointing out the lack of clarity,

Ted
(as an individual)



> Regards,
> -drc
> (Speaking only for myself)
>
>