From nobody Tue Apr 1 14:43:19 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365B1A0A0A for ; Tue, 1 Apr 2014 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cE17gTBacaS4 for ; Tue, 1 Apr 2014 14:43:16 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id B188E1A089A for ; Tue, 1 Apr 2014 14:43:16 -0700 (PDT) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id 1E8C322901 for ; Tue, 1 Apr 2014 14:43:12 -0700 (PDT) From: Wes Hardaker To: dns-privacy@ietf.org Date: Tue, 01 Apr 2014 14:43:10 -0700 Message-ID: <0lmwg4680h.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/jb7CduWLnJIGtLNEmIBz9CKGLPY Subject: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:43:18 -0000 The problem with other solutions is that you (a DNS user) must trust someone not to have been hacked or to sell you out. This solution is a super-hack, but shows the type of architecture needed to ensure that no entity but you knows both: - who made the request - what the request (and response) contains Anyone that knows both is a potential point of compromise. http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ Warning: the security in here is not. -- Wes Hardaker Parsons From nobody Tue Apr 1 14:46:26 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4791A0A18 for ; Tue, 1 Apr 2014 14:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 m2hiu0BhPUso for ; Tue, 1 Apr 2014 14:46:22 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE991A0A0C for ; Tue, 1 Apr 2014 14:46:21 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uy5so11757858obc.6 for ; Tue, 01 Apr 2014 14:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9nCeHhSf6dVjnwIfpS/240XqvUZsJJqI/anZmR++PlI=; b=eh9KMfvN4bsp0PXNcd/q6w8GgPMJKkoYZrpY6YKLAMqMwKD6WHdaaW6Qqrf56j9Q0A Oh4Gbr/oU8pj0hhRlrA3iI/BstARvN7XdthNSk8uDp1VtmrkeT4BiJJXTwcgpnbxEM29 kGqVDU0Fshoh1D/0sqhwciYEOwEqCS4RMuog8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9nCeHhSf6dVjnwIfpS/240XqvUZsJJqI/anZmR++PlI=; b=YCqz8Gd8YNFHERXBhqFCFchXax5cqECAQlkapKb4U1IIHfgijEbWXQ8MjZtaf0SDRC QxNc5DEqcbEeMbS+OF/DRQRryOEPhnsujoutxzcmwCW7r5Qg8GTC8K/+sexaFpnjB9V4 6mWs6p0vTmeSGxxVUvcEcoU0oeTpylk4T7fTr++GkU3mcaIvEXdG4Enviavukakid9fa zdiGJF2Mzi+hXCDT0TetkYYCvqBSYVijqQGDFCqk4PVJUtvzoatEkardm6ySQCu4m7kG 7rS1AZSh0dbcQ1NtizimTJHX6J8BWdtoicRPsE7Wh7RhzrVxamChWk+1o1/0TkXzssTK urMg== X-Gm-Message-State: ALoCoQny/a/F+h68R9IFozLr8LuZsa990m45QqN1CdCtta3c2d0ZX5YIgi8x7kAGCr0+ModM/1us X-Received: by 10.60.63.12 with SMTP id c12mr30454973oes.23.1396388778052; Tue, 01 Apr 2014 14:46:18 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:ad2e:b401:7b1:45bb? ([2001:4900:1042:1:ad2e:b401:7b1:45bb]) by mx.google.com with ESMTPSA id j9sm32027688obh.23.2014.04.01.14.46.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 14:46:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Abley In-Reply-To: <0lmwg4680h.fsf@wjh.hardakers.net> Date: Tue, 1 Apr 2014 17:46:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <35BBE7CD-9994-41EA-A6E7-2D5777141CD7@hopcount.ca> References: <0lmwg4680h.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/YEdVI0RfEslJWjqdwQxv0os0OUc Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:46:24 -0000 On 1 Apr 2014, at 17:43, Wes Hardaker wrote: > The problem with other solutions is that you (a DNS user) must trust > someone not to have been hacked or to sell you out. > > This solution is a super-hack, but shows the type of architecture needed > to ensure that no entity but you knows both: > > - who made the request > - what the request (and response) contains > > Anyone that knows both is a potential point of compromise. That was the basis of our onion-smelling proposal, too: http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00 This document describes an approach which separates the data in DNS queries and responses from the identity of the DNS resolver used by DNS clients. [...] This is an incomplete proposal. It has been distributed in its current form for the purposes of discussion, such that the high-level approach can be considered amongst other options in the general consideration of DNS privacy. The authors have called out particular gaps in this document. The authors are confident that there are many other gaps that have not been mentioned. The absence of a description of a gap in this document does not imply there is no gap. Contents may have settled in transit. Your statutory rights are not affected. The origins of this document lie in a beer-soaked afternoon conversation in the lobby bar of the Hilton Metropole, London, UK. Should this document play any future part in preserving human life or dignity, the authors recommend the installation of a small but elegant brass plaque, the text embossed upon which should naturally be encrypted. Joe From nobody Tue Apr 1 14:47:45 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430291A0A1A for ; Tue, 1 Apr 2014 14:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oiL7qJVKUov1 for ; Tue, 1 Apr 2014 14:47:42 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id AE96D1A0A18 for ; Tue, 1 Apr 2014 14:47:41 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7AA5A23E2AB2; Tue, 1 Apr 2014 21:47:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2OWzCujVox8; Tue, 1 Apr 2014 23:47:35 +0200 (CEST) Received: from kopoli (g226178137.adsl.alicedsl.de [92.226.178.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 5E1D923E2A86; Tue, 1 Apr 2014 23:47:35 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Wes Hardaker'" , References: <0lmwg4680h.fsf@wjh.hardakers.net> In-Reply-To: <0lmwg4680h.fsf@wjh.hardakers.net> Date: Tue, 1 Apr 2014 23:47:35 +0200 Message-ID: <009501cf4df3$fe95b710$fbc12530$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDJFXm1B2p2SDW1HPGbRG9mHYlKPp0JvJsQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/QzkzIX4FaSye52ZZ5t6tk5K6n1M Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:47:43 -0000 > > The problem with other solutions is that you (a DNS user) must trust someone > not to have been hacked or to sell you out. > > This solution is a super-hack, but shows the type of architecture needed to > ensure that no entity but you knows both: Not all solutions.... This is not actually a problem with CGA-TSIG. :-) Hosnieh From nobody Tue Apr 1 15:43:30 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC641A08DD for ; Tue, 1 Apr 2014 15:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 anK72uifU_HA for ; Tue, 1 Apr 2014 15:43:26 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0460B1A08B1 for ; Tue, 1 Apr 2014 15:43:25 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 87EA84CE9AC; Wed, 2 Apr 2014 00:43:20 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id dgjTCJkPGuTw; Wed, 2 Apr 2014 00:43:19 +0200 (CEST) Received: from macbook.bluepipe.net (x0.dk [194.19.205.214]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id 6D2554CE98C; Wed, 2 Apr 2014 00:43:17 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id C04921E92FF0; Wed, 2 Apr 2014 00:43:20 +0200 (CEST) Date: Wed, 2 Apr 2014 00:43:20 +0200 From: Phil Regnauld To: Wes Hardaker Message-ID: <20140401224320.GI25608@macbook.bluepipe.net> References: <0lmwg4680h.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lmwg4680h.fsf@wjh.hardakers.net> X-Operating-System: Darwin 13.1.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/LoLCGWsBnf87X1yL0ORr-6OXyVw Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 22:43:28 -0000 Wes Hardaker (wjhns1) writes: > Anyone that knows both is a potential point of compromise. > > http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ > > Warning: the security in here is not. "In order to protect against this threat, the endEntity must transmit the request to the recursive resolver in such a way that the recursive resolver in such a way that the recursive resolver must not be aware of which end entity sent the request in the first place." Man, reading that sentence, I had the feeling that sentence that I had read it twice. From nobody Tue Apr 1 17:56:35 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9FD1A004A for ; Tue, 1 Apr 2014 17:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=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 S4y9k8pUt7Nw for ; Tue, 1 Apr 2014 17:56:32 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 387BA1A0046 for ; Tue, 1 Apr 2014 17:56:32 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3D5D520B2E; Tue, 1 Apr 2014 17:56:26 -0700 (PDT) From: Wes Hardaker To: Phil Regnauld References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140401224320.GI25608@macbook.bluepipe.net> Date: Tue, 01 Apr 2014 17:56:26 -0700 In-Reply-To: <20140401224320.GI25608@macbook.bluepipe.net> (Phil Regnauld's message of "Wed, 2 Apr 2014 00:43:20 +0200") Message-ID: <0leh1g5z2d.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/xtobgqHKbj_Fq9iYKnuuq5yuMKc Cc: dns-privacy@ietf.org, Wes Hardaker Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 00:56:32 -0000 Phil Regnauld writes: > Man, reading that sentence, I had the feeling that sentence that I had > read it twice. I wrote it twice, so it worked. Somewhere in the abstract I should have put "what follows is random, unproofread, typing that may or may not make sense". -- Wes Hardaker Parsons From nobody Wed Apr 2 00:37:45 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21B51A00BF for ; Wed, 2 Apr 2014 00:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gYz_QPDuiWPZ for ; Wed, 2 Apr 2014 00:37:39 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6F1A0027 for ; Wed, 2 Apr 2014 00:37:39 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 900EC2804B4; Wed, 2 Apr 2014 09:37:35 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 8B8712803DE; Wed, 2 Apr 2014 09:37:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id D349CB38039; Wed, 2 Apr 2014 09:36:58 +0200 (CEST) Date: Wed, 2 Apr 2014 09:37:01 +0200 From: Stephane Bortzmeyer To: Wes Hardaker Message-ID: <20140402073701.GA19628@nic.fr> References: <0lmwg4680h.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lmwg4680h.fsf@wjh.hardakers.net> X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.13-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/Rc3ipEnQg01gOwuxu4tYmHl2M5Q Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:37:43 -0000 On Tue, Apr 01, 2014 at 02:43:10PM -0700, Wes Hardaker wrote a message of 23 lines which said: > http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ You mention the risk coming from the resolver. That's why, IMHO, we should recommend people to run a local resolver, as much as possible (I'm aware it may not always be possible, for instance for constrained devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00 This leaves us with the authoritative name servers learning the request. Caching protects a bit. For the rest, that's where qname minimisation or minimization comes into play. The authoritative name servers will still learn things but not as many things. See draft-bortzmeyer-dns-qname-minimisation From nobody Wed Apr 2 03:32:59 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC17E1A01BE for ; Wed, 2 Apr 2014 03:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4dWHTNTbnicQ for ; Wed, 2 Apr 2014 03:32:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id CE6511A01B2 for ; Wed, 2 Apr 2014 03:32:45 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s32AWePj010193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Apr 2014 06:32:41 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s32AWcfX004745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 2 Apr 2014 06:32:39 -0400 Message-ID: <533BE746.9050209@redhat.com> Date: Wed, 02 Apr 2014 12:32:38 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dns-privacy@ietf.org References: <20140324112105.GB24967@nic.fr> In-Reply-To: <20140324112105.GB24967@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/zXNsdFSjLasw_OWEGRjeJ1fJEEE Subject: Re: [dns-privacy] Core effort X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 10:32:58 -0000 On 24.3.2014 12:21, Stephane Bortzmeyer wrote: > On Fri, Mar 21, 2014 at 03:51:30PM -0700, > Ted Hardie wrote > a message of 58 lines which said: > >> We may eventually get to active attacks as well, but those aren't likely to >> be occurring at the moment because they aren't required; passive monitoring >> of a cleartext protocol is enough. >> >> Do we have agreement that this is the core of what we're setting out to do? > > Not for me. The problem is that "active" or "passive" depends on the > layer. According to Snowden files, the NSA is doing _active_ attacks > (injecting packets with QUANTUM, planting malware with FOXACID) for > the purpose of conducting _passive_ data collection. > > So, I do not think we should limit ourselves to passive attacks. I I agree. Resiliency against passive attacks only is very very brittle and I hope we can do better. Also, keep in mind http://en.wikipedia.org/wiki/Authenticated_encryption#cite_ref-1 http://en.wikipedia.org/wiki/Authenticated_encryption#cite_ref-2 Have a nice day! -- Petr Spacek @ Red Hat From nobody Wed Apr 2 04:54:48 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4761A01EC for ; Wed, 2 Apr 2014 04:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 QhTuWoZoJlKi for ; Wed, 2 Apr 2014 04:54:42 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 302BD1A01EE for ; Wed, 2 Apr 2014 04:54:41 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gl10so60599lab.14 for ; Wed, 02 Apr 2014 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2MtlLLJCkbKRJdHiEW7hHOory0r0Iw4tFDUCi5HwJk0=; b=SZctwehWCEkDAOo3CguUrrsI82THw/FicyQaHhIWWyVWvw94w4Wu7bYsVOk70OwVrZ O353JD+RG464Cm/2fLe/kWKSUjm7GgFwJZkHP9PphPKkEPXSBkJByUX2VZcgv41gs+Yf WDFKvhG7af5ZUBDYyinsvk6eng95T/QSgPj3BwKBPb18k9g2Oy1hc2jytpztC7lolYON bZDWf+dEKE7wJ5eCe0Hh13J8kA5sQj1qQRdnFdurTIb863a+OW73aSqwv1m6EVusrSrQ L29f5/+EXUpUB1Xj+Y/b+L2QFY4AJKcdZH4TOXET+b2R24XcHtUFaop57s5QjhA08a5P 7cxw== MIME-Version: 1.0 X-Received: by 10.113.3.35 with SMTP id bt3mr126383lbd.87.1396439677710; Wed, 02 Apr 2014 04:54:37 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 2 Apr 2014 04:54:37 -0700 (PDT) In-Reply-To: <533BE746.9050209@redhat.com> References: <20140324112105.GB24967@nic.fr> <533BE746.9050209@redhat.com> Date: Wed, 2 Apr 2014 07:54:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Petr Spacek Content-Type: multipart/alternative; boundary=001a1134c0bef0b59d04f60df211 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/7rW2GIJTine55wcKHu8ODXlCC34 Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] Core effort X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 11:54:46 -0000 --001a1134c0bef0b59d04f60df211 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 2, 2014 at 6:32 AM, Petr Spacek wrote: > On 24.3.2014 12:21, Stephane Bortzmeyer wrote: > >> On Fri, Mar 21, 2014 at 03:51:30PM -0700, >> Ted Hardie wrote >> a message of 58 lines which said: >> >> We may eventually get to active attacks as well, but those aren't likely >>> to >>> be occurring at the moment because they aren't required; passive >>> monitoring >>> of a cleartext protocol is enough. >>> >>> Do we have agreement that this is the core of what we're setting out to >>> do? >>> >> >> Not for me. The problem is that "active" or "passive" depends on the >> layer. According to Snowden files, the NSA is doing _active_ attacks >> (injecting packets with QUANTUM, planting malware with FOXACID) for >> the purpose of conducting _passive_ data collection. >> >> So, I do not think we should limit ourselves to passive attacks. I >> > I agree. Resiliency against passive attacks only is very very brittle and > I hope we can do better. > > Also, keep in mind > http://en.wikipedia.org/wiki/Authenticated_encryption#cite_ref-1 > http://en.wikipedia.org/wiki/Authenticated_encryption#cite_ref-2 > > Have a nice day! The current status of my code is that I am getting close to being able to do a demo of a scheme that is actually quite a bit simpler than DTLS. I have had a look at the authenticated encryption modes but I think we are better off with AES + HMAC-SHA2 right now. The problem is that several of the crypto libraries do not expose the AES block operation as a primitive which means having to re-implement AES to do modes other than the vanilla ones. And reimplementing means losing the advantage of access to built in crypto hardware. If we were going to use authenticated encryption we would probably need to warn the platform providers that is where we are headed. For example through something like this: https://datatracker.ietf.org/doc/draft-hallambaker-consensuscrypto/ -- Website: http://hallambaker.com/ --001a1134c0bef0b59d04f60df211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 2, 2014 at 6:32 AM, Petr Spacek <pspacek@redhat.com> wrote:
On 24.3.2014 12:21, Stephane Bortzmeyer wr= ote:
On Fri, Mar 21, 2014 at 03:51:30PM -0700,
=A0 Ted Hardie <= ted.ietf@gmail.com> wrote
=A0 a message of 58 lines which said:

We may eventually get to active attacks as well, but those aren't likel= y to
be occurring at the moment because they aren't required; passive monito= ring
of a cleartext protocol is enough.

Do we have agreement that this is the core of what we're setting out to= do?

Not for me. The problem is that "active" or "passive" d= epends on the
layer. According to Snowden files, the NSA is doing _active_ attacks
(injecting packets with QUANTUM, planting malware with FOXACID) for
the purpose of conducting _passive_ data collection.

So, I do not think we should limit ourselves to passive attacks. I
I agree. Resiliency against passive attacks only is very very brittle and I= hope we can do better.

Also, keep in mind
http://en.wikipedia.org/wiki/Authenticated_encry= ption#cite_ref-1
http://en.wikipedia.org/wiki/Authenticated_encry= ption#cite_ref-2

Have a nice day!

The current status of my c= ode is that I am getting close to being able to do a demo of a scheme that = is actually quite a bit simpler than DTLS.

I have = had a look at the authenticated encryption modes but I think we are better = off with AES + HMAC-SHA2 right now. The problem is that several of the cryp= to libraries do not expose the AES block operation as a primitive which mea= ns having to re-implement AES to do modes other than the vanilla ones. And = reimplementing means losing the advantage of access to built in crypto hard= ware.

If we were going to use authenticated encryption we wou= ld probably need to warn the platform providers that is where we are headed= . For example through something like this:


=A0
--
Website: http://hallambaker.com/
--001a1134c0bef0b59d04f60df211-- From nobody Thu Apr 3 07:04:38 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD671A01B5 for ; Thu, 3 Apr 2014 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CVMGrXLDxLs2 for ; Thu, 3 Apr 2014 07:04:31 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75D1A01BF for ; Thu, 3 Apr 2014 07:04:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37156) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WViFi-00013e-Wq (Exim 4.82_3-c0e5623) (return-path ); Thu, 03 Apr 2014 15:04:22 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WViFi-0001Wh-2R (Exim 4.72) (return-path ); Thu, 03 Apr 2014 15:04:22 +0100 Date: Thu, 3 Apr 2014 15:04:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Stephane Bortzmeyer In-Reply-To: <20140402073701.GA19628@nic.fr> Message-ID: References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140402073701.GA19628@nic.fr> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/gtSjZx1FUmONDOBU7gdFXTjjo6k Cc: dns-privacy@ietf.org, Wes Hardaker Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:04:36 -0000 Stephane Bortzmeyer wrote: > > You mention the risk coming from the resolver. That's why, IMHO, we > should recommend people to run a local resolver, as much as possible If (big if) you trust the resolver then you have the advantage of hiding your iteratve queries in the aggregate behaviour of the resolver's other users, and if the connection to your resolver is encrypted it is relatively difficult for a snooper to work out what you are asking for. If you run the resolver locally then it becomes really easy to do traffic analysis on your DNS, because even if it is encrypted the attacker has your authoritative server addresses as well as the packet sizes to work with. So I don't think the trade-off is simple enough to make a blanket recommendation. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet: South or southwest 3 or 4, occasionally 5 later. Slight or moderate. Occasional rain with fog patches, becoming fair. Moderate, occasionally very poor, becoming good. From nobody Thu Apr 3 08:17:46 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6271A0216 for ; Thu, 3 Apr 2014 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 DOOuXA8mIb6q for ; Thu, 3 Apr 2014 08:17:40 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3801A020A for ; Thu, 3 Apr 2014 08:17:39 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so1449178lab.38 for ; Thu, 03 Apr 2014 08:17:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4i2Om5oY6Kdz8hnPPYU6eXrceLpHNjZdbokt79LLNTs=; b=Eii29DY82N5PUwk1/gqVnU3WfTREzPGpgVaNnNMtroKBoKUHQneQBZtuCPvrWCto7Z ebx9I4jw1W6PTl7LI8pQBtuhfr8MDY1ASyWFda/rDH9Y4B+A4VY4BtLfVS0q947nNbE1 QI7TY6qbIrkz/xf62YqmSJv1Oz9vM+A6pjRD+vJZIyfF8CYKdAm6/lJrL+HJp4h2bmFy f3N8BJsTd2HWqjEpXt+82Nf9bfBUhIrKfC1ohYrdKHtiGv8uk0yEtswWblMyN6bAv5W1 Y+3ozDWApsogsM/E58VpL4toizuJMi7tEYucTSpB9z5GB+AvhnlIs7xDwOvmypjrHxWv NVxw== X-Gm-Message-State: ALoCoQlIdDlMLwtYsZ1TR2nYVdyq6ngQNR1K+93oKPfloZlJ6W4jBtqCTlHfruN7l2X2OYR3dZ0o MIME-Version: 1.0 X-Received: by 10.112.30.233 with SMTP id v9mr2399989lbh.35.1396538254070; Thu, 03 Apr 2014 08:17:34 -0700 (PDT) Received: by 10.114.0.243 with HTTP; Thu, 3 Apr 2014 08:17:34 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: <20140402073701.GA19628@nic.fr> References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140402073701.GA19628@nic.fr> Date: Thu, 3 Apr 2014 23:17:34 +0800 Message-ID: From: Warren Kumari To: Stephane Bortzmeyer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/PvrUltDW1-ltipOKlwjMm_WYGd8 Cc: dns-privacy@ietf.org, Wes Hardaker Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:17:44 -0000 On Wed, Apr 2, 2014 at 3:37 PM, Stephane Bortzmeyer wrote: > On Tue, Apr 01, 2014 at 02:43:10PM -0700, > Wes Hardaker wrote > a message of 23 lines which said: > >> http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ > > You mention the risk coming from the resolver. That's why, IMHO, we > should recommend people to run a local resolver, as much as possible > (I'm aware it may not always be possible, for instance for constrained > devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00 > > This leaves us with the authoritative name servers learning the > request. ... 'm still confused by this bit. If I'm running a local resolver and my machine makes a connection to ns1.example.com, presumably it's because I'm trying to lookup a record in the example.com zone (assuming ns1.example.com is only authoritative for a small number of zones). Sure, I could be looking up www.example.com or mail.example.com or foo.example.com but it's still clear I'm going to example.com.... As an example of this, if my resolver makes a connection to 199.193.245.198 it's quite clear I'm going to http://www.smartrecovery.org/ (I wanted to use Alcoholics Anonymous, but they use ns.rackspace.com, just like ~2,500 other folk). Perhaps we don't care, because folk who run their own DNS likely run "dedicated" web servers, and so it's clear for someone on the wire where they are going anyway?! W > Caching protects a bit. For the rest, that's where qname > minimisation or minimization comes into play. The authoritative name > servers will still learn things but not as many things. See > draft-bortzmeyer-dns-qname-minimisation > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Thu Apr 3 14:10:39 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292751A0188 for ; Thu, 3 Apr 2014 14:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=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 Qi9zsjAM_Agl for ; Thu, 3 Apr 2014 14:10:29 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3CD1A01D9 for ; Thu, 3 Apr 2014 14:10:11 -0700 (PDT) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id E196121F92; Thu, 3 Apr 2014 14:10:01 -0700 (PDT) From: Wes Hardaker To: Stephane Bortzmeyer References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140402073701.GA19628@nic.fr> Date: Thu, 03 Apr 2014 14:10:00 -0700 In-Reply-To: <20140402073701.GA19628@nic.fr> (Stephane Bortzmeyer's message of "Wed, 2 Apr 2014 09:37:01 +0200") Message-ID: <0ld2gy9l1z.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/yqP5cISK2um_H0gYUf2dKPgf4uA Cc: dns-privacy@ietf.org, Wes Hardaker Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 21:10:33 -0000 Stephane Bortzmeyer writes: > You mention the risk coming from the resolver. That's why, IMHO, we > should recommend people to run a local resolver, as much as possible > (I'm aware it may not always be possible, for instance for constrained > devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00 But that doesn't really mitigate everything. Anyone sniffing the wire either near you or even near the resolver in question can see who is making the traffic and where it's going. To get secured deployment using a local resolver scheme, you still have to have the local resolver doing DTLS (or equivalent) from it to everywhere, and the destination NS still gives a lot away even if you could encrypt everything everywhere "soon". I do agree that everyone should use a local resolver. Or, even better, smarter in-application validating APIs with local caches. Anyway, the hack in my Apr 1. document gets around these problems by only needing a few of the distant anonymizing resolvers in place. (FYI, in the document I listed the suggested name as EEEE.K1.example.org, but it really should be reversed to provide easier state tracking in both places: K1.EEEE.example.org). -- Wes Hardaker Parsons From nobody Fri Apr 4 01:11:29 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE91A0404 for ; Fri, 4 Apr 2014 01:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Y8oeH9ZO8uVT for ; Fri, 4 Apr 2014 01:11:18 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 3D41B1A03F8 for ; Fri, 4 Apr 2014 01:11:18 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 479212801FE; Fri, 4 Apr 2014 10:11:13 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 428A728018A; Fri, 4 Apr 2014 10:11:13 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 12CCD4C00B8; Fri, 4 Apr 2014 10:10:43 +0200 (CEST) Date: Fri, 4 Apr 2014 10:10:44 +0200 From: Stephane Bortzmeyer To: Tony Finch Message-ID: <20140404081042.GA23384@nic.fr> References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140402073701.GA19628@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.13-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/t766WV8PeojRVVN7OF0RTRB-D6A Cc: dns-privacy@ietf.org, Stephane Bortzmeyer , Wes Hardaker Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:11:28 -0000 On Thu, Apr 03, 2014 at 03:04:22PM +0100, Tony Finch wrote a message of 23 lines which said: > If (big if) you trust the resolver then you have the advantage of > hiding your iteratve queries in the aggregate behaviour of the > resolver's other users, You can have your cake and eat it: run your own resolver and forward the uncached queries to a shared resolver (your IAP's or Google Public DNS, as you wish). This is automatically done by the excellent tool dnssec-trigger, which probes the shared resolver before using it in forwarding. Because of the local resolver, you will send less info to the shared resolver. Because of the shared resolver, you will send less info to the authoritative name servers. From nobody Fri Apr 4 01:50:45 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE201A0455 for ; Fri, 4 Apr 2014 01:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KHqIUHsC8qoQ for ; Fri, 4 Apr 2014 01:50:37 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41C1A0453 for ; Fri, 4 Apr 2014 01:50:37 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 70366280277; Fri, 4 Apr 2014 10:50:32 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 6B80428018A; Fri, 4 Apr 2014 10:50:32 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 3311A4C0029; Fri, 4 Apr 2014 10:50:02 +0200 (CEST) Date: Fri, 4 Apr 2014 10:50:04 +0200 From: Stephane Bortzmeyer To: Wes Hardaker Message-ID: <20140404085004.GC23384@nic.fr> References: <0lmwg4680h.fsf@wjh.hardakers.net> <20140402073701.GA19628@nic.fr> <0ld2gy9l1z.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ld2gy9l1z.fsf@wjh.hardakers.net> X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.13-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/5iX8YhMd6JCTQdPGrhqHoUE0cks Cc: dns-privacy@ietf.org, Stephane Bortzmeyer Subject: Re: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:50:42 -0000 On Thu, Apr 03, 2014 at 02:10:00PM -0700, Wes Hardaker wrote a message of 27 lines which said: > Anyone sniffing the wire either near you or even near the resolver > in question can see who is making the traffic and where it's going. > To get secured deployment using a local resolver scheme, you still > have to have the local resolver doing DTLS Yes, as I have said in physical meetings or in my drafts, there is not one solution that will solve everything. We need data minimisation (or minimization) _and_ encryption. From nobody Sun Apr 13 05:34:53 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585B41A01D9 for ; Sun, 13 Apr 2014 05:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2pzgTuMNdUjZ for ; Sun, 13 Apr 2014 05:34:50 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 948321A01CA for ; Sun, 13 Apr 2014 05:34:49 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id mc6so4761330lab.8 for ; Sun, 13 Apr 2014 05:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=W89fhy1RdIXzSeny3Pv05CPXlW5ve5VUwrU4frg3iAs=; b=xDGf/dp/cbZc0wJPrN3PmPF2JqnZQCGapwKRblHmGo0oR/l5VevvcKqmPHZuuOACWa DAli0Zvc2Ev4Q+KMaClUmoIvrUSZzLmA/Ny+eYyQkLMNisSq9ExeR7I69YZV9laF4IcU jeDnh/ByoleZoocUlFXaysCcaPc4QT3/t7/wjIftvgoP2L2h5I14zNiR9jD1zMRcV5cI esSa7IMjitk8daaFKI5vn/0VN53IGPhdOkIIIq8RVf/SyH99E2vPEY19oT8vSUPcpIne WZPHh217I46Iay6RhKFlR+9mU33r7TO+tKZXT6F8l7vYOpOKLbY5hRrED0f2RTKYOTH4 FWbA== MIME-Version: 1.0 X-Received: by 10.112.163.69 with SMTP id yg5mr23665953lbb.14.1397392486665; Sun, 13 Apr 2014 05:34:46 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sun, 13 Apr 2014 05:34:46 -0700 (PDT) Date: Sun, 13 Apr 2014 08:34:46 -0400 Message-ID: From: Phillip Hallam-Baker To: dns-privacy@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/blrKCzJplHq29g6u081I3LtpbPY Subject: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 12:34:51 -0000 There are many lessons that can be drawn from Heartbleed but one of the most important is that complexity is the enemy of security and general platforms have a tendency to become rather complex. Which is one of the reasons why I have been rather suspicious of the 'just use DTLS' approach. Building on DTLS means importing all the current and future complexity of TLS. That seems rather a lot of overhead when all we need to do at the DNS layer is to take a message M, encrypt it under a key and plonk a MAC code on the end. I know that the counter argument is that 'TLS is a known quantity, 20 years have gone into development'. But like the argument that 'open source is better because anyone can review' we are seeing that its not necessarily true. Code can get worse over time as well as better. -- Website: http://hallambaker.com/ From nobody Sun Apr 13 05:45:22 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4126A1A009A for ; Sun, 13 Apr 2014 05:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.975 X-Spam-Level: * X-Spam-Status: No, score=1.975 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 DuWlwij2_ocN for ; Sun, 13 Apr 2014 05:45:20 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 785251A0091 for ; Sun, 13 Apr 2014 05:45:20 -0700 (PDT) Received: from [192.168.88.218] (unknown [177.32.105.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id EB533208015C; Sun, 13 Apr 2014 09:45:17 -0300 (BRT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rubens Kuhl In-Reply-To: Date: Sun, 13 Apr 2014 09:45:17 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/kctYOdyM9qg2WMZe-hXuSKWvrmQ Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 12:45:21 -0000 > Which is one of the reasons why I have been rather suspicious of the > 'just use DTLS' approach. Building on DTLS means importing all the > current and future complexity of TLS. >=20 > That seems rather a lot of overhead when all we need to do at the DNS > layer is to take a message M, encrypt it under a key and plonk a MAC > code on the end. >=20 What about =93Just use QUIC=94 ? It might have a better future with DNS = than DTLS.=20 >=20 > I know that the counter argument is that 'TLS is a known quantity, 20 > years have gone into development'. But like the argument that 'open > source is better because anyone can review' we are seeing that its not > necessarily true. Code can get worse over time as well as better. Open source is still better because anyone can review. But code get = worse with time, either closed or open source, unlike wine.=20 Rubens From nobody Sun Apr 13 06:16:47 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FB71A0110 for ; Sun, 13 Apr 2014 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Hn_8sPxzOlJI for ; Sun, 13 Apr 2014 06:16:42 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6281A0108 for ; Sun, 13 Apr 2014 06:16:42 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so4851427lbd.37 for ; Sun, 13 Apr 2014 06:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PyN0p9GAmzZLDvA9jPy7d99ke6vJs+ZXG1JXxklH21k=; b=IJLgOCSqUYJl0PW+DxfxIoT/btZQNyI4icLl7Kj2eIuqMSoijRVUnSwO2GQiRJNwjw JypswD8w1LboBM//1MT8w1avqBRFOSA2zs5m5Eq5b+OvMofmGfRaA+D8H+G5QkqA9tev kQXvE9hPKiwXoGHTwZX8W5Y5fVacG2qJ+NNdFup8SYH/zJIakCrxXTLzewy+NAr1xN+N PFu6KBQBTYZcNFL5ZTDnPc34YXk0PMwCpu1FCCfUSk2Xxgp/SmsgI93LTOBHux/K1oOc b3OoX4hTUlaQrUDO05tcozcOnwn6x9OkcztXwUTaKhL6NJnAHbgFxmWO9Nn8J6gny6fn Tntg== MIME-Version: 1.0 X-Received: by 10.152.235.3 with SMTP id ui3mr25320529lac.2.1397394999743; Sun, 13 Apr 2014 06:16:39 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sun, 13 Apr 2014 06:16:39 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Apr 2014 09:16:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Rubens Kuhl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/2GAT7yDPk5vy3BHW2Hbg0xckzgQ Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 13:16:45 -0000 On Sun, Apr 13, 2014 at 8:45 AM, Rubens Kuhl wrote: >> Which is one of the reasons why I have been rather suspicious of the >> 'just use DTLS' approach. Building on DTLS means importing all the >> current and future complexity of TLS. >> >> That seems rather a lot of overhead when all we need to do at the DNS >> layer is to take a message M, encrypt it under a key and plonk a MAC >> code on the end. >> > > What about =E2=80=9CJust use QUIC=E2=80=9D ? It might have a better futur= e with DNS than DTLS. QUIC is a replacement for TCP and it has a lot of merit for applications where requests can be larger than a packet. If the request will fit into one packet and the number of response packets is small enough, the simplest approach is one UDP request packet and multiple response packets. That means servers are completely stateless and we can use anycast etc. What might be rather surprising is that we can fit a complex DNS transaction into one request packet, for example, to resolve http://www.example.com/ we might want to do the following lookups: www.example.com ? A www.example.com ? AAAA _http._tcp.www.example.com ? SRV _http._tcp.www.example.com ? POLICY Although the DNS protocol allows for multiple queries per request, this doesn't quite work because there is no way to specify which response code matches which query. So the simplest approach turns out to be to encode these as four separate DNS queries. But even with that overhead, we can fit all four queries above plus a MAC and a key identifier into one 1400 byte request packet. The nice thing about this is that it means support for the secure DNS actually reduces the load on the server. Instead of making at least two separate queries (A, AAAA) there is a single query. Since the crypto overhead is negligible (its all symmetric key), this is almost certainly a net win as most servers are I/O and transaction bound rather than CPU bound. >> I know that the counter argument is that 'TLS is a known quantity, 20 >> years have gone into development'. But like the argument that 'open >> source is better because anyone can review' we are seeing that its not >> necessarily true. Code can get worse over time as well as better. > > > Open source is still better because anyone can review. But code get worse= with time, either closed or open source, unlike wine. These arguments are only problematic when people think 'A allows B' means 'A therefore B'. --=20 Website: http://hallambaker.com/ From nobody Sun Apr 13 09:01:16 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34F01A02CE for ; Sun, 13 Apr 2014 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.975 X-Spam-Level: * X-Spam-Status: No, score=1.975 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 BTWU0vUfjkbb for ; Sun, 13 Apr 2014 09:01:13 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD471A02CA for ; Sun, 13 Apr 2014 09:01:13 -0700 (PDT) Received: from [192.168.88.218] (unknown [177.32.105.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 851FD208017B; Sun, 13 Apr 2014 13:01:09 -0300 (BRT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rubens Kuhl In-Reply-To: Date: Sun, 13 Apr 2014 13:01:08 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/pGb-d-1r10VIgwWDZM7LJqM1TM8 Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 16:01:14 -0000 >> What about =93Just use QUIC=94 ? It might have a better future with = DNS than DTLS. >=20 > QUIC is a replacement for TCP and it has a lot of merit for > applications where requests can be larger than a packet. >=20 =93is a replacement for=94 is a judgement of suitability. Over the years = I heard some people saying DNS should have used TCP with built-in = scalability for large recursive and authoritative servers, so may be = QUIC is quick enough to allow usage in the DNS world. If people converge = on replace TCP with QUIC too that=92s fine, but being useful for TCP is = not a factor into using in DNS or not.=20 > If the request will fit into one packet and the number of response > packets is small enough, the simplest approach is one UDP request > packet and multiple response packets. That means servers are > completely stateless and we can use anycast etc. Stateless is a good thing, but a bit of state can be tolerated if it=92s = used for a high steady request volume. For instance, a Google 8.8.8.8 = recursive server, even just one of the servers, likely keeps requesting = Alexa-100 authoritative servers 24x7 without mercy. Requiring state = would be bad, but allowing state where it justifies would be fine by me.=20= Reverting to TCP due to multiple response packets, like is done today, = really isn=92t a good criteria, but query rate would be. Want a less = than x queries / minute ? Do totally stateless. Want more than that ? = State is required. We would get rid of one of the DDoS vectors that = exist today (high amplification attacks from a low number of fast = compromised machines).=20 > What might be rather surprising is that we can fit a complex DNS > transaction into one request packet, for example, to resolve > http://www.example.com/ we might want to do the following lookups: >=20 > www.example.com ? A > www.example.com ? AAAA > _http._tcp.www.example.com ? SRV > _http._tcp.www.example.com ? POLICY >=20 > Although the DNS protocol allows for multiple queries per request, > this doesn't quite work because there is no way to specify which > response code matches which query. So the simplest approach turns out > to be to encode these as four separate DNS queries. But even with that > overhead, we can fit all four queries above plus a MAC and a key > identifier into one 1400 byte request packet. >=20 >=20 > The nice thing about this is that it means support for the secure DNS > actually reduces the load on the server. Instead of making at least > two separate queries (A, AAAA) there is a single query. Since the > crypto overhead is negligible (its all symmetric key), this is almost > certainly a net win as most servers are I/O and transaction bound > rather than CPU bound. Either with DTLS, QUIC or something else, that would be a sound design = to have.=20 Rubens From nobody Sun Apr 13 10:01:39 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A166E1A0202 for ; Sun, 13 Apr 2014 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 0aAhsOYNqB1h for ; Sun, 13 Apr 2014 10:01:35 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id A361B1A0159 for ; Sun, 13 Apr 2014 10:01:34 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 5C5B41A2671; Sun, 13 Apr 2014 20:01:30 +0300 (EEST) Date: Sun, 13 Apr 2014 20:01:30 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20140413170130.GA13725@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/rxbn6eZyzYY5x4P1lD9hticJ9qo Cc: dns-privacy@ietf.org, Rubens Kuhl Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:01:37 -0000 On Sun, Apr 13, 2014 at 09:16:39AM -0400, Phillip Hallam-Baker wrote: > > The nice thing about this is that it means support for the secure DNS > actually reduces the load on the server. Instead of making at least > two separate queries (A, AAAA) there is a single query. Since the > crypto overhead is negligible (its all symmetric key), this is almost > certainly a net win as most servers are I/O and transaction bound > rather than CPU bound. There's also another factor to consider: Memory use. Specifically, how much memory "sessions" that aren't currently being prcessed, but which need to be able to bring to service in 0 RTT use. I have no idea how DTLS would fare here... Also, agreed that DTLS is a serious mess (and I think it is going to get even worse). -Ilari From nobody Sun Apr 13 10:01:45 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1C61A02CA for ; Sun, 13 Apr 2014 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ttcxfcElxj1R for ; Sun, 13 Apr 2014 10:01:39 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3B51A0159 for ; Sun, 13 Apr 2014 10:01:38 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so4887230lbi.22 for ; Sun, 13 Apr 2014 10:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o8u2fsc7Q2rlHMjxzz5u/8ffiNvBse2Qduxgo/FV5YY=; b=dOAsRvtfMOf3QnmfApwZ4tVpmMzqtbi6UicvA4kQ/gEPFYY/hqfvXo/IfhoMI3ZoAa FsEWO51aOgyrEeT2K8AhuSIB1eOY2Ep2dXfe/t+EZxyDVIbW5EJFkUh5hfTx+bWUc9wv /HpXsM9Enl3zWafxwVSrpVG1Az9suACRf9/laEhyeb1VhKAn16kcmzxztHglTA3QCVE+ RY7Ic166TkITDN6E8uNk/NyEPI4hk+pmzH+zkW+TyuEu40LZmdcRqAX8cP10CMRkGELL uBu52yagY2mO0JovyIp5QCgIeC0rj4P0kla02MjhqFVGcOtPEZGKXHYjmzLYUjjevA47 +p1g== MIME-Version: 1.0 X-Received: by 10.153.11.163 with SMTP id ej3mr25941050lad.17.1397408496073; Sun, 13 Apr 2014 10:01:36 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sun, 13 Apr 2014 10:01:36 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Apr 2014 13:01:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Rubens Kuhl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/RM5xChfcE-mTsq4C9H9nZxaHHrs Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 17:01:44 -0000 On Sun, Apr 13, 2014 at 12:01 PM, Rubens Kuhl wrote: >>> What about =E2=80=9CJust use QUIC=E2=80=9D ? It might have a better fut= ure with DNS than DTLS. >> >> QUIC is a replacement for TCP and it has a lot of merit for >> applications where requests can be larger than a packet. >> > > =E2=80=9Cis a replacement for=E2=80=9D is a judgement of suitability. Ove= r the years I heard some people saying DNS should have used TCP with built-= in scalability for large recursive and authoritative servers, so may be QUI= C is quick enough to allow usage in the DNS world. If people converge on re= place TCP with QUIC too that=E2=80=99s fine, but being useful for TCP is no= t a factor into using in DNS or not. > >> If the request will fit into one packet and the number of response >> packets is small enough, the simplest approach is one UDP request >> packet and multiple response packets. That means servers are >> completely stateless and we can use anycast etc. > > Stateless is a good thing, but a bit of state can be tolerated if it=E2= =80=99s used for a high steady request volume. For instance, a Google 8.8.8= .8 recursive server, even just one of the servers, likely keeps requesting = Alexa-100 authoritative servers 24x7 without mercy. Requiring state would b= e bad, but allowing state where it justifies would be fine by me. Well you might have a point... But the people who have the problem with latency are the google who want to shave it to the very minimum possible. And they would be the main constituency for QUIC. > Reverting to TCP due to multiple response packets, like is done today, re= ally isn=E2=80=99t a good criteria, but query rate would be. Want a less th= an x queries / minute ? Do totally stateless. Want more than that ? State i= s required. We would get rid of one of the DDoS vectors that exist today (= high amplification attacks from a low number of fast compromised machines). The way I avoid the DDoS attack is to authenticate requests so they only get a response if there is a valid ticket. Amplification attacks are no longer an issue. --=20 Website: http://hallambaker.com/ From nobody Sun Apr 13 21:43:57 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F251A0332 for ; Sun, 13 Apr 2014 21:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 x9xvPhbah3Su for ; Sun, 13 Apr 2014 21:43:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DB5201A032C for ; Sun, 13 Apr 2014 21:43:53 -0700 (PDT) Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3E4hQeY003762; Sun, 13 Apr 2014 21:43:27 -0700 (PDT) Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (Postfix) with ESMTP id 166B961480; Sun, 13 Apr 2014 21:43:21 -0700 (PDT) From: John Heidemann To: Ilari Liusvaara In-reply-to: <20140413170130.GA13725@LK-Perkele-VII> References: <20140413170130.GA13725@LK-Perkele-VII> X-url: http://www.isi.edu/~johnh/ MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Date: Sun, 13 Apr 2014 21:43:21 -0700 Message-ID: <19837.1397450601@dash.isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: johnh@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/j3qITHUeM_oMuas8S-6_IgmLnY0 Cc: dns-privacy@ietf.org, Phillip Hallam-Baker , Rubens Kuhl Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 04:43:56 -0000 On Sun, 13 Apr 2014 20:01:30 +0300, Ilari Liusvaara wrote: >On Sun, Apr 13, 2014 at 09:16:39AM -0400, Phillip Hallam-Baker wrote: >... >There's also another factor to consider: Memory use. Specifically, >how much memory "sessions" that aren't currently being prcessed, >but which need to be able to bring to service in 0 RTT use. > >I have no idea how DTLS would fare here... > >Also, agreed that DTLS is a serious mess (and I think it is going to get >even worse). A couple of comments: - it seems to me like memory use is the biggest constraint if you're running a server, and latency for the clients. - unfortunately these conflict with each other: you reduce latency by keeping connections open and reusing them, but that increases memory use at servers - We've done some studies about memory use for TCP+TLS, with real traces from several several different types of servers. See http://www.isi.edu/~johnh/PAPERS/Zhu14a.html for the tech report. (We'd love comments and feedback!) - the high order bit from the study is that with very conservative (i.e., short) timeouts, and with TCP+TLS from stub to recursive and TCP only from recursive to authoritative, we see ~21% greater latency and 9GB of state at the recursive resolver. You can tweak the numbers to get different trade-offs if you prefer. Both of these are more than current UDP, but both are, I think, "reasonable". And fortunately, DNS is embarrassingly parallel, so one can easily increase server capacity by buying more servers. About specific protocols: - we took the most conservative choice: TCP and TLS. Heartbleed shows us subtle bugs are possible, but IMHO better something the community has been studying for years and years than something hand-rolled, or something less well examined. - Although not a privacy issue, I think DNS over TCP is a really interesting method to address other (non-privacy-related) security questions, like reducing DNS amplification attacks, and removing the endless debates about "change X will overflow packet size Y and cause subtle problem Z to W percent of users". (IMHO, that debate has subtly distorted a number of policy discussions, like keysize choices. I'd just like to sidestep all that.) Details are in the tech report; I don't want to get off-topic wrt dns-privacy. - I think UDP+DTLS vs. TCP+TLS is an interesting open question. It's not obvious to me that DTLS helps that much, as you still do a standard TLS handshake (just over UDP). And I'm admiring of TCP for other reasons (see the prior bullet). But I think a prudent step would be to advance TCP+TLS and then see if the same model also applies to UDP+DTLS, if we can articulate the compelling advantages of DTLS. -John Heidemann From nobody Sun Apr 20 11:39:55 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90FE1A0029 for ; Sun, 20 Apr 2014 11:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.878 X-Spam-Level: X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 K9CzkqFVEyU8 for ; Sun, 20 Apr 2014 11:39:49 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) by ietfa.amsl.com (Postfix) with ESMTP id 50C5D1A0040 for ; Sun, 20 Apr 2014 11:39:48 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Wbwcr-000488-3y; Sun, 20 Apr 2014 20:38:01 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WbweL-0007Ep-A5; Sun, 20 Apr 2014 20:39:33 +0200 From: Florian Weimer To: John Heidemann References: <20140413170130.GA13725@LK-Perkele-VII> <19837.1397450601@dash.isi.edu> Date: Sun, 20 Apr 2014 20:39:33 +0200 In-Reply-To: <19837.1397450601@dash.isi.edu> (John Heidemann's message of "Sun, 13 Apr 2014 21:43:21 -0700") Message-ID: <87ha5nc0be.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/W2jCWtXvZQoKz5XY3eSqSr15txM Cc: Phillip Hallam-Baker , dns-privacy@ietf.org, Ilari Liusvaara , Rubens Kuhl Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 18:39:53 -0000 * John Heidemann: > - We've done some studies about memory use for TCP+TLS, with real traces > from several several different types of servers. See > http://www.isi.edu/~johnh/PAPERS/Zhu14a.html for the tech report. > (We'd love comments and feedback!) Did you attempt to filter out garbage queries from your replay data? Especially for the B root, I expect sources that would never be able to complete a three-way handshake because they use incorrect IP sources addresses. I'm not sure in which direction garbage queries tilt the numbers. The stub resolver performance for classic DNS seems to be too good to be true, partly due to the PlanetLab bias (as youn note)=E2=80=94or it measures RRTs to some local non-recursive cache: many access technologies have RTTs to the first IP hop that exceed 5 ms, and you still have to reach the ISP resolver from there. I wonder if it is possible to obtain better data by triggering a cascade of name resolutions from web browsers and try to tell upstream cache miss rate from local stub cache miss rate. > - the high order bit from the study is that with very conservative > (i.e., short) timeouts, and with TCP+TLS from stub to recursive and > TCP only from recursive to authoritative, we see ~21% greater latency > and 9GB of state at the recursive resolver. You can tweak the numbers > to get different trade-offs if you prefer. > > Both of these are more than current UDP, but both are, I think, > "reasonable". And these numbers are quite impressive because the classic DNS baseline you've established seems a bit rosy to me. In any case, interesting work. Compared to DTLS (or any home-grown protocol), the advantage of TLS over TCP is that we have extensive experience in dealing with various kinds of network anomalies, much of which would likely apply directly to protecting DNS infrastructure. From nobody Tue Apr 22 23:18:49 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC6B1A00B4 for ; Tue, 22 Apr 2014 23:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 2zl5YIKDDj2L for ; Tue, 22 Apr 2014 23:18:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C06741A0096 for ; Tue, 22 Apr 2014 23:18:42 -0700 (PDT) Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3N6IEwk007133; Tue, 22 Apr 2014 23:18:14 -0700 (PDT) Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (Postfix) with ESMTP id EEE876004B; Tue, 22 Apr 2014 23:18:12 -0700 (PDT) From: John Heidemann To: Florian Weimer In-reply-to: <87ha5nc0be.fsf@mid.deneb.enyo.de> References: <20140413170130.GA13725@LK-Perkele-VII> <19837.1397450601@dash.isi.edu> <87ha5nc0be.fsf@mid.deneb.enyo.de> X-url: http://www.isi.edu/~johnh/ MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Apr 2014 23:18:12 -0700 Message-ID: <9285.1398233892@dash.isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: johnh@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/3HOhnTxnGVqHiOo09awrE1NlTeU Cc: Ilari Liusvaara , dns-privacy@ietf.org, Phillip Hallam-Baker , Rubens Kuhl Subject: Re: [dns-privacy] DTLS and OpenSSL Heartbleed bug X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:18:47 -0000 On Sun, 20 Apr 2014 20:39:33 +0200, Florian Weimer wrote= :=20 >* John Heidemann: > >> - We've done some studies about memory use for TCP+TLS, with real traces >> from several several different types of servers. See >> http://www.isi.edu/~johnh/PAPERS/Zhu14a.html for the tech report. >> (We'd love comments and feedback!) Thanks for the comments. >Did you attempt to filter out garbage queries from your replay data? >Especially for the B root, I expect sources that would never be able >to complete a three-way handshake because they use incorrect IP >sources addresses. I'm not sure in which direction garbage queries >tilt the numbers. You mean queries with spoofed IP source addresses? AFAIK our UDP data does not give us enough information to differentiate actual from spoofed source IP addresses. >The stub resolver performance for classic DNS seems to be too good to >be true, partly due to the PlanetLab bias (as youn note)=E2=80=94or it >measures RRTs to some local non-recursive cache: many access >technologies have RTTs to the first IP hop that exceed 5 ms, and you >still have to reach the ISP resolver from there. I wonder if it is >possible to obtain better data by triggering a cascade of name >resolutions from web browsers and try to tell upstream cache miss rate >from local stub cache miss rate. > >> - the high order bit from the study is that with very conservative >> (i.e., short) timeouts, and with TCP+TLS from stub to recursive and >> TCP only from recursive to authoritative, we see ~21% greater latency >> and 9GB of state at the recursive resolver. You can tweak the numbers >> to get different trade-offs if you prefer. >> >> Both of these are more than current UDP, but both are, I think, >> "reasonable". > >And these numbers are quite impressive because the classic DNS >baseline you've established seems a bit rosy to me. Figure 9 looks at "local" (=3D5ms) and "public" (=3D20ms) (first-hop) recursive resolvers. If you you think 5ms is too low, you can consider the 20ms numbers. That moves the ~21% to ~39%. >In any case, interesting work. Compared to DTLS (or any home-grown >protocol), the advantage of TLS over TCP is that we have extensive >experience in dealing with various kinds of network anomalies, much of >which would likely apply directly to protecting DNS infrastructure. Thanks. Our goal was to leverage TLS+TCP experience. -John From nobody Wed Apr 23 07:05:51 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA35C1A03B3; Wed, 23 Apr 2014 06:47:23 -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] autolearn=ham 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 iLn_4yaY_7Dk; Wed, 23 Apr 2014 06:47:22 -0700 (PDT) Received: from rincewind.ksquared.net (rincewind.ksquared.net [216.129.106.12]) by ietfa.amsl.com (Postfix) with ESMTP id 010D31A020F; Wed, 23 Apr 2014 06:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rincewind.ksquared.net (Postfix) with ESMTP id E08FF20F3C7; Wed, 23 Apr 2014 06:47:13 -0700 (PDT) Received: from rincewind.ksquared.net ([127.0.0.1]) by localhost (rincewind.ksquared.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QgHDmOXSTUq; Wed, 23 Apr 2014 06:47:09 -0700 (PDT) Received: from sjc-vpn7-764.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dwing) by rincewind.ksquared.net (Postfix) with ESMTPSA id 67E4C20F3AD; Wed, 23 Apr 2014 06:47:08 -0700 (PDT) From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Apr 2014 06:47:07 -0700 Message-Id: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> To: dnsop@ietf.org, dns-privacy@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/Olq4Bk9opxgf3WdtliiGI8v7UXM X-Mailman-Approved-At: Wed, 23 Apr 2014 07:05:49 -0700 Cc: Prashanth Patil , Tirumaleswar Reddy Subject: [dns-privacy] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:47:24 -0000 For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls -d From nobody Wed Apr 23 07:26:57 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DE1A03B9; Wed, 23 Apr 2014 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 SOCoJTGiLMXr; Wed, 23 Apr 2014 07:26:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA991A03AE; Wed, 23 Apr 2014 07:26:51 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3NEQhVV073468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2014 07:26:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> Date: Wed, 23 Apr 2014 07:26:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> To: dns-privacy@ietf.org, dnsop X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/1L_hwpOxJUAIGs34XOS6KDU4NoI Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:26:52 -0000 On Apr 23, 2014, at 6:47 AM, Dan Wing wrote: > For discussion. >=20 > DNS queries and responses are visible to network elements on the = path > between the DNS client and its server. These queries and responses > can contain privacy-sensitive information which is valuable to > protect. An active attacker can send bogus responses causing > misdirection of the subsequent connection. >=20 > To counter passive listening and active attacks, this document > proposes the use of Datagram Transport Layer Security (DTLS) for = DNS, > to protect against passive listeners and certain active attacks. As > DNS needs to remain fast, this proposal also discusses mechanisms to > reduce DTLS round trips and reduce DTLS handshake size. The = proposed > mechanism runs over the default DNS port and can also run over an > alternate port. >=20 > http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls This proposes to run a binary protocol (DTLS) over port 53. It says "A = DNS client or server that does not implement this specification will not = respond to the incoming DTLS packets because they don't parse as DNS = packets (the DNS Opcode would be 15, which is undefined)." Has anyone run any tests against currently deployed recursive resolvers = and authoritative servers to see what they do when sent the initial DTLS = packet? --Paul Hoffman= From nobody Wed Apr 23 08:42:39 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5CD1A0016; Wed, 23 Apr 2014 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mLd25zmklyWx; Wed, 23 Apr 2014 08:42:32 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6851A020C; Wed, 23 Apr 2014 08:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1673; q=dns/txt; s=iport; t=1398267747; x=1399477347; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/z2ZHmUx+cVemdfFbFXsAPJ6lhRfpOkQOHimlDi7yCU=; b=LnVC/px6nPA/MVNhjO95q0JjXfxXfx37IFhZ2JMaoOJOWhhFatWKp1b4 Ka+eID2z6KPKatJYqXzuklQY02sdKhyuwlYrrtIgpbHcgI97xbI3dxyqo dMLNV/Y0w8TvVM2k7I50oLaIuBwN8w6Rari1eBlxcCQncTkV80NTIiPgG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAHHeV1OrRDoJ/2dsb2JhbABZgwZPxQqBGhZ0giUBAQEDATo/BQsLGC5XBhOIOQcOzxAXjiUzB4MkgRUEiWWPEIE3kR6DUR0 X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="108408994" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 23 Apr 2014 15:42:26 +0000 Received: from dhcp-10-33-190-27.cisco.com (dhcp-10-33-190-27.cisco.com [10.33.190.27]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3NFgPuH028572; Wed, 23 Apr 2014 15:42:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> Date: Wed, 23 Apr 2014 08:42:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/dYzNPL_lFfUxIQ9lt1A4p07y6X8 Cc: dns-privacy@ietf.org, dnsop Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:42:34 -0000 On Apr 23, 2014, at 7:26 AM, Paul Hoffman wrote: > On Apr 23, 2014, at 6:47 AM, Dan Wing wrote: >=20 >> For discussion. >>=20 >> DNS queries and responses are visible to network elements on the = path >> between the DNS client and its server. These queries and responses >> can contain privacy-sensitive information which is valuable to >> protect. An active attacker can send bogus responses causing >> misdirection of the subsequent connection. >>=20 >> To counter passive listening and active attacks, this document >> proposes the use of Datagram Transport Layer Security (DTLS) for = DNS, >> to protect against passive listeners and certain active attacks. As >> DNS needs to remain fast, this proposal also discusses mechanisms to >> reduce DTLS round trips and reduce DTLS handshake size. The = proposed >> mechanism runs over the default DNS port and can also run over an >> alternate port. >>=20 >> http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls >=20 > This proposes to run a binary protocol (DTLS) over port 53. It says "A = DNS client or server that does not implement this specification will not = respond to the incoming DTLS packets because they don't parse as DNS = packets (the DNS Opcode would be 15, which is undefined)." >=20 > Has anyone run any tests against currently deployed recursive = resolvers and authoritative servers to see what they do when sent the = initial DTLS packet? Paul, openssl s_client -dtls1 -connect 1.2.3.4:53 -debug substituting 1.2.3.4 for the server you want to test, and in another = window do tcpdump port 53. -d From nobody Wed Apr 23 08:49:15 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF49C1A03CA for ; Wed, 23 Apr 2014 08:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 DAUaVK_rDVB7 for ; Wed, 23 Apr 2014 08:06:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 616971A03CB for ; Wed, 23 Apr 2014 08:05:50 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo20so1163471obc.17 for ; Wed, 23 Apr 2014 08:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RuH2QP4G9aojT+MBF3Y1sRMD6l/UCIVs1xqpyKvzWvI=; b=KVfDL6Ikzb5CWh9miCg1KzcZIWuMLJohBTGf2OuxjLKoeuod8cXrMSQzocsaSzAxT4 S6LzMiT7DNMGT1OdeqwvHPMe+ZHXrqF6XwEABn2ocFnTggGOGeNyldT0Fs8rSoaiBns4 V9/s3Zx9pOL8pbLOgzzKxdNGQtYyARetWR6pijrAwcFLOM16eoy3/+Yf0rvG/Qfo58LM DxlrnkBKd1/8Lvw3b8yEskfI3Xh82sd2OJTnwlwZlDzuM0gN/j0bEjb9udB0J5WWV/a1 IHXwMwk5Ie34XzfXxYyooZWShVTuM39Q4vzmmWKw9lBu6OZdBcC+gmWO5ZLw38Aa9UC+ hPhw== X-Gm-Message-State: ALoCoQlS+0Dzqa6QiqKbo3z/fy8xR6joxZFXJVKAR6hLLXW04keBHqOzeWBdbRefq+2EQb36tfd6 MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr1640730obd.71.1398265544543; Wed, 23 Apr 2014 08:05:44 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Wed, 23 Apr 2014 08:05:44 -0700 (PDT) In-Reply-To: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> Date: Wed, 23 Apr 2014 08:05:44 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Dan Wing Content-Type: multipart/alternative; boundary=001a11c339e615e0c204f7b71116 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/gOj8n12_ojUs0FefyO4uaD7Az1Y X-Mailman-Approved-At: Wed, 23 Apr 2014 08:49:10 -0700 Cc: Prashanth Patil , "dnsop@ietf.org" , dns-privacy@ietf.org, Tirumaleswar Reddy Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:06:09 -0000 --001a11c339e615e0c204f7b71116 Content-Type: text/plain; charset=UTF-8 TLS seems like a poor choice for any new cryptographic transport, it is a very complicated protocol with a considerable amount of implementation complexity, computational and network costs. DTLS seems poorer still, as it is an adaptation of primitives never intended for datagram transmission. But feedback on the draft: * It's unclear how your protocol would really mitigate an active attacker sending bogus responses. Won't the attacker still be able to disrupt the DTLS session? Allowing session multiplexing by query-id likely amplifies this risk. * In DTLS, the ClientHello is in the plain - this presents opportunities for downgrade attacks and inference making. Considering the proposal advocates for hardcoding the certificate, why not just use a key from the off? * Some nameservers definitely don't just "not respond" when they get messages they don't understand :/ * Is the entire protocol subject to the simplest downgrade attack of all? Just cause the first server response to be dropped and regular DNS will be used? * How long should session state persist? * The network costs of certificate transmission probably pale in comparison to the computational costs of key negotiation. How should trivial key-exchange ddos attacks be prevented? * TLS Heartbeat messages do not permit asymmetric MTU discovery. On Wed, Apr 23, 2014 at 6:47 AM, Dan Wing wrote: > For discussion. > > DNS queries and responses are visible to network elements on the path > between the DNS client and its server. These queries and responses > can contain privacy-sensitive information which is valuable to > protect. An active attacker can send bogus responses causing > misdirection of the subsequent connection. > > To counter passive listening and active attacks, this document > proposes the use of Datagram Transport Layer Security (DTLS) for DNS, > to protect against passive listeners and certain active attacks. As > DNS needs to remain fast, this proposal also discusses mechanisms to > reduce DTLS round trips and reduce DTLS handshake size. The proposed > mechanism runs over the default DNS port and can also run over an > alternate port. > > http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls > > -d > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Colm --001a11c339e615e0c204f7b71116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

TLS seems like a poor choice for any new cryptogr= aphic transport, it is a very complicated protocol with a considerable amou= nt of implementation complexity, computational and network costs. DTLS seem= s poorer still, as it is an adaptation of primitives never intended for dat= agram transmission.

But feedback on the draft:

=C2= =A0 =C2=A0* It's unclear how your protocol would really mitigate an act= ive attacker sending bogus responses. Won't the attacker still be able = to disrupt the DTLS session? Allowing session multiplexing by query-id like= ly amplifies this risk.=C2=A0

=C2=A0 =C2=A0* In DTLS, the ClientHello is in the plain= - this presents opportunities for downgrade attacks and inference making. = Considering the proposal advocates for hardcoding the certificate, why not = just use a key from the off?

=C2=A0 =C2=A0* Some nameservers definitely don't ju= st "not respond" when they get messages they don't understand= :/

=C2=A0 =C2=A0* Is the entire protocol subject = to the simplest downgrade attack of all? Just cause the first server respon= se to be dropped and regular DNS will be used?=C2=A0

=C2=A0 =C2=A0* How long should session state persist?= =C2=A0

=C2=A0 =C2=A0* The network costs of certifi= cate transmission probably pale in comparison to the computational costs of= key negotiation. How should trivial key-exchange ddos attacks be prevented= ?

=C2=A0 =C2=A0* TLS Heartbeat messages do not permit asy= mmetric MTU discovery.=C2=A0

On Wed, Apr 23, 2014 at 6:47 AM, Dan Wing <dan@danwing.org<= /a>> wrote:
For discussion.

=C2=A0 =C2=A0DNS queries and responses are visible to network elements on t= he path
=C2=A0 =C2=A0between the DNS client and its server. =C2=A0These queries and= responses
=C2=A0 =C2=A0can contain privacy-sensitive information which is valuable to=
=C2=A0 =C2=A0protect. =C2=A0An active attacker can send bogus responses cau= sing
=C2=A0 =C2=A0misdirection of the subsequent connection.

=C2=A0 =C2=A0To counter passive listening and active attacks, this document=
=C2=A0 =C2=A0proposes the use of Datagram Transport Layer Security (DTLS) f= or DNS,
=C2=A0 =C2=A0to protect against passive listeners and certain active attack= s. =C2=A0As
=C2=A0 =C2=A0DNS needs to remain fast, this proposal also discusses mechani= sms to
=C2=A0 =C2=A0reduce DTLS round trips and reduce DTLS handshake size. =C2=A0= The proposed
=C2=A0 =C2=A0mechanism runs over the default DNS port and can also run over= an
=C2=A0 =C2=A0alternate port.

http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls

-d

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop



--
Colm
--001a11c339e615e0c204f7b71116-- From nobody Wed Apr 23 09:18:12 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36A61A0389; Wed, 23 Apr 2014 09:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 g0gq3B27hna9; Wed, 23 Apr 2014 09:17:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9612E1A0381; Wed, 23 Apr 2014 09:17:54 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3NGFYEq077591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2014 09:16:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Wed, 23 Apr 2014 09:16:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63843A6C-33AF-4A65-87FA-281FF9E996CC@vpnc.org> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> To: Dan Wing X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/FhezbsM42TuM-WyV8ECuQvxIIGc Cc: dns-privacy@ietf.org, dnsop Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:17:59 -0000 On Apr 23, 2014, at 8:42 AM, Dan Wing wrote: > On Apr 23, 2014, at 7:26 AM, Paul Hoffman = wrote: >=20 >> On Apr 23, 2014, at 6:47 AM, Dan Wing wrote: >>=20 >>> For discussion. >>>=20 >>> DNS queries and responses are visible to network elements on the = path >>> between the DNS client and its server. These queries and responses >>> can contain privacy-sensitive information which is valuable to >>> protect. An active attacker can send bogus responses causing >>> misdirection of the subsequent connection. >>>=20 >>> To counter passive listening and active attacks, this document >>> proposes the use of Datagram Transport Layer Security (DTLS) for = DNS, >>> to protect against passive listeners and certain active attacks. As >>> DNS needs to remain fast, this proposal also discusses mechanisms to >>> reduce DTLS round trips and reduce DTLS handshake size. The = proposed >>> mechanism runs over the default DNS port and can also run over an >>> alternate port. >>>=20 >>> http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls >>=20 >> This proposes to run a binary protocol (DTLS) over port 53. It says = "A DNS client or server that does not implement this specification will = not respond to the incoming DTLS packets because they don't parse as DNS = packets (the DNS Opcode would be 15, which is undefined)." >>=20 >> Has anyone run any tests against currently deployed recursive = resolvers and authoritative servers to see what they do when sent the = initial DTLS packet? >=20 > Paul, > openssl s_client -dtls1 -connect 1.2.3.4:53 -debug > substituting 1.2.3.4 for the server you want to test, and in another = window do tcpdump port 53. Sure. What were the results of your testing? --Paul Hoffman= From nobody Wed Apr 23 09:38:00 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C31A0221; Wed, 23 Apr 2014 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 fqvWAWBF-1GX; Wed, 23 Apr 2014 09:36:45 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id D10E51A01E6; Wed, 23 Apr 2014 09:36:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 667372C400B; Wed, 23 Apr 2014 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D3OmMxeycAhu; Wed, 23 Apr 2014 09:36:36 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 78EDF2C4004; Wed, 23 Apr 2014 09:36:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_173A909E-7037-488F-BF66-43FA249CBC06"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Nicholas Weaver In-Reply-To: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> Date: Wed, 23 Apr 2014 09:36:35 -0700 Message-Id: <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> To: Dan Wing X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/IGPUaq4nGb8R2vAYwpc1hRfEtvM X-Mailman-Approved-At: Wed, 23 Apr 2014 09:37:58 -0700 Cc: Prashanth Patil , dnsop@ietf.org, Nicholas Weaver , dns-privacy@ietf.org, Tirumaleswar Reddy Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:36:47 -0000 --Apple-Mail=_173A909E-7037-488F-BF66-43FA249CBC06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 23, 2014, at 6:47 AM, Dan Wing wrote: > For discussion. >=20 > DNS queries and responses are visible to network elements on the = path > between the DNS client and its server. These queries and responses > can contain privacy-sensitive information which is valuable to > protect. An active attacker can send bogus responses causing > misdirection of the subsequent connection. >=20 > To counter passive listening and active attacks, this document > proposes the use of Datagram Transport Layer Security (DTLS) for = DNS, > to protect against passive listeners and certain active attacks. As > DNS needs to remain fast, this proposal also discusses mechanisms to > reduce DTLS round trips and reduce DTLS handshake size. The = proposed > mechanism runs over the default DNS port and can also run over an > alternate port. >=20 > http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls a: With the need to do all the handshaking, you gain only a little from = doing dTLS over UDP rather than TLS over TCP. So why use UDP with all = its headaches? Just use TCP and conventional TLS rather than DTLS, = especially when you are talking about mucking with the handshake. b: DO NOT USE PORT 53 for this: There are far far too many networks = (1%+) that reinterpret DNS requests or just outright block all DNS to = non-approved servers, and more still which block non-DNS over DNS. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_173A909E-7037-488F-BF66-43FA249CBC06 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTV+wTAAoJEG2B1w+SDi/uLS0P/jt1E+g/CeDaZmlFKicY1sZG gU0kMNU++kBdAKKOSVwN4oFgJa3yff1uoQZpM1o0lsRYFgxQGyRlZxy9kWISXYar YJtk4Tm359R0KI9YDOiSs8OWC0WiPd9r5AV1RjqHUuREy6THMo2shc42bOoE4Evb jh/88G3a2sPqTD005mrwwZneVhOttYiF59JQzOZbIPUDFX2nM9+bWf09bY/6FNUo yfaMOBilHHWR0AYu9sj8J9eMRHxJGrYX2OB0OTRl863CJoFp3LLwJOTTbdvOg05n NMjBaOCYcBV8ZAqrZ9OdRGJ5AdnqvGfehNrFvJv6/j0POUgrZA39h0eB8XhJpRYg d4eq/+jW4tIOiiqWij5621qnXm23PVEc6Ee3xEKtHBSgbmfl8gXug/Ab6OE8nVbq hAadm6124AIGVte8FqAvGpsZz71idwFI5/Bul+vogn54sL3yA8vfPiNVSJGFE2R7 4O2INb9H0U2tLnylUhMPLJQ0ehyStlvWth3BSkXwWdQnsEhyp23gbXoQvIK2C7E3 MlWXH2AFph0qTwaslXayXJ1NGiXs/EggKNSSDwiuuotSFWtm4vSVLy9DwxFCbxdn 1rpOWgcobXp3i7Pz5uNV2JH2KkHb7ott1ViBy6IjmsJA2Y3V62fUQEzweMpvqV4z liSUQbHzK1I3oRVd2g0a =QVYh -----END PGP SIGNATURE----- --Apple-Mail=_173A909E-7037-488F-BF66-43FA249CBC06-- From nobody Wed Apr 23 11:44:48 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60A41A049A; Wed, 23 Apr 2014 11:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Z2JNZLm4E7p7; Wed, 23 Apr 2014 11:41:17 -0700 (PDT) Received: from ss.vix.su (ss.vix.su [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB0061A0435; Wed, 23 Apr 2014 11:41:16 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:4c1:8feb:f05:1318] (unknown [IPv6:2001:559:8000:cb:4c1:8feb:f05:1318]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.su (Postfix) with ESMTPSA id C6A54EBC92; Wed, 23 Apr 2014 18:41:10 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <53580948.9070404@redbarn.org> Date: Wed, 23 Apr 2014 11:41:12 -0700 From: Paul Vixie User-Agent: Postbox 3.0.9 (Windows/20140128) MIME-Version: 1.0 To: Dan Wing References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> In-Reply-To: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/F5ZLw_LwK-nOIg_Q6Klu4hva39E X-Mailman-Approved-At: Wed, 23 Apr 2014 11:44:47 -0700 Cc: Prashanth Patil , dnsop@ietf.org, dns-privacy@ietf.org, Tirumaleswar Reddy Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:41:19 -0000 for reasons well-spoken up-thread, if we're going to add a dns transport, i'd like it to be RFC 6013 style TCP (in which session context can be compressed and retained after FIN for full-window-size restart, and which permits the query to be bundled into the SYN packet), or at a minimum, SCTP. DTLS does not solve any of the problems described at . vixie From nobody Wed Apr 23 13:00:33 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB51A0502; Wed, 23 Apr 2014 13:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 55DVNcI-4sQ4; Wed, 23 Apr 2014 13:00:19 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E11291A0429; Wed, 23 Apr 2014 13:00:18 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3FEBA8009A; Wed, 23 Apr 2014 16:00:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1398283212; bh=bR6SoOv4f4c3YVShY1W/3HcgnNCK4V76YmcYzhqw9bE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KWzhy7YQttjS1N0/2CityuBuPXoKNQc/6VqKE4ZPs/iZoGnmRDzKAJC/vx0B3bVvF /MLG97Ew9hscbVHb90UzQ6uZfGET74vjX0tCV0p+SDTeOAzlVpaYF0u5c8NRXOGMne 6DpMCk3Z1Cpldr/skojFvwdcI0MpGsSKpkt20goM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3NK09MH000842; Wed, 23 Apr 2014 16:00:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 23 Apr 2014 16:00:09 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> Message-ID: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/-v1lzbfGv6wDzPQAA-aGBjDGBBI Cc: dnsop , dns-privacy@ietf.org Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:00:23 -0000 On Wed, 23 Apr 2014, Nicholas Weaver wrote: > b: DO NOT USE PORT 53 for this: There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS over DNS. Yes, I fully agree with this. It was a major objection for me to CurveDNS as well No, I fully disagree with this. Port 53 TCP has a much better chance at working these days than a random other newly assigned port. I'll go get a comfort coffee now..... Paul ps. leaning towards "custom crypto that fits in DNS formats" From nobody Wed Apr 23 13:30:08 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499151A0644; Wed, 23 Apr 2014 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 y0wbhWnaoGdK; Wed, 23 Apr 2014 13:27:49 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46D1A063B; Wed, 23 Apr 2014 13:27:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E9E242C404A; Wed, 23 Apr 2014 13:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZNzLmH+Mbjho; Wed, 23 Apr 2014 13:27:40 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9620C2C4049; Wed, 23 Apr 2014 13:27:38 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_79E895E5-3641-4C03-80AD-A8ADED576DDA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Nicholas Weaver In-Reply-To: Date: Wed, 23 Apr 2014 13:27:37 -0700 Message-Id: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> To: Paul Wouters X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/AVMbS0aqbzxnMDUQdgi_6FMIsbI X-Mailman-Approved-At: Wed, 23 Apr 2014 13:30:04 -0700 Cc: dnsop , Nicholas Weaver , dns-privacy@ietf.org Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:27:51 -0000 --Apple-Mail=_79E895E5-3641-4C03-80AD-A8ADED576DDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: > No, I fully disagree with this. Port 53 TCP has a much better chance = at > working these days than a random other newly assigned port. Not true. Port 53 is far more molested than "random": INBOUND firewall = rules prevent you from running new services without firewall rule = modifications, but outbound blocking is far less common. (Our test port = for this is TCP 1947 with Netalyzr). -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_79E895E5-3641-4C03-80AD-A8ADED576DDA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTWCI6AAoJEG2B1w+SDi/umSwP/RhAp8f8nrlwu8MvJxrNqoIB Fk9TKfEPo5AZw6iPoeMISuELIqvbgf1EtbUSXVW8klI00+nVpCbJht1SbDNDLWDN auFohWFmOMk37V2O/RZTVk2RQDIeOu7JZInS6QtMwbCnsWUWt1VUHLzoqM+Ojrtd C4t5CtpehdDhnufTz4Z+kZ80FIQBTvDuSqYXd+qbmuBdrB4int8swM6iyS7UCDh3 QrgohThs1fTeUxw0pNYrpSpWEZPoHFXmqNQDUcLwTaWxDYG2mfW3PoBvdOB81t3V 9FGo1lgMWsrsXuxJIeCwp7+Mnx9eDztvRgT9UbMjxoaC0+fpw7leDtP+Oo6f/cXJ m1NUgM4//7ThS1hxrxT8/o/lFqz503EdK/ZvFkqL2Beqi/d6aAEqOAmT2L5VZ6dI zh5Kp5PiVrJq61xPQQKkid2MkoHPXmlnftBopAY/Wk7mIMjkatvslYYfCZctuxCw o3cXFHbzgjf7px1sT5IeJbQIFV8CKbuqhhWXMXOBbYVb4U9wo0PZFPz5mxt/oF1L ComN1khX72lKo/6tGjbsd7s/IxWyi81Gd/dhCfDOD0gG2fWwLhahaijQmaF0cCzp av6U8fY6JUyJ3su4Eg+I0oJDQUANRzLl2LOqzuKXfnd01Pevv1mvOntnGRDCcd8T L+a5rUdiirQ1TVmfT8Yr =zt/2 -----END PGP SIGNATURE----- --Apple-Mail=_79E895E5-3641-4C03-80AD-A8ADED576DDA-- From nobody Wed Apr 23 15:32:47 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4321A0705; Wed, 23 Apr 2014 15:32:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 AbrUjvKLP09l; Wed, 23 Apr 2014 15:32:42 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0E1A06F5; Wed, 23 Apr 2014 15:32:41 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ec20so1026041lab.22 for ; Wed, 23 Apr 2014 15:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXir4oHf7AadMrQ+yQ1or9KS5gSeGbxrYyJCIL2WxaI=; b=gGot6+q6ZRh6K65aXC2CLazvUMQTuwgRvX8Zuc+AcwteugbRzbCoAlyl+XBx/glJrm NE/BPAYEuut8L1OZEAkLmpCoqWF8zMIMEQDWDC8CAFlDiRkRiJQcBbeb5/yZQI5HvNUa jY4fBIkBXDPmAkVo7YeF0E1pi+Xj0utkOGn/eq8K5l980aBcYv4R1uSikpMsP/MCc9MJ jzO94NKsX20CwDxXW0D8L3aPY9Yb+MG32r0P/PGYQa4KR2SebksPv8DDbEdJiZFdbOOF d90ty+PeTFJ3TF7/FAGW3jiBRv6VpswVKrfjfzHueNz4bXqQiAEI4Qc3YqPxTgoF/IJy wjCw== MIME-Version: 1.0 X-Received: by 10.152.42.196 with SMTP id q4mr37610911lal.14.1398292355324; Wed, 23 Apr 2014 15:32:35 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 23 Apr 2014 15:32:35 -0700 (PDT) In-Reply-To: <53580948.9070404@redbarn.org> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <53580948.9070404@redbarn.org> Date: Wed, 23 Apr 2014 18:32:35 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Vixie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/MLtGZeD-lXvdE2IGwPq1-nFY8U4 Cc: Prashanth Patil , Dan Wing , dns-privacy@ietf.org, "dnsop@ietf.org" , Tirumaleswar Reddy Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:32:44 -0000 I agree that DTLS does not solve any problems for DNS. The basic problem is that DTLS is still based around the notion of a session where the server stores per connection state. So you might as well use TLS for this application. But TLS is not the only option available. Or rather using TLS to secure DNS is not the only option possible. If we use TLS to do a kerberos like key exchange, we can generate a shared secret and a ticket which can then be used to secure all future communications without changing from UDP. We can't run over port 53 (trust me, I tried). But we can nominate the ports to use in the key exchange setup. The resulting protocol works in about 93-98% of network situations (depending on how you measure). So you still need a Web Service backup. But it does work pretty well. On Wed, Apr 23, 2014 at 2:41 PM, Paul Vixie wrote: > for reasons well-spoken up-thread, if we're going to add a dns > transport, i'd like it to be RFC 6013 style TCP (in which session > context can be compressed and retained after FIN for full-window-size > restart, and which permits the query to be bundled into the SYN packet), > or at a minimum, SCTP. > > DTLS does not solve any of the problems described at > . > > vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Website: http://hallambaker.com/ From nobody Wed Apr 23 16:11:20 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B621A072B for ; Wed, 23 Apr 2014 16:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 NJO9KoWocV7d for ; Wed, 23 Apr 2014 16:11:10 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id C523A1A072A for ; Wed, 23 Apr 2014 16:11:10 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id uy17so202083igb.15 for ; Wed, 23 Apr 2014 16:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bPDO9LbLCbiG74O5vvo0H+CoCxSfXgKLbDQo1n06KR4=; b=fzqKSeanweoIehfs+5A641/OEHS/diTaXNalACgkJQdZe7rOOXQwEF0PLBMcIVV2dW accF1tinIKJaW065ozNBtX1HDaSbrRdC8lrBLZD5lzx9BaEJysf+QBIhLwueHFw4wzXO e16drDW35jNFGAWRqrGwlp8XDy7NTYiz/nXJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bPDO9LbLCbiG74O5vvo0H+CoCxSfXgKLbDQo1n06KR4=; b=S74K318bfZUDnd/Vr3J8w+3dlTTcm2BaX00H8IBMuy4m3xIGPDXX/JLtHRlDo3JlVK uwOv+5rEoD1LdwVxNTYlS+Uj+bUdyFX852vM4acIDaE94PBQjf4cFv82j+tHMtRakjl7 6jZpllfNQ8zX8Q+9KBT+MjTWBvfdeo7FFcz00nbPED+r+5NsKSAj8hYO5s/7qhgPWfwT p1MuF1nQa1uXFR/o3TWuyW2MbxQHwCWbjvkMHCQj42zLVt14YflnDPndBDh5GNhizv1H nUINK1Yl3ew1VZSPYdPKfk3F0dr2RNJeJGRBlscMKD8piQbXXeIjJXlPoXfB6D7LAop+ BBfw== X-Gm-Message-State: ALoCoQkAev7toiLMscIhh/PVqcaHYtaWFpXk5eCp2Uqhy7rCPd/PC7wapw8J1mk7/r4nC3gkLIzD X-Received: by 10.42.24.76 with SMTP id v12mr17981246icb.59.1398294664759; Wed, 23 Apr 2014 16:11:04 -0700 (PDT) Received: from dh27.r1.hopcount.ca (24-52-234-221.cable.teksavvy.com. [24.52.234.221]) by mx.google.com with ESMTPSA id b6sm9056568igm.2.2014.04.23.16.11.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 16:11:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Abley In-Reply-To: Date: Wed, 23 Apr 2014 19:11:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <53580948.9070404@redbarn.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/rc2d9oQLucxAZolF1_o1-w5px7k Cc: Prashanth Patil , "dnsop@ietf.org" , Paul Vixie , Tirumaleswar Reddy , dns-privacy@ietf.org, Dan Wing Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:11:19 -0000 On 23 Apr 2014, at 18:32, Phillip Hallam-Baker wrote: > We can't run over port 53 (trust me, I tried). You have doubts about the approach described in = draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I = find that draft (and the accompanying t-dns technical report) to be = quite compelling. If you have doubts, are you mainly concerned about transactions between = recursive and authority servers, or between stub resolvers and recursive = servers? Joe= From nobody Wed Apr 23 16:30:56 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950E1A0730; Wed, 23 Apr 2014 16:30:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qUYcLQ0lWNaO; Wed, 23 Apr 2014 16:30:50 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 07D4B1A0736; Wed, 23 Apr 2014 16:30:49 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u14so1380821lbd.33 for ; Wed, 23 Apr 2014 16:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ym5ldT2QKuAcroauqdUwmbnP8gBpMd+liqy97Mn8oqU=; b=bxcO70n8sE58oVRrFXQMcpFiMx65LaRyJcF2j4hHvU07iTTnD0/yS5m6i1rHKhDLCe /o/6E7oc0z6AqD/kHShZ+8/E/BBRg3LAqQwMIhL3S7TLocdjYQbnBOQfcocrsFAFm65I 1eQU/Hka3+34cSCvhwMwhgT7VpcwIj72GH7pS2E8wWgBq6On0m88iOLZc0wmNS8ERdrF OVgTYh5CVpTBLyRSIIfjTlJKIYzL0qF17GiQr8O5ntgiRpt9eBrCcRsU8CJma8U4b4YK tBJBaPy+p3WEMOCyCPyElfOKa1bcMCmFVA6SKvGe2yjG1dmWsOgEVPQk1Ebh98a9efLN PzIg== MIME-Version: 1.0 X-Received: by 10.112.200.130 with SMTP id js2mr33333525lbc.28.1398295843422; Wed, 23 Apr 2014 16:30:43 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 23 Apr 2014 16:30:43 -0700 (PDT) In-Reply-To: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <53580948.9070404@redbarn.org> Date: Wed, 23 Apr 2014 19:30:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/TNlApXPjZl0KOrDDnJWjqa4SAik Cc: Prashanth Patil , "dnsop@ietf.org" , Paul Vixie , Tirumaleswar Reddy , dns-privacy@ietf.org, Dan Wing Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:30:53 -0000 On Wed, Apr 23, 2014 at 7:11 PM, Joe Abley wrote: > > On 23 Apr 2014, at 18:32, Phillip Hallam-Baker wrote: > >> We can't run over port 53 (trust me, I tried). > > You have doubts about the approach described in draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I find that draft (and the accompanying t-dns technical report) to be quite compelling. > > If you have doubts, are you mainly concerned about transactions between recursive and authority servers, or between stub resolvers and recursive servers? I meant Port 53 UDP. There is just too much middlebox stuff that gets in the way. Port 53 TCP might be viable. -- Website: http://hallambaker.com/ From nobody Wed Apr 23 18:47:14 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E301A076B; Wed, 23 Apr 2014 18:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 ofwcxMKSS9Zh; Wed, 23 Apr 2014 18:47:10 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 42A8B1A02D2; Wed, 23 Apr 2014 18:47:07 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8296C8009A; Wed, 23 Apr 2014 21:47:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1398304020; bh=lpnwH+oOSL1c1oHA0xKZrcDW8MEMIFCAeVPr4D12XMY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=I9y0CbGh8XkLAGaQedzIZ/0zKTGG2D00/Cpa81vuaM7TMGmEyW7jKPhfhOP5tNEND Llk5a8AWy80MpoUiu8VGG6DkESzpF7nsr7yB8U6uwnRPSYjUjXeYAwfQVbey5DLWu/ vVlhv6Ccz8cFHjDN/98H6qRbSBmYsB3IIgvE1ztI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3O1kxHB018285; Wed, 23 Apr 2014 21:47:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 23 Apr 2014 21:46:59 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: Message-ID: References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/2H4cQ5oOMkhAAK9Z61fXmAafYRA Cc: dnsop , dns-privacy@ietf.org Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 01:47:12 -0000 On Wed, 23 Apr 2014, Nicholas Weaver wrote: > On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: >> No, I fully disagree with this. Port 53 TCP has a much better chance at >> working these days than a random other newly assigned port. > > Not true. Port 53 is far more molested than "random": INBOUND firewall rules prevent you from running new services without firewall rule modifications, but outbound blocking is far less common. (Our test port for this is TCP 1947 with Netalyzr). Provided you use "traditional DNS" perhaps? Once you account for roaming around different network, I think you will see port 53 us regularly transparently proxied to a local DNS server. When those see something they don't understand because its not "traditional DNS", you'll lose. Paul From nobody Wed Apr 23 19:02:19 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2940D1A02D4; Wed, 23 Apr 2014 19:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 dMbUsSzi0dHm; Wed, 23 Apr 2014 19:02:01 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B41A028F; Wed, 23 Apr 2014 19:02:00 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id CF6643493B3; Thu, 24 Apr 2014 02:01:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C306C160064; Thu, 24 Apr 2014 02:04:35 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9275D16005B; Thu, 24 Apr 2014 02:04:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B5C6E144FC30; Thu, 24 Apr 2014 12:01:48 +1000 (EST) To: Paul Wouters From: Mark Andrews References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <4E9BF8F0-5852-49CD-960A-1147D72C306B@icsi.berkeley.edu> In-reply-to: Your message of "Wed, 23 Apr 2014 21:46:59 -0400." Date: Thu, 24 Apr 2014 12:01:48 +1000 Message-Id: <20140424020148.B5C6E144FC30@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/Kf3dqdSIpywbmkruASP6BRzrAG0 Cc: dnsop , Nicholas Weaver , dns-privacy@ietf.org Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 02:02:05 -0000 In message , Paul Wouters writes: > On Wed, 23 Apr 2014, Nicholas Weaver wrote: > > > On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: > >> No, I fully disagree with this. Port 53 TCP has a much better chance at > >> working these days than a random other newly assigned port. > > > > Not true. Port 53 is far more molested than "random": INBOUND firewall rules prevent you from running new services without firewall rule modifications > , but outbound blocking is far less common. (Our test port for this is TCP 1947 with Netalyzr). > > Provided you use "traditional DNS" perhaps? Once you account for roaming > around different network, I think you will see port 53 us regularly > transparently proxied to a local DNS server. When those see something > they don't understand because its not "traditional DNS", you'll lose. > > Paul Which doesn't handle RD=0 queries and often doesn't handle DNSSEC. This still isn't a reason to not use port 53. It is a reason to write "Transparent DNS Proxies Considered Harmful". It is a reason to have a DHCP{v6} option for "hotspot registration". Mark > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Apr 23 23:13:21 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E71E1A079F; Wed, 23 Apr 2014 23:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.878 X-Spam-Level: X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 kiFfftM35jAW; Wed, 23 Apr 2014 23:12:06 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8D1A0062; Wed, 23 Apr 2014 23:12:05 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D95B228044D; Thu, 24 Apr 2014 08:11:58 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id D388A2803DE; Thu, 24 Apr 2014 08:11:58 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id D1CD54C007F; Thu, 24 Apr 2014 08:11:28 +0200 (CEST) Date: Thu, 24 Apr 2014 08:11:28 +0200 From: Stephane Bortzmeyer To: Paul Hoffman Message-ID: <20140424061128.GA27677@nic.fr> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> <63843A6C-33AF-4A65-87FA-281FF9E996CC@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63843A6C-33AF-4A65-87FA-281FF9E996CC@vpnc.org> X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.13-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/h-ZDSYCeLYjgnqliwo6ZTJU8BNk Cc: dns-privacy@ietf.org, dnsop , Dan Wing Subject: Re: [dns-privacy] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:12:13 -0000 On Wed, Apr 23, 2014 at 09:16:29AM -0700, Paul Hoffman wrote a message of 39 lines which said: > Sure. What were the results of your testing? I quickly tested with .FR authoritative name servers and both NSD and BIND seem to silently ignore the incoming request. No response is seen coming back. 08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF], proto UDP (17), length 192) 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| [0q] 0/0/0 (164) 08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF], proto UDP (17), length 192) 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| [0q] 0/0/256 ar: ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] 08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF], proto UDP (17), length 192) 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| [0q] 0/0/512 ar: ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] From nobody Thu Apr 24 05:42:28 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5581A01C1 for ; Thu, 24 Apr 2014 05:42:22 -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] autolearn=ham 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 PQpCHy-re284 for ; Thu, 24 Apr 2014 05:42:14 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDA1A01D6 for ; Thu, 24 Apr 2014 05:42:14 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 08193880E9 for ; Thu, 24 Apr 2014 05:42:09 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CFDEE71B0001 for ; Thu, 24 Apr 2014 05:42:08 -0700 (PDT) Message-ID: <535906B7.2000106@innovationslab.net> Date: Thu, 24 Apr 2014 08:42:31 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dns-privacy@ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TICUslonwlSQ3WvJxUnhQgpnQDTl7vRmu" Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/JrottV4MAfVd2nMCDwBLKUTY9Dg Subject: [dns-privacy] Back to the core effort X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:42:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TICUslonwlSQ3WvJxUnhQgpnQDTl7vRmu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I would like to encourage folks to return focus to the main effort of getting the problem statement document completed. That will drive any effort to charter a WG to formulate and assess any solutions in this space. Regards, Brian --TICUslonwlSQ3WvJxUnhQgpnQDTl7vRmu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTWQa3AAoJEBOZRqCi7goqTx0H/Ah+xsvJBWPu2gWtB/ukIpSC DCUDdEA9P+EbaUIG85e9qIqpb5vzXkSKd8cqpLMetM0sKvvXnjX9ifHgrP839xwg zcVKIxoQKQ6m3UyjRFPmwEd4IPCufsQ4GY1/D+fAs3qOKKr7o9gekHnrwO7DfJuj CNJGZRtOzkUYLiYQlPfbjX72RFMSjRO7YC/k9lIYz5pjwIKjxAdoToLAJElMxEfH iCZN74B3i6qTXMc/9d3VNTZPwxlhkOhX6VmNs/a0ZuVFuiLr5h0Tb6vjHh4Krsli 1BmjFulwNmUR+isMhbjMfEmbom9yCR/rii5sB3Eq3gVwA+kq4m3kreLksqn/AH4= =HQ95 -----END PGP SIGNATURE----- --TICUslonwlSQ3WvJxUnhQgpnQDTl7vRmu-- From nobody Thu Apr 24 06:27:36 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD91A01E3; Thu, 24 Apr 2014 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 K0O3hVfNAyPp; Thu, 24 Apr 2014 06:27:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 584DF1A01B3; Thu, 24 Apr 2014 06:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1079; q=dns/txt; s=iport; t=1398346045; x=1399555645; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=jUTSWzJLQOXA9uRYl94W8mgEOJLqJUVZhe93D5LeJYA=; b=R328L/xJbjR0wHS8wKqyWhHB1i40/UFq/ROxYToqF8IiWTer0zpo1KcM aMfXzhN6Q03Uo5EtO/jYKAJH/TETsNBQwEGYACTIlMEC6ip376vdTXjdc HOM4R62ri8EA/H4Mbir8OCyjLTde/w8mNO6aOzcLNPx+0E6nVtwcB+wGH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADwQWVOtJA2J/2dsb2JhbABZgwZPV8Q2gRwWdIIlAQEBAwE6PwwGAQgRBAEBCxQJORQJCQEEAQ0FCIgxCA3LFBeOExQxDYMegRUEmi2RHoMxgis X-IronPort-AV: E=Sophos;i="4.97,919,1389744000"; d="scan'208";a="320124605" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 24 Apr 2014 13:27:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3ODRPRQ030319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 13:27:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 08:27:24 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Paul Vixie , Dan Wing Thread-Topic: [DNSOP] DNS over DTLS (DNSoD) Thread-Index: Ac9fwOrh+Fru7AYFQ0a7FrrXTvzoUQ== Date: Thu, 24 Apr 2014 13:27:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431A47B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.37.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/GjPlTmjifgFfC-DmZ0DTrxZMB-I Cc: "Prashanth Patil \(praspati\)" , "dnsop@ietf.org" , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:27:33 -0000 > -----Original Message----- > From: Paul Vixie [mailto:paul@redbarn.org] > Sent: Thursday, April 24, 2014 12:11 AM > To: Dan Wing > Cc: dnsop@ietf.org; dns-privacy@ietf.org; Prashanth Patil (praspati); > Tirumaleswar Reddy (tireddy) > Subject: Re: [DNSOP] DNS over DTLS (DNSoD) >=20 > for reasons well-spoken up-thread, if we're going to add a dns transport,= i'd like > it to be RFC 6013 style TCP (in which session context can be compressed a= nd > retained after FIN for full-window-size restart, and which permits the qu= ery to > be bundled into the SYN packet), or at a minimum, SCTP. SCTP has problems with Firewall and NAT traversal, hence WebRTC is using SC= TP over DTLS over DNS (http://tools.ietf.org/html/draft-ietf-rtcweb-data-ch= annel-08). DNSoD does not require server-side DTLS state, this is achieved = by the server sending ticket to the DTLS client using the mechanism explain= ed in RFC 5077. -Tiru >=20 > DTLS does not solve any of the problems described at > . >=20 > vixie From nobody Thu Apr 24 06:28:58 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24E91A01B3; Thu, 24 Apr 2014 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 dkIKUcbphGJU; Thu, 24 Apr 2014 06:28:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 668481A0232; Thu, 24 Apr 2014 06:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1451; q=dns/txt; s=iport; t=1398346125; x=1399555725; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=Vc01FIVFrPt2cuRZke4zbX6soKVIzlLE2/y9tF1Wwkc=; b=HBs3MhNEZ4228WE+ASXRGBYeNfeupFJptZwF4X2toBfJBQGhzDyLILxw YzlAcFFLQSVhMf5l9P9vikyi1oOlBIbov5ieftHNS79JWIZJmW1H0spzV v7QsO43NZiZVfRyKcPzVUEF5X7xlNycKd5jFS2/6ZXXKmrHOL17M/xtAN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPYQWVOtJA2F/2dsb2JhbABWAw4IgnBPV8Q2gRoWdIIlAQEBAwE6PwwGAQgOAwQBAQEKFAk5FAkJAQQBDQUIiDEIDcsTF44nIRANC4MTgRUEmi2RHoJxQIIr X-IronPort-AV: E=Sophos;i="4.97,919,1389744000"; d="scan'208";a="320030191" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 24 Apr 2014 13:28:45 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3ODSjr9028708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 13:28:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 08:28:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Nicholas Weaver , Paul Wouters Thread-Topic: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) Thread-Index: Ac9fwRqmYIVmUvtNTl6GZl6OLWdUsA== Date: Thu, 24 Apr 2014 13:28:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.37.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/_QE6q25nzQ6SOSiOEAbC2JFfaAE Cc: dnsop , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:28:56 -0000 > -----Original Message----- > From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Nich= olas > Weaver > Sent: Thursday, April 24, 2014 1:58 AM > To: Paul Wouters > Cc: dnsop; Nicholas Weaver; dns-privacy@ietf.org > Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) >=20 >=20 > On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: > > No, I fully disagree with this. Port 53 TCP has a much better chance > > at working these days than a random other newly assigned port. On the contrary, Firewalls are configured today to permit UDP port 53 and b= lock TCP port 53. Why should firewalls change their configuration ? DNSoD does not require any changes to the Firewall configuration. Browsers = already support DTLS because of WebRTC (SRTP-DTLS for media streams, SCTP o= ver DTLS over UDP for data channels). Cheers, -Tiru >=20 > Not true. Port 53 is far more molested than "random": INBOUND firewall = rules > prevent you from running new services without firewall rule modifications= , but > outbound blocking is far less common. (Our test port for this is TCP 194= 7 with > Netalyzr). >=20 >=20 > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc From nobody Thu Apr 24 06:52:43 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F51A0232; Thu, 24 Apr 2014 06:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Kt_rFj6ScChe; Thu, 24 Apr 2014 06:52:34 -0700 (PDT) Received: from nox.guxx.net (nox.guxx.net [78.46.109.173]) by ietfa.amsl.com (Postfix) with ESMTP id C9DA51A026F; Thu, 24 Apr 2014 06:52:30 -0700 (PDT) Received: by nox.guxx.net (Postfix, from userid 65534) id CB132DB830C; Thu, 24 Apr 2014 15:52:23 +0200 (CEST) Received: from [10.19.6.192] (tmo-100-206.customers.d1-online.com [80.187.100.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nox.guxx.net (Postfix) with ESMTPSA id AA95CDB8107; Thu, 24 Apr 2014 15:52:22 +0200 (CEST) References: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> X-Mailer: iPhone Mail (11D167) From: Ralf Weber Date: Thu, 24 Apr 2014 15:52:20 +0200 To: "Tirumaleswar Reddy (tireddy)" Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/NWXj0gDqIUCWvSCGB7aRjSI5Ckc Cc: dnsop , Paul Wouters , Nicholas Weaver , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:52:39 -0000 Moin! On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" w= rote: >> -----Original Message----- >> From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Nich= olas >> Weaver >> Sent: Thursday, April 24, 2014 1:58 AM >> To: Paul Wouters >> Cc: dnsop; Nicholas Weaver; dns-privacy@ietf.org >> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) >>=20 >>=20 >>> On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: >>> No, I fully disagree with this. Port 53 TCP has a much better chance >>> at working these days than a random other newly assigned port. >=20 > On the contrary, Firewalls are configured today to permit UDP port 53 and b= lock TCP port 53. Why should firewalls change their configuration ? I know lots of firewalls that also allow TCP/53, but the real problem with a= ll these middle boxes that make changing DNS hard is that they believe to un= derstand the full protocol and only pass what they think is right. So everyt= hing new we come up will be dropped (Been there, done that). We have to be v= ery careful with changes to the DNS protocol if we want them to be deployed = =20 So long Ralf=20 Sent from my iPhone= From nobody Thu Apr 24 07:19:54 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE61A02AD; Thu, 24 Apr 2014 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 fiQSg1LhgmBB; Thu, 24 Apr 2014 07:19:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2BC1A02C8; Thu, 24 Apr 2014 07:19:26 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3OEJFpb034835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2014 07:19:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140424061128.GA27677@nic.fr> Date: Thu, 24 Apr 2014 07:19:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <995CF19C-6E1E-4282-BEA1-9991214E6653@vpnc.org> References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> <63843A6C-33AF-4A65-87FA-281FF9E996CC@vpnc.org> <20140424061128.GA27677@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/AaiUD_5Fy0bPOYRe02NfSbjIlEA Cc: dns-privacy@ietf.org, dnsop , Dan Wing Subject: Re: [dns-privacy] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:19:27 -0000 On Apr 23, 2014, at 11:11 PM, Stephane Bortzmeyer = wrote: > On Wed, Apr 23, 2014 at 09:16:29AM -0700, > Paul Hoffman wrote=20 > a message of 39 lines which said: >=20 >> Sure. What were the results of your testing? >=20 > I quickly tested with .FR authoritative name servers and both NSD and > BIND seem to silently ignore the incoming request. No response is seen > coming back. >=20 > 08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF], > proto UDP (17), length 192) > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > [0q] 0/0/0 (164) > 08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF], > proto UDP (17), length 192) > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > [0q] 0/0/256 ar: > = ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=3D= M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^= @5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^= @2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-= ^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] > 08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF], > proto UDP (17), length 192) > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > [0q] 0/0/512 ar: > = ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=3D= M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^= @5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^= @2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-= ^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] Thanks, this is the kind of data I was looking for. The draft seems to = assume that the server will give an error, not no response. --Paul Hoffman= From nobody Thu Apr 24 07:53:20 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBAA1A032E; Thu, 24 Apr 2014 07:53:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 sTC_UGQh0fhN; Thu, 24 Apr 2014 07:53:15 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 318E81A031E; Thu, 24 Apr 2014 07:53:14 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so2072247lab.24 for ; Thu, 24 Apr 2014 07:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9ypnZg73Plm/vzEDTSoc7MHGQyMeJrIeOd5PLLWVdU4=; b=MlUDlXDu2Bu+69jcLj5Q4Cl8noNvIqaRUYVTbQMjKNdUkLq7ugkfQaIeziDfYYkniP bwyLWHVZEN78ifYx7pP3TYJMTvKnE3Ssqy8lcrqXeVz6RHUvVume2D3NCiEApZYCWeMU 4zPjnbrJsJkQTlLCRvIQk6ejY6R5bu5NcF149pQ0iaPaux8uwgZ4V5juHIag/9b39IHn j0lNfr7ozEd4IHDVI9sNXejRHjWOC5BByosKlDZ7C/fTkSFhG0ZmPHRzVMnzrXBgj7DU YAZZRTybvELUHmv4A3T/xizTfWe3gSx88cWDTitjpbVox7R6ApYFmME0sYF3P7clxo1J xE5Q== MIME-Version: 1.0 X-Received: by 10.112.87.226 with SMTP id bb2mr1473272lbb.29.1398351188430; Thu, 24 Apr 2014 07:53:08 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 24 Apr 2014 07:53:08 -0700 (PDT) In-Reply-To: <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> References: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> Date: Thu, 24 Apr 2014 10:53:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Ralf Weber Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/H6y4BnKZi1XqqIrM-0opnybXaCw Cc: dnsop , Paul Wouters , Nicholas Weaver , "dns-privacy@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:53:17 -0000 On Thu, Apr 24, 2014 at 9:52 AM, Ralf Weber wrote: > Moin! > > > On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" wrote: > >>> -----Original Message----- >>> From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Ni= cholas >>> Weaver >>> Sent: Thursday, April 24, 2014 1:58 AM >>> To: Paul Wouters >>> Cc: dnsop; Nicholas Weaver; dns-privacy@ietf.org >>> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) >>> >>> >>>> On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: >>>> No, I fully disagree with this. Port 53 TCP has a much better chance >>>> at working these days than a random other newly assigned port. >> >> On the contrary, Firewalls are configured today to permit UDP port 53 an= d block TCP port 53. Why should firewalls change their configuration ? > I know lots of firewalls that also allow TCP/53, but the real problem wit= h all these middle boxes that make changing DNS hard is that they believe t= o understand the full protocol and only pass what they think is right. So e= verything new we come up will be dropped (Been there, done that). We have t= o be very careful with changes to the DNS protocol if we want them to be de= ployed +1 If you want to use TLS with DNS then use port 443. One of the effects of firewalls is that we now only have three ports for all protocols: Port 80/UDP: Non SSL traffic Port 443/TCP: SSL traffic Port 53/UDP: DNS Which is why the HTTP/2.0 crowd have adopted 'always TLS', not for encryption, they want to bypass firewalls. And the reason some of us are pushing back on that is that some of them propose weakening TLS to make this practical. Now this approach is of course reprehensible. People are deploying firewalls for legitimate reasons. And there are some circumstances in which your traffic not getting out is exactly what should happen. There are also circumstances where censorship bypass is important and legitimate. If you want to run DNS over TCP then I suggest that you simply build a mechanism to advise on the port to use into whatever upgrade mechanism you attempt. Then you can use 443, 8443, whatever works. But the result is rather Rube-Goldberg. My version of digg exploded from a few hundred kb to 2Mb because it now has the whole of OpenSSL embedded. (Although the same might well happen if I implemented DNSSEC) I don't like that approach. TLS is optimized for a particular purpose and DNS is a very different problem. We end up using only a fraction of the features. And as heartbleed shows, an unused feature can still cause failure. In fact its always been the underused parts of TLS where problems have emerged - client auth, renegotiation, heartbeat. I would prefer to separate out the key negotiation from the DNS protocol. The complex part is the key negotiation. Applying crypo to messages is pretty easy (albeit not foolproof as heartbeat shows). One of the features you will note in both CBOR and JSON-B is that we both use byte length markers to specify the length of binary and text fields but we don't use them to denote lists or structures. There is a good reason for that, using byte counts to measure structures is inherently ambiguous if the inner lengths are larger than the outer. Just finishing up a draft. Got to get over this cold first. --=20 Website: http://hallambaker.com/ From nobody Thu Apr 24 08:19:31 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5D21A036B for ; Thu, 24 Apr 2014 08:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 VagP8Jw3iAyJ for ; Thu, 24 Apr 2014 08:19:25 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7F1A03D5 for ; Thu, 24 Apr 2014 08:19:19 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo20so2837981obc.3 for ; Thu, 24 Apr 2014 08:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CXTaSeL4W7mqBzII+Gyj9pPHSQG+AYak+VUu7Hw/iHI=; b=IU6thF44rZp8/B0efQrYzi9sNnPMqGO/OxZN/R28ayhK6ypyjIoom7swFY0CShEonb x9pgzPgHSzi6C0zl19XVDQ4q0sLlSGNw3ZvoFY+KDHViNGhtVaLflqUG6IwoXiDDwb4n K2jefoEQve3Daz7P0fQGzRb8H5dk4KPSvj00A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CXTaSeL4W7mqBzII+Gyj9pPHSQG+AYak+VUu7Hw/iHI=; b=jwNQEW660DvOTLRxyPgBI1M23T5yTKha7Msfs6xnxKkxNji777z01HWYVoiotH7qLK 15MlFwL3/W6H8ud6s035zGyexh9gyBt+gxvoMxWM7XnpKIaiIwQ6RAAsPpdP4Gzd1zjZ oKE7uqg0IsxNa1PQU4UD0Nn5YK2xWEQaDqsvg16RZNTvO5X4K4ISU0Y5xaEpDlr+AnM9 yhS+DC9VWH9TPCIDLl0cbJ5tRRNSgVGl4tBldadMbhcgwC1z01bAGWdsRX8hLmJaq0Ni x6wawVOPZvDU6rR3QVqrPqJ1xsGmMdInbej6z2T+y9OgCAumrfumMd0fVbrkv9EXSJ2y v6IQ== X-Gm-Message-State: ALoCoQnKaGkjUvEpMMD72XCQhLWBb7O8AYwxzC10kSVwcxXkSD/t/N65Q58mj1iccoJzU5W3uy/N X-Received: by 10.60.78.165 with SMTP id c5mr1100987oex.83.1398352753211; Thu, 24 Apr 2014 08:19:13 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:bdd8:47d2:8343:de72? ([2001:4900:1042:1:bdd8:47d2:8343:de72]) by mx.google.com with ESMTPSA id pa3sm9081944obb.6.2014.04.24.08.19.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 08:19:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Abley In-Reply-To: Date: Thu, 24 Apr 2014 11:19:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A9A094B-6905-40C3-A6A5-621B302F9BAF@hopcount.ca> References: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/QXHW3LvWMf-gzwLUG_HkgxGsCHA Cc: Nicholas Weaver , dnsop , "Tirumaleswar Reddy \(tireddy\)" , Ralf Weber , "dns-privacy@ietf.org" , Paul Wouters Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:19:28 -0000 On 24 Apr 2014, at 10:53, Phillip Hallam-Baker wrote: > If you want to use TLS with DNS then use port 443. One of the effects > of firewalls is that we now only have three ports for all protocols: >=20 > Port 80/UDP: Non SSL traffic > Port 443/TCP: SSL traffic > Port 53/UDP: DNS I think it's important to frame the problem space. I suspect that the = firewall challenges you cite most often apply to communications between = stub resolvers and recursive resolvers, for hosts that are using an = off-net resolver (directly, or via a proxy). I also suspect that any ISP who has ever decided to install firewalls or = other packet-mangling middleware in front of their resolver service (and = is still in business) has by now collected many reasons not to do that, = and that the network path between ISP resolver and authority servers is = very likely to be clean. For ISP, read campus, enterprise, etc as = appropriate. I have no science to back up my suspicions, here. Given that others = apparently have different suspicions, equally plausible, perhaps science = is needed. However, I'll note that the conversations surrounding the = problem statement in London all seemed to support separating these two = uses of the protocol. I don't think it's worth butchering the protocol if it turns out that we = have an easy and clean solution that works for a significant part of the = problem space (resolvers talking to authority servers), which is what = t-dns/draft-hzhwm-start-tls-for-dns looks like to me. This compartmentalisation of the problem space reminds me of RFC 4409, = and makes me wonder whether there's a way to replace stub-resolver = communications with something new without breaking everything. After = all, in a very real sense we really only have two edge platforms to = worry about (Android and iOS). Joe= From nobody Thu Apr 24 08:32:29 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103A01A03AB; Thu, 24 Apr 2014 08:32:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 kD06MF5rULWF; Thu, 24 Apr 2014 08:32:19 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 596F41A02D7; Thu, 24 Apr 2014 08:32:19 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id n15so2136291lbi.14 for ; Thu, 24 Apr 2014 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dPex+CuXBWzuSibnnuuHPjrNttuVjQ1Nc+SC9xL9CX4=; b=Srg4vXmNwLtJ0ycIqVlavyA0uC1AdozHHFW/rkIavl58Uisi209mnb/Z8BcX5CbQ+T 3i0ADd5Ys3DQQhItVlYE6JhlonovZg8mLzJTLltFD3dEn+TvKLl9TMBSPBdi0Twar6RR MeCwCUiQEvwIijSrggjsFHDfBO1mqlqAX4k1vJiRaIXL5ytt5zeUnmiZ8kEgCs9gFLHe qEFohChE1098++Z0/LXEzXuGBU9MplzlwS2Nwc85FCTPvwTRP6qHw5MaDK0URAty11Ft 5JjGfqZIz4ZMkAneHBYX4I7swm0gx+Pp/U24OtCeAyykdJLVgZFomB15vxQNbJ6yxMtu F2GA== MIME-Version: 1.0 X-Received: by 10.112.142.68 with SMTP id ru4mr1555444lbb.49.1398353532703; Thu, 24 Apr 2014 08:32:12 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 24 Apr 2014 08:32:12 -0700 (PDT) In-Reply-To: <6A9A094B-6905-40C3-A6A5-621B302F9BAF@hopcount.ca> References: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> <6A9A094B-6905-40C3-A6A5-621B302F9BAF@hopcount.ca> Date: Thu, 24 Apr 2014 11:32:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/5oslKipbXzJEHWKW9FKD1m_tpFY Cc: Nicholas Weaver , dnsop , "Tirumaleswar Reddy \(tireddy\)" , Ralf Weber , "dns-privacy@ietf.org" , Paul Wouters Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:32:22 -0000 On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley wrote: > > On 24 Apr 2014, at 10:53, Phillip Hallam-Baker wrote: > >> If you want to use TLS with DNS then use port 443. One of the effects >> of firewalls is that we now only have three ports for all protocols: >> >> Port 80/UDP: Non SSL traffic >> Port 443/TCP: SSL traffic >> Port 53/UDP: DNS > > I think it's important to frame the problem space. I suspect that the fir= ewall challenges you cite most often apply to communications between stub r= esolvers and recursive resolvers, for hosts that are using an off-net resol= ver (directly, or via a proxy). > > I also suspect that any ISP who has ever decided to install firewalls or = other packet-mangling middleware in front of their resolver service (and is= still in business) has by now collected many reasons not to do that, and t= hat the network path between ISP resolver and authority servers is very lik= ely to be clean. For ISP, read campus, enterprise, etc as appropriate. My interest at the start was censorship prevention so my interest is almost exclusively client-resolver. It does look like a totally different protocol to resolver-authoritative though. Since what we are concerned with here is (also) privacy, I agree that the resolver-authoritative loop is also in play. But that is a vastly lower priority than the client-resolver loop. If you don't solve that, you don't have any solution. The two problems are completely separate from a trust point of view. For key management in the Resolver-Authoritative loop you almost certainly want to use DNSSEC. But in the client-resolver loop you might well want to use WebPKI because you would want accountability. > I have no science to back up my suspicions, here. Given that others appar= ently have different suspicions, equally plausible, perhaps science is need= ed. However, I'll note that the conversations surrounding the problem state= ment in London all seemed to support separating these two uses of the proto= col. > > I don't think it's worth butchering the protocol if it turns out that we = have an easy and clean solution that works for a significant part of the pr= oblem space (resolvers talking to authority servers), which is what t-dns/d= raft-hzhwm-start-tls-for-dns looks like to me. You know when people use loaded terms like 'butchering the protocol' to mean 'do it a different way to me' I start to get a little cross. For me the idea of putting TLS traffic over the same port as non TLS traffic without careful attention to how the upgrade is achieved would be 'butchering the protocol'. Changing the port number to one that is known to work is a cleaner approach. --=20 Website: http://hallambaker.com/ From nobody Thu Apr 24 08:39:48 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98E1A028B; Thu, 24 Apr 2014 08:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YPl_k-39N-1r; Thu, 24 Apr 2014 08:39:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1C51A02C8; Thu, 24 Apr 2014 08:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1398353973; x=1399563573; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=UAwOnEUdo/JslQA1BtdYahnUpxO1WQnlXgCO9Eu9Sbs=; b=Q/NoZrI4ftBV7BuZPSPAhmW2NvbFr0+pfJu5UDMviyeNyQM4qdP7wH3W owU04wsAYTMYy7OgBGyp0drzWZdZeWeVwID6v77tuWHdkBz+VwYBfT8Nb YSaVYWxYlqNzBfcQZhuW9uOBmdmUP3V7WKtT+ACADVtlQPOiD/sDJP2h7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADcvWVOtJA2G/2dsb2JhbABZgwZPV7x8hzqBGxZ0giUBAQEDAQEBATc0CwwGAQgRBAEBAQoUCS4LFAkJAQQBDQUIiDEIDctIF44nMQ2DHoEVBJotkR6DMYIr X-IronPort-AV: E=Sophos;i="4.97,919,1389744000"; d="scan'208";a="320094248" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 24 Apr 2014 15:39:33 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3OFdXJW027816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 15:39:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 10:39:32 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Paul Hoffman , Stephane Bortzmeyer Thread-Topic: [dns-privacy] DNS over DTLS (DNSoD) Thread-Index: Ac9f02BXoNakowd0T/+l0PCf2VUpYw== Date: Thu, 24 Apr 2014 15:39:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431A616@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/o1ZAhu4gqrrUD3CoEYI8Y7e_uhE Cc: "dns-privacy@ietf.org" , dnsop , "Dan Wing \(dwing\)" Subject: Re: [dns-privacy] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:39:41 -0000 > -----Original Message----- > From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Paul > Hoffman > Sent: Thursday, April 24, 2014 7:49 PM > To: Stephane Bortzmeyer > Cc: dns-privacy@ietf.org; dnsop; Dan Wing (dwing) > Subject: Re: [dns-privacy] DNS over DTLS (DNSoD) >=20 > On Apr 23, 2014, at 11:11 PM, Stephane Bortzmeyer > wrote: >=20 > > On Wed, Apr 23, 2014 at 09:16:29AM -0700, Paul Hoffman > > wrote a message of 39 lines which said: > > > >> Sure. What were the results of your testing? > > > > I quickly tested with .FR authoritative name servers and both NSD and > > BIND seem to silently ignore the incoming request. No response is seen > > coming back. > > > > 08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/0 (164) > > 08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/256 ar: > > > > ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM- > "n4^gs^OM-ylMM-S0M-9M > > -=3DM-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M- > @!^@9^@8^@M-^H^@M-^GM-@^O > > M-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM- > @^C^@^JM-@^SM-@^IM-@^ > > _M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M- > ^V^@A^@^U^@^R^@^I^@^T^@ > > ^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] > > 08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/512 ar: > > > > ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM- > "n4^gs^OM-ylMM-S0M-9M > > -=3DM-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M- > @!^@9^@8^@M-^H^@M-^GM-@^O > > M-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM- > @^C^@^JM-@^SM-@^IM-@^ > > _M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M- > ^V^@A^@^U^@^R^@^I^@^T^@ > > ^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain] >=20 > Thanks, this is the kind of data I was looking for. The draft seems to as= sume that > the server will give an error, not no response. No, the draft states that the DNS server will send no response. Please refe= r to section 5 of the draft http://tools.ietf.org/html/draft-wing-dnsop-dns= odtls-00#section-5=20 After performing the above steps, the host should determine if the DNS server supports DNSoD by sending a DTLS ClientHello message. A DNS server that does not support DNSoD will not respond to ClientHello messages sent by the client, because they are not valid DNS requests (specifically, the DNS Opcode is invalid). -Tiru >=20 > --Paul Hoffman > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Thu Apr 24 08:52:39 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF11A035B; Thu, 24 Apr 2014 08:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 iXZmYnZGla8n; Thu, 24 Apr 2014 08:52:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C971C1A032E; Thu, 24 Apr 2014 08:52:32 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3OFqONK048605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2014 08:52:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <913383AAA69FF945B8F946018B75898A2431A616@xmb-rcd-x10.cisco.com> Date: Thu, 24 Apr 2014 08:52:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D44260A-D0D9-41B6-98EC-A5826D12D6AD@vpnc.org> References: <913383AAA69FF945B8F946018B75898A2431A616@xmb-rcd-x10.cisco.com> To: "dns-privacy@ietf.org" , dnsop X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/sXp6tmHT2p-PnH-P7JeG6bsTauY Subject: Re: [dns-privacy] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:52:34 -0000 On Apr 24, 2014, at 8:39 AM, Tirumaleswar Reddy (tireddy) = wrote: > No, the draft states that the DNS server will send no response. Please = refer to section 5 of the draft = http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-00#section-5=20 >=20 > >=20 > After performing the above steps, the host should determine if the > DNS server supports DNSoD by sending a DTLS ClientHello message. A > DNS server that does not support DNSoD will not respond to > ClientHello messages sent by the client, because they are not valid > DNS requests (specifically, the DNS Opcode is invalid). >=20 > Sorry, you are right, and I had misread that. --Paul Hoffman= From nobody Thu Apr 24 15:59:35 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9DF1A0412; Thu, 24 Apr 2014 15:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 MzuDO9MRtL6e; Thu, 24 Apr 2014 15:59:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 976DE1A0420; Thu, 24 Apr 2014 15:59:27 -0700 (PDT) Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3OMwiTm009596; Thu, 24 Apr 2014 15:58:44 -0700 (PDT) Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (Postfix) with ESMTP id C9FF96005D; Thu, 24 Apr 2014 15:58:43 -0700 (PDT) From: John Heidemann To: Phillip Hallam-Baker In-reply-to: References: <913383AAA69FF945B8F946018B75898A2431A49C@xmb-rcd-x10.cisco.com> <5305A974-288E-4C5B-A5D0-6A21C70EC416@fl1ger.de> <6A9A094B-6905-40C3-A6A5-621B302F9BAF@hopcount.ca> X-url: http://www.isi.edu/~johnh/ MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Date: Thu, 24 Apr 2014 15:58:43 -0700 Message-ID: <1732.1398380323@dash.isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: johnh@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/y7Hih3MTP3dy5zkBbsoumVuRv0Y Cc: dnsop , dns-privacy@ietf.org Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:59:32 -0000 On Thu, 24 Apr 2014 11:32:12 -0400, Phillip Hallam-Baker wrote: >... > >For me the idea of putting TLS traffic over the same port as non TLS >traffic without careful attention to how the upgrade is achieved would >be 'butchering the protocol'. Changing the port number to one that is >known to work is a cleaner approach. > >... Agreed that TLS upgrade must be done carefully. Fortunately we have a number of protocools that have survived a TLS retrofit: IMAP, STMP, POP3, FTP, XMPP, LDAP, NNTP (according to http://en.wikipedia.org/wiki/STARTTLS). Several of these protocols are used over WANs, although I would guess DNS has far more frequent "help" from transparent middleboxes than they do, so YMMV. I think SMTP is a pretty compelling argument that the World May Not End to do STARTTLS, though. It is true that a new port "solves" the "oh noes, something changed and I, the firewall/middlebox, hate you" problem. However, it solves that by by turning it into the "oh noes, why should I, the firewall, ever open this new port for you". (As as been pointed out.) It seems like a trade-off about which pain one wants to endure. -John From nobody Thu Apr 24 21:44:59 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23D71A02FF; Thu, 24 Apr 2014 21:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 ksgHTETWI6DB; Thu, 24 Apr 2014 21:44:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AF0651A02ED; Thu, 24 Apr 2014 21:44:53 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 7DA9A349414; Fri, 25 Apr 2014 04:44:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4B1A6160059; Fri, 25 Apr 2014 04:47:32 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1351F160042; Fri, 25 Apr 2014 04:47:32 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 89469147F330; Fri, 25 Apr 2014 14:44:41 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <11620EF1-D80F-4B2E-87CB-DE65EB35D672@danwing.org> <491D9439-C6A9-4B38-8754-A9CBCA642C40@vpnc.org> <63843A6C-33AF-4A65-87FA-281FF9E996CC@vpnc.org> <20140424061128.GA27677@nic.fr> <995CF19C-6E1E-4282-BEA1-9991214E6653@vpnc.org> In-reply-to: Your message of "Thu, 24 Apr 2014 07:19:14 -0700." <995CF19C-6E1E-4282-BEA1-9991214E6653@vpnc.org> Date: Fri, 25 Apr 2014 14:44:41 +1000 Message-Id: <20140425044441.89469147F330@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/80PuE0_Z3MROqE1RnWC7J-h_DI0 Cc: dns-privacy@ietf.org, Stephane Bortzmeyer , dnsop , Dan Wing Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 04:44:55 -0000 If you want a response "QR" needs to be zero. Note the "*" which indicates the packet is a response (QR=1). In message <995CF19C-6E1E-4282-BEA1-9991214E6653@vpnc.org>, Paul Hoffman writes: > On Apr 23, 2014, at 11:11 PM, Stephane Bortzmeyer wrote: > > > On Wed, Apr 23, 2014 at 09:16:29AM -0700, > > Paul Hoffman wrote > > a message of 39 lines which said: > > > >> Sure. What were the results of your testing? > > > > I quickly tested with .FR authoritative name servers and both NSD and > > BIND seem to silently ignore the incoming request. No response is seen > > coming back. > > > > 08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/0 (164) > > 08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/256 ar: > > ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^ > TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_ > M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A > ^A.[|domain] > > 08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF], > > proto UDP (17), length 192) > > 192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-| > > [0q] 0/0/512 ar: > > ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^ > TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_ > M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A > ^A.[|domain] > > Thanks, this is the kind of data I was looking for. The draft seems to assume that the server will give an e > rror, not no response. > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Apr 25 07:22:26 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF61A0232; Fri, 25 Apr 2014 07:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QL-3t-MunKGQ; Fri, 25 Apr 2014 07:22:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 811261A04CD; Fri, 25 Apr 2014 07:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2988; q=dns/txt; s=iport; t=1398435725; x=1399645325; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=EFBaCH/DFLkmU8/8wnkcRY6tU/4bNmWUDCVlKtguGiM=; b=JPGPTIdwco2CbqdUUqEmHY43XxPnXJ1cVwuWvXt7HJEcRpXMW1eIxYyE XXzTRPMzPgan0G7ajaIoGCdZwtN4KzQwa/W8vRN4IWuNj1hnKR54naOr9 RVkMJFQZiN3uu3WdpZntk2HUp9Bmh0jQQw11zQy+0R0EWO/Ttkglkh5cr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOFuWlOtJA2E/2dsb2JhbABZgwaBJsQfgQ8WdIIlAQEBAwE6PwUHBgEIDgMEAQEBChQJORQJCQEECgQFCIgxCMpkF44oMQ2DHoEVBKthgzGCKw X-IronPort-AV: E=Sophos;i="4.97,927,1389744000"; d="scan'208";a="320339381" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 25 Apr 2014 14:22:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEM4Jl007021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 14:22:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:22:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ralf Weber Thread-Topic: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) Thread-Index: Ac9gkbkWWJ3ncNt8R8iiAdUNUgPxDw== Date: Fri, 25 Apr 2014 14:22:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/PNsYg65mqBAMgk4zdEPKys8AYI4 Cc: dnsop , Paul Wouters , Nicholas Weaver , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:22:17 -0000 > -----Original Message----- > From: Ralf Weber [mailto:dns@fl1ger.de] > Sent: Thursday, April 24, 2014 7:22 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Nicholas Weaver; Paul Wouters; dnsop; dns-privacy@ietf.org > Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) >=20 > Moin! >=20 >=20 > On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" > wrote: >=20 > >> -----Original Message----- > >> From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of > >> Nicholas Weaver > >> Sent: Thursday, April 24, 2014 1:58 AM > >> To: Paul Wouters > >> Cc: dnsop; Nicholas Weaver; dns-privacy@ietf.org > >> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) > >> > >> > >>> On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: > >>> No, I fully disagree with this. Port 53 TCP has a much better chance > >>> at working these days than a random other newly assigned port. > > > > On the contrary, Firewalls are configured today to permit UDP port 53 a= nd > block TCP port 53. Why should firewalls change their configuration ? > I know lots of firewalls that also allow TCP/53,=20 Any specific reason for the firewalls to permit TCP/53 other than for zone = transfer ? > but the real problem with all > these middle boxes that make changing DNS hard is that they believe to > understand the full protocol and only pass what they think is right. So e= verything > new we come up will be dropped (Been there, done that). We have to be ver= y > careful with changes to the DNS protocol if we want them to be deployed Agreed, It totally depends on the environment in which the firewall is depl= oyed, it's capability and configuration.=20 For example [1] For firewalls deployed in Enterprise network and the I.T realizing the= importance of privacy then FW could be configured to permit DNSoD over 53.= Similarly I don't see any problem with the firewall deployed in the Home n= etwork. [2] It could be a problem with firewalls deployed in airports, coffee shops= , where I.T may not care about privacy, and the firewall configured could= block non-DNS traffic on port 53. In such environments if a user wants pri= vacy then it's probably better to go with DNS servers that the user trusts.= For example DNSCrypt uses UDP/443 by default and if the connectivity with = the DNS servers fails then it resorts to TCP/443 and it works on UDP/53 too= . I guess With {D}TLS we will need a similar approach where client tries co= nnectivity using multiple ports, L4 protocols etc. Firewalls today are already capable of inspecting the TLS handshake and can= also act as {D}TLS proxy. DTLS is already deployed and used today to secu= re WebRTC media, data channels and CoAP protocol in IOT environments. Firew= alls are catching up with these emerging protocols to make sure it works wi= th them. Cheers, -Tiru >=20 > So long > Ralf >=20 > Sent from my iPhone From nobody Fri Apr 25 07:24:40 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45CB1A0232; Fri, 25 Apr 2014 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 NQaGY7tH0K4B; Fri, 25 Apr 2014 07:24:35 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) by ietfa.amsl.com (Postfix) with ESMTP id C8C7E1A022E; Fri, 25 Apr 2014 07:24:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54442) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Wdh3C-0000b1-RU (Exim 4.82_3-c0e5623) (return-path ); Fri, 25 Apr 2014 15:24:26 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Wdh3C-0006iy-EV (Exim 4.72) (return-path ); Fri, 25 Apr 2014 15:24:26 +0100 Date: Fri, 25 Apr 2014 15:24:26 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Tirumaleswar Reddy (tireddy)" In-Reply-To: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> Message-ID: References: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/MQpkzqoH7EWCkgbu40oV5fiCl_A Cc: dnsop , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:24:37 -0000 Tirumaleswar Reddy (tireddy) wrote: > > Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? RFC 5966 Tony. -- f.anthony.n.finch http://dotat.at/ South Utsire, Northeast Forties: Easterly 4 or 5, increasing 6 or 7. Slight or moderate. Fair. Good. From nobody Fri Apr 25 07:47:11 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480C81A0300; Fri, 25 Apr 2014 07:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 tV9AMCe9jpzC; Fri, 25 Apr 2014 07:47:05 -0700 (PDT) Received: from nox.guxx.net (nox.guxx.net [78.46.109.173]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF81A022E; Fri, 25 Apr 2014 07:47:04 -0700 (PDT) Received: by nox.guxx.net (Postfix, from userid 65534) id B7BF2DB830C; Fri, 25 Apr 2014 16:46:57 +0200 (CEST) Received: from porcupinetree.hohensolms.de (p5B3F9658.dip0.t-ipconnect.de [91.63.150.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nox.guxx.net (Postfix) with ESMTPSA id 7B470DB8130; Fri, 25 Apr 2014 16:46:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ralf Weber In-Reply-To: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> Date: Fri, 25 Apr 2014 16:46:58 +0200 X-Mao-Original-Outgoing-Id: 420130018.81523-b7ceb53e1475c3339e747800edabea1b Content-Transfer-Encoding: quoted-printable Message-Id: <56C5189A-C0EC-4AA1-B8AB-E8A6DEEB99AD@fl1ger.de> References: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/Ia998PFpzyckwI-yOgvwzvFEOvM Cc: dnsop , Paul Wouters , Nicholas Weaver , "dns-privacy@ietf.org" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:47:08 -0000 Moin! On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy) = wrote: > Any specific reason for the firewalls to permit TCP/53 other than for = zone transfer ? Wat? Because it is defined in the RFC. RFC1035 may not been totally = clear on that. IMHO=20 the language is strong enough, but if not there is RFC5966: "All general-purpose DNS implementations MUST support both UDP = and TCP transport." Any more questions?! Also all this new DNS stuff like DNSSEC and = mitigating DNS=20 amplification attack with RRL or similar techniques require that the TCP = transport works. So long -Ralf From nobody Fri Apr 25 08:15:09 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FCF1A0527; Fri, 25 Apr 2014 08:15:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 gT6dmEMvxPD8; Fri, 25 Apr 2014 08:15:02 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 774451A04FA; Fri, 25 Apr 2014 08:15:01 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so3105507lbi.8 for ; Fri, 25 Apr 2014 08:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w1fvO3wScI3BuXRw6ve3COcnmI/eidTIXa1EV5TFcWo=; b=aRz/k5bvETUuCNyCik1oBMz7Pe8sDKmbzmBJl3veeKQNBAypv/9oOrnanBi4N6mV0G gE4WuUEony1i+4Vn9q82MM/5qJbGdlMcy0jrOxLiItd93Ceo34ZiNV4ruAK/CPQBPDVQ romwqCASoV3r4uUDahCFF7V1AmG4nSFUMhzlGbLxOuxTQ8s92Uly+OpPwjzRfUfCrZHn naEBNqCrTzbCfbopJfyubMUdv3lbbvYF+FK1zMElaJzaRgltDqaJk/8Tu83aVEADB0ew hg2fp2UmDHIMFDNCWvHOyeNNnnPNh1K4jV8JKyh+q4LsXEP8a95HDVhdz2SkIOqaRKVB 8HDg== MIME-Version: 1.0 X-Received: by 10.112.22.130 with SMTP id d2mr5628766lbf.33.1398438894120; Fri, 25 Apr 2014 08:14:54 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 25 Apr 2014 08:14:54 -0700 (PDT) In-Reply-To: <56C5189A-C0EC-4AA1-B8AB-E8A6DEEB99AD@fl1ger.de> References: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> <56C5189A-C0EC-4AA1-B8AB-E8A6DEEB99AD@fl1ger.de> Date: Fri, 25 Apr 2014 11:14:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Ralf Weber Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/EUWAT8b5zPCH7LZA4JkYMgZWCDE Cc: dnsop , Paul Wouters , Nicholas Weaver , "dns-privacy@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:15:04 -0000 On Fri, Apr 25, 2014 at 10:46 AM, Ralf Weber wrote: > Moin! > > On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy) wrote: >> Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? > Wat? Because it is defined in the RFC. RFC1035 may not been totally clear on that. IMHO > the language is strong enough, but if not there is RFC5966: > "All general-purpose DNS implementations MUST support both UDP and TCP transport." > Any more questions?! Also all this new DNS stuff like DNSSEC and mitigating DNS > amplification attack with RRL or similar techniques require that the TCP transport works. > > So long Yes and RFC 8888 quite definitely says that I get a pony. The existing DNS works as far as the people running their firewalls are concerned. The failure of TCP fallback in practice has been an understood problem for 20+ years. If people want to design a protocol that is going to be usable, they are going to end up having to accept some constraints that are not in the specs. -- Website: http://hallambaker.com/ From nobody Fri Apr 25 11:57:06 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F45A1A0665 for ; Fri, 25 Apr 2014 11:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 Tl2JNAPqsy5M for ; Fri, 25 Apr 2014 11:56:56 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 310F31A0659 for ; Fri, 25 Apr 2014 11:56:56 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id hn18so2549079igb.11 for ; Fri, 25 Apr 2014 11:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q26YQ+UVoBJBu4PUDBakiQsz1m4rIbe3cusexlQ57yA=; b=SSC0hzl+XT7WMZg118Xq8viYavrsO9+edXN4iQ2vSeTcEbiKahr0rAqC1toRaQF8eP QFb6orV5B+7B2sIZib3wP+XVJc0W0/tUeb/TOdIjnkSNXyxH1+v8/DAhFUutZMI/+vAS SyLOJpP3wbRML7OLNuFxn+I4IRWi0o8ESrlgk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Q26YQ+UVoBJBu4PUDBakiQsz1m4rIbe3cusexlQ57yA=; b=e3Bjm0YveoxG2BpdWNMneZxJoXlBQ0cRPsgXOjWGK8ooRWp2QKdBmfjmdGPiAs1qlg 0TRtIjlIBMcAeaoYshv7zcZsTDPBnwkX6El2qgD/A1XVKy9OH1LFmo/W47LD4L0icP3c 6CV6QdoF4hbIAVq+393xAgqgWzoydErF5NjaVawVHD4l8B6wIxYuVpizm/gbPbtwJBtv o7en5ZGAZanVDgBjyt+7j+1Fn2ZeksJI9whkq2gc6w2SkYXI3g8crU+/wzFBKawMGIS/ DtlOPOnTJI2Y2m0rMIc+uNHnB2RRpiP/h4s1kHso7sFAOTXzHUt8676tLdeV61LURPcj LnEw== X-Gm-Message-State: ALoCoQmWG/S36NLC8aESvp3mU2YWwnc9nZpCzrTiiTFtacPT0ouInBvSoZPP856RzN9OCxjd6R8i X-Received: by 10.50.27.2 with SMTP id p2mr7091357igg.32.1398452209629; Fri, 25 Apr 2014 11:56:49 -0700 (PDT) Received: from dh27.r1.hopcount.ca (24-52-234-221.cable.teksavvy.com. [24.52.234.221]) by mx.google.com with ESMTPSA id g1sm10791585igt.14.2014.04.25.11.56.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 11:56:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Abley In-Reply-To: Date: Fri, 25 Apr 2014 14:56:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18337BA0-D8F6-49C5-9C02-8D29FC616428@hopcount.ca> References: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> <56C5189A-C0EC-4AA1-B8AB-E8A6DEEB99AD@fl1ger.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/Kfvt9h2eggQ33AGZsVPzglYcyJg Cc: Nicholas Weaver , dnsop , "Tirumaleswar Reddy \(tireddy\)" , Ralf Weber , "dns-privacy@ietf.org" , Paul Wouters Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:56:59 -0000 On 25 Apr 2014, at 11:14, Phillip Hallam-Baker wrote: > The existing DNS works as far as the people running their firewalls > are concerned. The failure of TCP fallback in practice has been an > understood problem for 20+ years. Understood, perhaps; measured and understood, not so much. What is sorely missing from most/all protocol evolution discussions is a = rigorous study of the actual impact of larger response sizes, = fragmentation, interception/middebox-mangling, TCP fallback and TCP = pipelining in the real world in at least two problem domains, = recursive-authority and stub-recursive. > If people want to design a protocol that is going to be usable, they > are going to end up having to accept some constraints that are not in > the specs. And it would be great if we could describe those constraints with = confidence. There was concern that signing ORG might cause resolution problems due = to larger responses, or might cause TCP fallback on a scale not seen = before. The former were not apparent. The latter happened (due to a = defect in the signer used for ORG) but did not cause any obvious = problems. There was widespread expectation that DNSSEC in the root zone would = impact resolvers' ability to prime, hence the DURZ, global netops = meeting roadshow, LTQC, etc. No issues were identified. We will get much further, much more quickly if we know more about what = problems are likely and which ones are unlikely. Being afraid of every = possible negative outcome is just a recipe for doing nothing. No useful = risk analysis is possible without data. Joe= From nobody Sun Apr 27 07:34:27 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D861A063C for ; Sun, 27 Apr 2014 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 Q45GMwvguiB9 for ; Sun, 27 Apr 2014 07:34:24 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 87A3A1A0663 for ; Sun, 27 Apr 2014 07:34:24 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7E6EC3B851; Sun, 27 Apr 2014 16:34:21 +0200 (CEST) Received: by tyrion (Postfix, from userid 1000) id ECFA1F013DD; Sun, 27 Apr 2014 16:31:54 +0200 (CEST) Date: Sun, 27 Apr 2014 16:31:54 +0200 From: Stephane Bortzmeyer To: dns-privacy@ietf.org Message-ID: <20140427143154.GA2220@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 13.10 (saucy) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/mdXfzYH2jGd301rqnCtkCRhrKBI Subject: [dns-privacy] New version of the privacy considerations document X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 14:34:26 -0000 I just posted a new version of draft-bortzmeyer-dnsop-dns-privacy, the revision -02, whose title was changed to "DNS privacy considerations" because some people seemed to dislike the word "problem". Comments, critics, patches, etc, requested. It is my opinion that during the London meeting, there were many general remarks ("we need to study the problem") but very few detailed remarks on the "core effort", a description of the issue. So, detailed remarks are welcome. From nobody Mon Apr 28 17:03:29 2014 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443FE1A8837; Mon, 28 Apr 2014 14:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 qOhLROVfpNvw; Mon, 28 Apr 2014 14:55:57 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 833D41A6FB7; Mon, 28 Apr 2014 14:55:56 -0700 (PDT) Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0B8BC8A031; Mon, 28 Apr 2014 21:55:45 +0000 (UTC) Date: Mon, 28 Apr 2014 17:55:41 -0400 From: Andrew Sullivan To: dnsop@ietf.org, dns-privacy@ietf.org Message-ID: <20140428215540.GA948@mx1.yitter.info> References: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <913383AAA69FF945B8F946018B75898A2431B066@xmb-rcd-x10.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/hgkc-4kPch-w1tAdkDK9P0PkksI X-Mailman-Approved-At: Mon, 28 Apr 2014 17:03:25 -0700 Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:55:58 -0000 On Fri, Apr 25, 2014 at 02:22:03PM +0000, Tirumaleswar Reddy (tireddy) wrote: > > Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? "Because DNS uses TCP in lots of cases, and always has"? Anyone who is still configuring firewalls to deny TCP/53 as a matter of course ought to have his or her Internet license revoked. A -- Andrew Sullivan ajs@anvilwalrusden.com