Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
Matthew Pounsett <matt@conundrum.com> Wed, 20 March 2019 20:08 UTC
Return-Path: <matt@conundrum.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 49B3D131084 for <doh@ietfa.amsl.com>; Wed, 20 Mar 2019 13:08:43 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 iMPsaX2xIjXs for <doh@ietfa.amsl.com>; Wed, 20 Mar 2019 13:08:38 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 A847E1277CC for <doh@ietf.org>; Wed, 20 Mar 2019 13:08:38 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id w15so880532itc.0 for <doh@ietf.org>; Wed, 20 Mar 2019 13:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nF6vbHAIGBtbzZxLmLxnins9oJ+xUCo37ezMJVt+EdE=; b=KRkrBa++x3OxvtOthjxReKJ860Bwr08Iwil5SMIf2+BNaVWP222ApaVTXUq6tAVPwe SYl1CZ/SuJoqIK0GOYyeMabdfR2UMp1ihHvvL1gMX2GzmvQm3d6YtWy9Zjn0UGAp3X4b KrH60bJjiI0W6O+rXG8Up38TZhJxdBTWS0Cnj+tPJLoFMQioAx/tbLypHBOQJEgO5Cw5 vsePk2lz9TbkRF2LX7UsRNEZeDKHdFW4zPpjVF5B3CoUaJ7YC/F/SUfSkkWMMdV7zWGc S2ij+Y9Ti6j5DMhz8R9x32yII6ABxek2igE0eRdUCZlLq0gf3zK5robmU9QyDkUwndxu 5ucg==
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=nF6vbHAIGBtbzZxLmLxnins9oJ+xUCo37ezMJVt+EdE=; b=C6LwUVgWiqUantY+GTUBrXbjDXrEudJAZS/097XozusWkpUHxt05RxYV461C5mnef/ y+SR6kIwDcbLJKCuDolFYy0EQ2rDBEdg/VcGzTf7QDveL9Tjrm77fzKjdmBLgK3MJFiT 0Ht3+1vvrAknYfNBaIMFc1zDaOrlsJnyUG/Zr8p8wlPaClDnnOAUhWv8s8wuVJLElIdK yY+K3XjnixhXUL8EYuuB5GY3mE2FhCEFxyWg5rB53mQi60lnjnL2SUwiW71qsExyXFSI 16bnhNnAZrEG/5XMktZ4AAKqRmkEiDTuJuxGqHp2eFapjDlDLlJ7w2OqNClToRXsvvN9 VlOw==
X-Gm-Message-State: APjAAAWopjZAwkgysIZmBWBVV9Jp8sE/66WO/C0ASRzkkegklkgTLQYu RDYDrMbvTVkGE90cpIFRxQUpeyZL6JNIbVikcXRLDQ==
X-Google-Smtp-Source: APXvYqz1c73Jnlk+oLIFH1x7p79sX++76LJjTnLUkwsv2gVp6UoLa4NB0RyWQBuMn/XHNc2aCoFHDqUASNShob3JfV8=
X-Received: by 2002:a05:660c:a18:: with SMTP id e24mr93791itk.129.1553112517889; Wed, 20 Mar 2019 13:08:37 -0700 (PDT)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <1900056.F7IrilhNgi@linux-9daj> <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com> <CAAiTEH_umx5Xqa24TywQ_BX_Lpo6piwRWPLWhADkh-PnM20vcg@mail.gmail.com> <CA+9kkMBXgPHmLRV44Qen_xm1G+Xerb5WJ0JvL11U3XayVgTHfA@mail.gmail.com>
In-Reply-To: <CA+9kkMBXgPHmLRV44Qen_xm1G+Xerb5WJ0JvL11U3XayVgTHfA@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 20 Mar 2019 16:08:26 -0400
Message-ID: <CAAiTEH9iD_PzhZDYc9jd-7_D2_4ZeT_v+EB2RxvKTGBYVukX-Q@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ecf05a05848c2f6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/iMBfcChz7HwXVXbyg9wZKPcVXeE>
Subject: Re: [Doh] [DNSOP] 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: Wed, 20 Mar 2019 20:08:43 -0000
On Tue, 19 Mar 2019 at 13:45, Ted Hardie <ted.ietf@gmail.com> wrote: > >> I have a relationship with my users and I can control the configuration >> of their *known* applications. I do not have a relationship with the >> malware author that is trying to steal their data, and cannot control the >> configuration of that (unknown) application. By running DoT on my borders >> and blocking all other DNS and DoT traffic, I can provide privacy for my >> users while still preventing malware from doing its thing. >> > > As I said to Paul, I don't think you can if your only defense is blocking > DNS access. Coding a system to use a non-standard resolution protocol over > TLS is relatively easy; all the malware needs is a specific target to start > at. That target can be hard coded, derived from the output of a web > search, or produced by the output of an algorithm resident in the malware > and some system-available data (commonly the time). My apologies if I have > misunderstood your point here, but unless you also block all traffic for > which you have seen no resolution event, I believe that it is entirely > possible to circumvent the defense you describe. > I think you need to understand a bit of the history of malware development and the arms race to block it. Malware C&C started out at hard-coded IP addresses. They quickly realized this didn't work because going to a single address for your C&C is easily spotted, easily filtered, and easily taken down. So they moved to using domain names and DNS; they could change the IP addresses that their C&C domains resolved to very quickly, and move C&C around, avoiding takedown. After a while, the domain sales business got better at domain takedowns, and so malware developers moved from single domains to DGAs. Which is where we are today. Using a hard-coded endpoint for domain resolution, even if it's TLS encrypted, is as easily spotted and dealt with as using a single hard-coded endpoint for C&C.. it can be filtered as soon as the anomaly is detected. Using DGAs to bootstrap such hidden resolution systems has the same limitations as DGAs above. It's just adding an extra layer of abstraction, using identical systems, over the C&C in the first place. The fact that they are NOT doing this today, even in the face of domain reputation systems and RPZ feeds should tell you something. I'd bet any malware author who's though of doing what you suggest got at most a few dozen lines into writing the code, realized they were just reimplementing their existing C&C, and stopped. > > >> With DoH available at endpoints that my users want to reach using some >> other application, >> > > And this is the critique that is not of DoH as a protocol, but of a > specific deployment possibility. You've seen the Quad9 folks point and the > Chrome statement of their current deployment plans. The first said they > will not deploy DNS resources and other web resources on commingled hosts. > The second said that they will only use DoH after a probe reveals that it > is available *at the already configured DNS service*. This is entirely in > line with Section 3 of RFC 8484: > Quad9 and Chrome's current policies are no guarantee of their future policies, nor the policies of other major browser developers or web properties. I cannot assume a statement made by either organization is binding on the entire Internet. When have you ever seen the Internet writ large choose NOT to do a thing that was enabled by the technology? The protocol enables (and even encourages) the deployment possibility, so why shouldn't I expect it? As soon as DoH the protocol is in GA codebase of major web browsers there will immediately be enough uptake on DoH server operation to enable the thing operators are concerned about. And remember, the protocol is DESIGNED to inhibit interference by hiding resolution streams along side other, less easily blocked traffic. You seem to be making the argument here, "don't worry, you'll still be able to interfere with DoH resolution by clients you don't control." If so, that is disingenuous at best. > A DoH client MUST NOT use a different URI simply because it was > discovered outside of the client's configuration (such as through > HTTP/2 server push) or because a server offers an unsolicited > response that appears to be a valid answer to a DNS query. This > specification does not extend DNS resolution privileges to URIs that > are not recognized by the DoH client as configured URIs. > > > Browsers do not have an incentive to permit random websites to poison > their caches, so I strongly suspect that there will be no ability to pass a > resolution done in JavaScript down into the browser cache; my experience > during RTCWeb was that the browsers treated all downloaded JavaScript > applications as potentially malign. > As I (and others) have stated several times, browsers aren't the ultimate problem. They will be configurable and thus controllable, when they're cooperative. It's the uncooperative clients that are the problem, but they're going to be enabled by adoption by the browsers. > it is orders of magnitude more complex for me to block the malware while >> still allowing my users to reach those endpoints. Phrased another way, a >> DoH endpoint at the same IP address as a popular website gives malware the >> ability to resolve names I was previously able to prevent. >> > > In the RFC 8484 terms, this is a DoH server. For this threat to be real, > there is an additional requirement: the DoH server at the popular website > must also be trusted by the application as a source of DNS data. For the > ones you configure, this remains in your control. For JavaScript > applications within browsers, see above. So this is probably the case only > for pure malware, which already has other circumventions available. > I wish you'd name those other circumventions. A large part of edge security these days is predicated on the ability to control malware's ability to resolve C&C names. > >> The only recourse I know of, if DoH is adopted, is to proxy all traffic >> toward that example site (including requiring me to engage in a MitM >> decryption attack on my users' web traffic) in order to continue to prevent >> that malware from circumventing network security. And because I can't >> predict which web sites will launch their own DoH endpoints, that means I >> need to proxy (and decrypt) all web traffic in order to maintain the same >> level of security I can today. >> >> Note that popular Web servers commingling DoH services should answer a > DNS query probe, so you will be able to tell readily if any of them choose > to do it. And, of course, you could respond by blocking the service rather > than with MitM; I suspect some would. > I can't afford to probe every IP address on the planet on a regular basis, and dynamically modify my blocking based on that. It's far, far less expensive to just automatically MitM all web traffic on my network, even though that is far more expensive than what I have to do today.
- [Doh] New I-D: draft-reid-doh-operator Jim Reid
- Re: [Doh] New I-D: draft-reid-doh-operator Warren Kumari
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [Doh] New I-D: draft-reid-doh-operator Jim Reid
- Re: [Doh] New I-D: draft-reid-doh-operator Ask Bjørn Hansen
- Re: [Doh] New I-D: draft-reid-doh-operator Livingood, Jason
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [Doh] New I-D: draft-reid-doh-operator Warren Kumari
- Re: [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [Doh] New I-D: draft-reid-doh-operator Jim Reid
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- [Doh] GDPR and IETF protocols (Was: New I-D: draf… Stephane Bortzmeyer
- Re: [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [Doh] GDPR and IETF protocols Jim Reid
- Re: [Doh] New I-D: draft-reid-doh-operator Livingood, Jason
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Michael Sinatra
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Winfield, Alister
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ralf Weber
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Lemon
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Martin Thomson
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Winfield, Alister
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eric Rescorla
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Adam Roach
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Christian Huitema
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator nalini elkins
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Joe Abley
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Adam Roach
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator 神明達哉
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jim Reid
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eric Rescorla
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Winfield, Alister
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator sthaug
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Joe Abley
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Winfield, Alister
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Joe Abley
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Bill Woodcock
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Livingood, Jason
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Joe Abley
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Richard Bennett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Patrick McManus
- Re: [Doh] [EXTERNAL] Re: [DNSOP] New I-D: draft-r… Patrick McManus
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Vittorio Bertola
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Paul Wouters
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Olli Vanhoja
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Daniel Stenberg
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Mark Andrews
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Ian Swett
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… sthaug
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Valentin Gosu
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Martin Thomson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Stephen Farrell
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Petr Špaček
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… Paul Vixie
- Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy