Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

Bob Harold <rharolde@umich.edu> Thu, 22 March 2018 17:04 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C153912704A for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 10:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 5BCstRxsEwTQ for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 10:04:44 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 52D0E126CD6 for <dnsop@ietf.org>; Thu, 22 Mar 2018 10:04:44 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id l4-v6so9921469lfg.12 for <dnsop@ietf.org>; Thu, 22 Mar 2018 10:04:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i8NYIl9jNr4b+HnuNupo/BFBGPHp7WH3p8IutNzTCQo=; b=LRuzS3sokvA0E54Er6JOE1jnY7zoC7n9DegTYcRKt6c9Tfp6gn0AKJ9XBQg0T10YVZ y/lYsSPNnzPBzouwXAhKDCNoSG0MMfflJ9yMKX0X6CtReAfCKjAF0wkvNuBmWKVImFWy 59uA8Nd/taX7J4d2WFe30DGYI+zyLYOFCHFr5vlE+ZgByi9LJUeV2ZKvsf+foS00bQ5n abbgw+7FXsociC6mt/hYGzQKPjpI9A1SIzIJ1a6rSjRGAhZNqCw8o931XOm4tgfjBfmy 4MIjVfJAUnFESNsV10rm836MvKrXtvaL+QfVFMNCB4UHJCQUEHWgY6TgoOitYb9xOsWk 12lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i8NYIl9jNr4b+HnuNupo/BFBGPHp7WH3p8IutNzTCQo=; b=fPCV5k6dkCdiDbIel+Nz+68/2nL2AX01ar3ig3GATYAkTeUuReeU1xh+FWfyHp5hzJ sX5WX/rMr82ijo8NornjxKZl42wFFttLiIbTA+iXNzr6I1i74CfW4lWm5XcgnpK+flNk DsOuuQHOHNaJSoOUUL+4TM0Cg2BrAX3h1MkTWSz2O9JaRA9i/ja+TLnyDi76PSbuZ3BY glLqCIigszsLBo5/TENl0/5zbaseFYKUNY46SlnpDO4x4GW6u9cyxKn6gUUsI9gxEXzy hz6nSuf+mpkzoFhcfUXeCkhUegsfC3JWhm0g4D+SOI6IWw9OiLHkehTMSu+KH/BtfA9/ +REg==
X-Gm-Message-State: AElRT7Hpx3kB6ewAq5IN22YH6vR5jpBjxvs3KT4C3qF1Hkcc7nGWrOyx GEX976+2ZHouYJ84igHW1feBZP1QTueM4h8yXT4/sw==
X-Google-Smtp-Source: AG47ELtfwK7OXXfLU6ah3CCSXtf1buB3ZghQ5hfrsDloGrqa1Opx5N21sn4UUWifA4kqS9OYrqXq/b+aPnm5y333vTo=
X-Received: by 10.46.127.30 with SMTP id a30mr2340046ljd.93.1521738282487; Thu, 22 Mar 2018 10:04:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.155.140 with HTTP; Thu, 22 Mar 2018 10:04:41 -0700 (PDT)
In-Reply-To: <23219.56569.2064.711002@gro.dd.org>
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <CAAObRXLm3c-p9rZkn6H6tcEoh3-UT5JW06NXQ_FMyyr2NFMmyw@mail.gmail.com> <23219.33838.166003.614689@gro.dd.org> <CAAObRX+xF5SwVd3x3iXSWd-A0Kpr_ubbOJzn0yTrSk8pc+tm6Q@mail.gmail.com> <23219.56569.2064.711002@gro.dd.org>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 22 Mar 2018 13:04:41 -0400
Message-ID: <CA+nkc8ANQh2wAr6==eNuM82mbD+E2ELzHGizdqF_sGdY-kkOqg@mail.gmail.com>
To: Dave Lawrence <tale@dd.org>
Cc: dnsop <dnsop@ietf.org>, doh@ietf.org
Content-Type: multipart/alternative; boundary="089e082f4198c4dfd70568034d9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qK8VVj3axsQTgv_GOxLeQDDjgUE>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 17:04:48 -0000

On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence <tale@dd.org> wrote:

> Davey Song writes:
> > To keep the transparency of DOH proxy, the proxy server should use
> > the same transport as the proxy client receive queries from
> > stub-resolver, transports patterns like UDP-DOH-UDP, and
> > TCP-DOH-TCP. So the proxy client should signal the proxy server the
> > initial transport recieve from stub-client.
>
> I'm really not digging this as a good use of a media type, especially
> when the draft says:
>
>   "If proxy client receives the query via TCP, then it
>    will carry a new media type defined in this document "application/
>    dns-tcpwireformat" and speak DOH with proxy server with the same
>    DNS query without the two-byte length field defined in DNS over
>    TCP"
>
> So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
> identical on the wire, and you're just using it as a signal for the
> transport you want the DOH Proxy Server to use when talking to a
> resolver (if indeed it is talking to separate resolver at all), is
> that right?  If a transparent DOH proxy client is talking to a
> co-operating DOH proxy server, shouldn't they have a better signaling
> mechanism than that?  Is there any other media type that directs a
> server on transport issues?
>
> The use case also doesn't really address why it is important to
> preserve the stub's udp-vs-tcp choice to its presumptive resolver, but
> rather only refers only vaguely to the transparency issue.  It would
> be nice to have a clearer statement of what's driving this proposal.
>
>
Unfortunately, the resolver needs to make decisions based on the original
transport, for example if the transport is TCP, it can send any size
response.  But if UDP, it needs to fit in a smaller size, and it often
sends less info in the response.  Likewise, session signalling,
anti-spoofing decisions, etc depend on the transport.

That brings up another question.  Would it also need to know the MTU of the
original connection, or any other info?  (Assuming EDNS is not used)  In
that case, a different media type is not enough, and we need to change the
format to add some 'header" info.

-- 
Bob Harold