Re: [Doh] [EXTERNAL] Re: New: draft-livingood-doh-implementation-risks-issues

"Livingood, Jason" <Jason_Livingood@comcast.com> Mon, 11 March 2019 01:49 UTC

Return-Path: <Jason_Livingood@comcast.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 E77DA130DD8 for <doh@ietfa.amsl.com>; Sun, 10 Mar 2019 18:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=comcast.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 v0BpAgXxbq-U for <doh@ietfa.amsl.com>; Sun, 10 Mar 2019 18:49:34 -0700 (PDT)
Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410A312EB11 for <doh@ietf.org>; Sun, 10 Mar 2019 18:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190220p; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1552268971; x=2416182571; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q+8PWAm66fDjLmwJZhdrFUKpy9tb0ldTIVEys+LK12A=; b=QnngcW8xEdyczouch/97yVPjUrhbadg9tKxZp9Y9NwDXpksmIAOTPchAXeX8Nslt u2CNUYwfYTOCxKFIyy/KD5k1Jz5+ZdVJYGRGk99OHeTwnzPKy4D1P2s7z3TGMMAq c8zCC8pMj0I/Sz/7ZjtQc7k910oebQ5ae49Qs1jPNpUmIQs60hKUS6iLBtZrqAN6 /7rJ5+xD4KyNvHwxQJfl2fdk6VAbhb2cpHKVUkygW0cEN9V3eZ5WHKKzuVl6EBe5 va8x0TggAUnIZqFGYPnj8WjDLhPcaLSz9f905dMw7lX46mnla9obsSgSRXxARI6f wgLRZl562k1lZtJvr3l+aq+K9mpBbupCzFmlvoilhBNdV9Q0ozWLCrXFJVJ6VRwC V7K8QVz4VykzYMHld7T8+rrPxRiaY9rySSk3DGN3UxqMPCUGUpV/f8ALFToLqx0E /SIFRyfcy9T80QajLyXrO4NyySAJdvdems0bA8vcTiwcCZWvHBl9fnH93zsRb7Zb aDZlQjunzk9piqtHti2sit4u3IGMqvLh8ZZAs/S71JkYAWFehJCWdNsEIXVyAjgc +XZEJ44/Kh+XooAha1MBSqyZmJ0MSXF0OgeZ49FfKbNV4jbtx5Hz7XCfJd43SXdW 1xjGnem2aqECxQBCTSDFZvCNohbAkroUuk7oaBbdAi8=;
X-AuditID: 60729ed4-2e5ff700000044dc-80-5c85beabbd2f
Received: from COPDCEXC38.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id DA.1E.17628.BAEB58C5; Sun, 10 Mar 2019 19:49:31 -0600 (MDT)
Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC38.cable.comcast.com (147.191.125.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 10 Mar 2019 21:49:30 -0400
Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Sun, 10 Mar 2019 21:49:31 -0400
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Doh] New: draft-livingood-doh-implementation-risks-issues
Thread-Index: AQHU1hbDDNj2GhBc2k6lTCYNWHxRBaYD846AgAG5mIA=
Date: Mon, 11 Mar 2019 01:49:31 +0000
Message-ID: <BAB74C4B-D93A-4EBA-8F76-FEC4C68FF753@cable.comcast.com>
References: <EA2A119D-06CF-4B0B-8994-86A99CD8AC0B@cable.comcast.com> <20190309182857.GA29321@laperouse.bortzmeyer.org>
In-Reply-To: <20190309182857.GA29321@laperouse.bortzmeyer.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [96.114.156.7]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9A16A3CBCAC25C4A998A4E00C29155D5@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsWSUDRnsu7qfa0xBjP2WFlMWPiS0eLa3Yts DkweS5b8ZPKY+G8DUwBTVAOjTUlGUWpiiUtqWmpecaodlwIGsElKTcsvSnVNLMqpDErNSU3E rgykMiU1J7MstUgfqzH6WM1J6GLKOPxEteCMWsXBZd1sDYxnVLsYOTkkBEwkll+9z9rFyMUh JLCLSeLCnn9sEE4Lk8SKy8uhMqcZJY7d/M0K0sImYCZxd+EVZhBbREBbYvLNHkYQm1lAUuLR 8UPsILawQIRE8/GlUDWRElf3T2eEsK0kWnrng8VZBFQlzq/8DmbzCrhILDn/lA3EFhKokDh7 fgXQLg4OTgE7ibenEkHCjAJiEt9PrWGCWCUucevJfCaIDwQkluw5zwxhi0q8fPwP7ExRAX2J LX0PWCDiChI9E6Yzg4xkFtCUWL9LH8K0klhxRw9ioqLElO6H7BDHCEqcnPkEqlNc4vCRHawT GCVnIVk8C2HQLIRBs5AMmoVk0AJG1lWMfJZmeoaGJnqGphZ6RoZGmxjBiWfelR2Ml6d7HGIU 4GBU4uFt39EaI8SaWFZcmXuIUYKDWUmE994qoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe9c1A KYH0xJLU7NTUgtQimCwTB6dUA2Ndjs7qYtsWWYVuK+GyzLLs+2kTl13+8D7TZE1t9rbtAexe fjlC3WJJgZr/+jSULPgtt99QDXroWcd7x+1MneubU7d2N/E1RJuK+BnNfV+n1/i3Sfz77jLF I6ZOd5YKyvV/2hagIPTi1n7fptTUaTzHy0S3XFW3is0XnHutkefQ6mVRF1cGKrEUZyQaajEX FScCAGxvn5g4AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/C_NWjF-veHCpl3UKxIFN2DJ8cxI>
Subject: Re: [Doh] [EXTERNAL] Re: New: draft-livingood-doh-implementation-risks-issues
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, 11 Mar 2019 01:49:36 -0000

