IETF Logo Mail Archive

Re: [Doh] WGLC #2

Tom Pusateri <pusateri@bangj.com> Wed, 23 May 2018 21:53 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8299A12D7F0 for <doh@ietfa.amsl.com>; Wed, 23 May 2018 14:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 CqbTTW5cyiKU for <doh@ietfa.amsl.com>; Wed, 23 May 2018 14:53:34 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD85912D7E6 for <doh@ietf.org>; Wed, 23 May 2018 14:53:34 -0700 (PDT)
Received: from [172.16.25.109] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 180C58B6; Wed, 23 May 2018 17:52:00 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_136F8290-5062-436C-9E3C-69978EE11E5D"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 23 May 2018 17:53:32 -0400
In-Reply-To: <CAOdDvNrW0qGn1V1s+fWhtn+LV-YiNEu66wp030_Jv-7EW2WhgA@mail.gmail.com>
Cc: Sara Dickinson <sara@sinodun.com>, DoH WG <doh@ietf.org>, "Hewitt, Rory" <rhewitt=40akamai.com@dmarc.ietf.org>
To: Patrick McManus <pmcmanus@mozilla.com>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <CAOdDvNrW0qGn1V1s+fWhtn+LV-YiNEu66wp030_Jv-7EW2WhgA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/7ZYYUpyGdYLpnL9ya4iN8Hki-GQ>
Subject: Re: [Doh] WGLC #2
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Wed, 23 May 2018 21:53:38 -0000


> On May 23, 2018, at 5:44 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> 
> 
> On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <sara@sinodun.com <mailto:sara@sinodun.com>> wrote:
> 
> 1) I previously asked if this spec required that a DNS API Sever should only be used if authentication of the TLS connection was successful. I got conflicting answers from Paul and Martin (‘No we can’t say that’ vs ‘authentication is critical and implicit’) and don’t see anything in this version that resolves this. I know there is other work attempting to address this issue (and more) but the lack of clarity in this document on the topic is still an issue for me. I’d still like to see a single sentence that either
> - makes clear the requirement (preferable) or
> - states that this is out of scope
> 
> 
> Martin is right - I'm not sure where the confusion originated. Authentication is part of HTTPS. I know dprive went down the road of opportunistic security, but that's not something HTTPS does. (plaintext http:// might, but we're pretty clear about doh steering clear of that.)
> 
> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186>
> 
> does this work?
> 
>  -DNS API client MUST only use a DNS API server that is configured as trustworthy.
> +DNS API client MUST only use a DNS API server that is configured as
> +trustworthy. {{RFC2818}} defines how HTTPS verifies the identity of
> +a connection with the trusted service.

How do you define trustworthy? This seems like it would vary for different clients and servers in different environments.

Trustworthiness isn’t binary although somewhere along a sliding scale, it crosses a threshold where you are willing to configure it. But that threshold is different for each client / user.

I don’t think trustworthiness is something the document can require,. especially with RFC 2119 language.

Tom

v2.23.0 | Report a Bug | By Email