Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

Ted Lemon <mellon@fugue.com> Mon, 25 March 2019 16:23 UTC

Return-Path: <mellon@fugue.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 237D81203FF for <doh@ietfa.amsl.com>; Mon, 25 Mar 2019 09:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 3rX2R37sKD6v for <doh@ietfa.amsl.com>; Mon, 25 Mar 2019 09:23:22 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 068AA1200B3 for <doh@ietf.org>; Mon, 25 Mar 2019 09:23:22 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id z11so9688307wmi.0 for <doh@ietf.org>; Mon, 25 Mar 2019 09:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lOX8nyj8nI7PG5DbqFDxUspwdSvdjF9AiuOAtY+F/ew=; b=C2qx1A4VqlaewkLVm1Bo+JFrp7R1iNnSTbPbYXoe36Ug4UU91wUavwLHFh8BXTHGy4 DA4GZe0KlFrwoBAI++mrfn+TiOI/todJcpk8RoJf7PJmKaBWYCbGns6GFMEjPIpY00Ux 9f3Y7B5Q43EI5beCqDXZw5b2SGG8bnaus6c5b12c4QmxJ6vp9Ga7XCJflTr/cSUBXnvx i96eosgA4TUrI+FnJHeITpNTXBE7/pg1a5W+yYG5ek2wq6ppXA/rA/tQubDlGhcB1xiD bO5j/f7WxvmVkEKTTe+TRv97JSBPqKipg2lZAgAgj5NovamvDgDECOUmFbxdA11kkL8T U5pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lOX8nyj8nI7PG5DbqFDxUspwdSvdjF9AiuOAtY+F/ew=; b=KxdiwQs8eocc9V4J3CVUY28SqbiGSyd/9OYmVLOxvPNTj79uEbtfDarMPCQMWdaFy8 Jix3DxigknpMTYY8tLcy6pNESAlF/DmxCGfKY76zRCp/3k90cwUX/Vtz7mmQcFdpOlGC zNr1kdZggxRDMYJVkA18izaFWVVeOpVkGiEFdMk+4odAzU/loX3DRj9I7xHEM/g4pOkn eOLAxWobFLXLzvZCK+O0Dl4bYGnZX3Z/0T6a79IDvGlAez9xNLLc/MiSN2exFzOHw/ut M2sKrBKMgbm6Njg85LUpz+tzbxPXaKNb8M6yq18N1DVvYRN74o3Liz3xUjm0ToHownDa D+Ug==
X-Gm-Message-State: APjAAAWiLQlKUtLGmDcJLc6cSEEV4kRNLn6Ug4gUaLPKm3g+EoCTql9v NC4UsZ8yYXKZA0oja4x/fLMbmY4wJeF3PoB3
X-Google-Smtp-Source: APXvYqy++iIWjhShlrMXWXyGMnJS44AwWRtDQiVINp/XorPikZnBvYz028p+kZL/t+hrULbCFVxhLQ==
X-Received: by 2002:a1c:d106:: with SMTP id i6mr11156615wmg.134.1553531000450; Mon, 25 Mar 2019 09:23:20 -0700 (PDT)
Received: from dhcp-889a.meeting.ietf.org (dhcp-889a.meeting.ietf.org. [31.133.136.154]) by smtp.gmail.com with ESMTPSA id d6sm18158670wrx.62.2019.03.25.09.23.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 09:23:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <alpine.DEB.2.20.1903251554300.13313@grey.csi.cam.ac.uk>
Date: Mon, 25 Mar 2019 17:23:17 +0100
Cc: "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <394A2493-4C87-41C7-9B9E-57441E4F673E@fugue.com>
References: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net> <1878722055.8877.1553241201213@appsuite.open-xchange.com> <CABcZeBPmpN-cEPK92QQW3bkvc41Cx5g7B_YuUXCJK3j1qF995Q@mail.gmail.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <CAOdDvNqb2+4Az+g608QRjYt+ZdUt1L9GAc=MJM3-xd0ZNmeBEQ@mail.gmail.com> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> <CAOdDvNrQiM2bpi65tCvwjanQTM1KtcZjRL0aOwS2oAryTR-YEA@mail.gmail.com> <E7E54A3B-4C85-4B64-BEFD-51891534DC9D@gmail.com> <CAOdDvNqKja9SRWa7FpjnGR3XZbVwZbitoU0yuWc+oXw3xXFEQA@mail.gmail.com> <CAH1iCirtvx2eipt65+TbazZ1f4uKiu6HA2PjVmPiAkGjN-hbEw@mail.gmail.com> <CAOdDvNoKGVhNkdacKUTefa40f_spxjvmDsbd5g78+A9TBuUdKg@mail.gmail.com> <CAH1iCirbM=8NJhAqS73+hF824z--8-gYmg55Phq9i-S7X4SoDA@mail.gmail.com> <CAPt1N1kpuCkpJyuMiVRnnbw+aUMFeo7xzOguxXvw80iuHHtoBg@mail.gmail.com> <alpine.DEB.2.20.1903251500480.13313@grey.csi.cam.ac.uk> <A4378E9B-4219-4C4E-BEE0-695E3B5BCD8F@fugue.com> <alpine.DEB.2.20.1903251554300.13313@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/lP30P_br9CBsVfs8PF-7PaQM2Ho>
Subject: Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Mar 2019 16:23:24 -0000

It seems like SACK would make the problem less bad in theory, but wouldn’t eliminate the problem.   With DNS-over-DTLS, if a packet is lost, the next packet still gets an immediate answer, because DTLS is a datagram protocol, not a stream protocol.   The retry strategy for DNS-over-DTLS would be the same as DNS-over-UDP, once the Diffie-Hellman shared key has been derived.   So assuming you are using this to communicate to a resolver, there would be an initial handshake that’s extra compared to DNS-over-UDP, and then it would just be DNS-over-UDP until such time as re-keying is needed.

> On Mar 25, 2019, at 5:13 PM, Tony Finch <dot@dotat.at> wrote:
> 
> Ted Lemon <mellon@fugue.com> wrote:
>> On Mar 25, 2019, at 4:04 PM, Tony Finch <dot@dotat.at> wrote:
>>> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
>>> application protocol. The DNS has horrible packet size problems, so it
>>> needs a lot more help than DTLS provides. QUIC is much better.
>> 
>> Indeed.  My point was simply that this avoids ordering problems, just as
>> QUIC does.  I suspect that it is worth having DNS-over-DTLS; QUIC is
>> great, but based on what I’ve been seeing, quite a lot, and probably not
>> appropriate for a lot of use cases where DNS-over-DTLS would do just
>> fine.
> 
> It isn't so much ordering that is the problem, but not delaying answer B
> when answer A suffers packet loss. I'm kind of curious about what the
> relative trade-offs might be between DoQ and DoT with a decent SACK
> implementation, when there is not much latency between the client and the
> resolver. DNS-over-DTLS will need its own application layer retry
> strategy. I kind of prefer the idea of DNS being able to re-use a good
> off-the-shelf transport protocol rather than doing its own thing.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good.