On 3/9/19, 1:29 PM, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:

    >> Network operators, ranging from ISPs to enterprises, schools, and
    >> others work hard to provide outstanding DNS and network performance,
    
    > Nice but clearly false. One of the reasons why many users switch to
    public DNS resolvers is because many local networks and ISP do a lousy
    job (specially in some parts of the world). Not to mention those who
    simply announce 8.8.8.8 trough DHCP...

[JL] It is my experience as an operator that it is indeed *not* false, else I'd not have written it nor would many ISPs with similar concerns not agreed with the statement. The key perhaps is that I didn't say *all* of course - but it sure seems like we're nit picking here. I don't disagree that in some parts of the world and in some networks that DNS operations could be improved. But I certainly think you can concede generally speaking that networks (of all types) strive to maximize performance & reliability, and this usually includes good DNS services. 

   > > the current Centralized DoH implementation model does not appear to
   > > make it possible for these operators to continue to play a value
   > > added role in the delivery of network services
    
    > Some people may consider that this is not something we want from the
    ISPs. "value added" is often the code word for violations of network
    neutrality.

[JL] It is not what is intended in the document but your perspective on that issue is noted.

   > If you care only about bytes, video
    providers will always win. But other metrics could be used: is a video
    of a cute kitten more important than a PDF document which is a
    multi-million dollars contract?

   > > The Dyn attack provides a vivid illustration of how DNS
   > > infrastructure vulnerabilities - and DNS space concentration - can
   > > wreak havoc on the stability of the Internet."
    
   > Is it really relevant, since it was an attack on authoritative DNS
    servers? Having lot of local resolvers would not have changed its
    consequences.

[JL] Yes, it suggests that when a provider handles rather a lot of a particular protocol that an outage or attack on that provider can have a significant impact. The quoted paper uses it as an example of the larger issue. 

   > > DNS blocklists, which are one of the primary and most effective ways
   > > to protect a network and its users against malware, phishing, spam,
   > > DDoS attacks, etc.
    
    > Can you explain how a blocklist on the DNS resolver protects against
    spam and dDoS?

[JL] Quite a lot of spam and DDoS traffic emanates from botted hosts. To the extent that you can prevent malware infection, detect and remediate infection, or detect and/or interrupt command & control traffic then you can have an impact on spam and DDoS. 

  >  > Loss of Parental Controls or other Content Controls
    
   > The draft seems to assume that lying DNS resolvers are a good thing
    (politically and technically) but I don't think there is an IETF
    consensus here.

[JL] I totally understand the 'lying resolver' perspective. But we need to be realistic about how technology is ultimately used. Many people have young children and may want to filter what content they have access to at home. And schools for young children may similarly want to block certain content from school. Or want to ensure their devices aren't talking to well-known malware C&C servers, etc.

Anyway - thanks for your review and sharing your thoughts!

Jason