From nobody Thu Jan 5 19:24:33 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC51296EC for ; Thu, 5 Jan 2017 19:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6LD_Mqe_CwP for ; Thu, 5 Jan 2017 19:24:30 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290B31294C7 for ; Thu, 5 Jan 2017 19:24:30 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id x49so3061950qtc.2 for ; Thu, 05 Jan 2017 19:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=XTavAevnSRy3UpFkzdEGLfONGR5lBhHNttNCkXG7AVA=; b=c9lwyn89X5/JhEVEOr6C+2aCsiF4jxS1EwyHssJH88bJBPcIrweYo/TlxzU6Xsxy5Q t2sWVVWhgDX4rsdnympDQ7bgO4eGgb0x8vyIqnT3OUO0ZoNmwmYawd9vj7t8JI38Odgd jpu4YJP1KuvZ/xv8Sl8thzPc8bF5Mt5umWNcG3wTcdnZYKvO7VZcSGDacnZeP8rfpwg5 RpR+hg1+jc5Lfo6tdnRtFcLSoHKK2E70PUY0qX2vagU4pj34RjOJuKjw33TIdI/kMBen pKmlSJVU2atnkeS9vZ7gpAAHJnrPuwuAzGBSLwFvP3kVHEfz114yUKhVwis46cPBqgHV VCQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XTavAevnSRy3UpFkzdEGLfONGR5lBhHNttNCkXG7AVA=; b=AVjMA4G6F4xqhevmJw89S2LRrrS2qVHSBWiUMt1zpxFzs2tcKH9Sbyo5XRDcAlqaKs Mw81n3MSOOz9gDnRcMtjP/NLvhxtpiGmi3DRShuCLpYNkXAEdAWs2wDVY2d+KXQyxHX/ oMsv8ADLKIX6V1BruovFeupztHBAef5ujsVhDOV8jUhePpBUR+CK1PM3C7KDNJTRAoIn TCkcJirnFl3ge9ayYtBz3LBfDf4EF/yv7C9TjEnF1CUc5us87a0k4JeexhOe4EMKVgW1 O839r0fo+6CrXJbSys9zq4MvE18US5V5cs35uLgPpQKeHr21Im7WERNczeDQkeIsrhoB yaPw== X-Gm-Message-State: AIkVDXIKDpYS3NQY3dJqYhsDgrZ8udeijsgo5gUkokGp5mlxDtBiZzQtNk1iWaTu1ggxAtONtZyOb3nb24tzPJPt X-Received: by 10.200.44.123 with SMTP id e56mr68647125qta.122.1483673068956; Thu, 05 Jan 2017 19:24:28 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Fri, 06 Jan 2017 03:24:18 +0000 Message-ID: To: "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary=001a113bc8803d0e510545648eae Archived-At: Subject: [dns-privacy] A DPRIVE container. X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 03:24:32 -0000 --001a113bc8803d0e510545648eae Content-Type: text/plain; charset=UTF-8 Hi all, I have created a Docker container for easily deploying a DPRIVE RFC7858 (DNS over TLS) server. This is implemented by putting a TLS proxy (NGINX) in front of a recursive nameserver (BIND). It can be found here: https://github.com/wkumari/dprive-nginx-bind This repo contains the Dockerfile, some rudimentary documentation and supporting files, including NGINX and BIND configs, and some Google Container Engine configs for starting and running the container / service. Most of the credit goes to Sara / Sinodun for documenting how to run BIND behind NGINX as a TLS proxy. I just wrapped this up in a container. Please let me know what you think, open issues, send pull requests, etc. Thanks. W --001a113bc8803d0e510545648eae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I have created a Docker contain= er for easily deploying a DPRIVE RFC7858 (DNS over TLS) server. This is imp= lemented by putting a TLS proxy (NGINX) in front of a recursive nameserver = (BIND).


This repo contains the Dockerfile, some= rudimentary documentation and supporting files, including NGINX and BIND c= onfigs, and some Google Container Engine configs for starting and running t= he container / service.

Most of the credit goes to= Sara / Sinodun for documenting how to run BIND behind NGINX as a TLS proxy= . I just wrapped this up in a container.

Please le= t me know what you think, open issues, send pull requests, etc.=C2=A0
=

Thanks.
W
--001a113bc8803d0e510545648eae-- From nobody Thu Jan 5 19:47:04 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E01297AB for ; Thu, 5 Jan 2017 19:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9zBny3Z3TlR for ; Thu, 5 Jan 2017 19:47:02 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED2B129415 for ; Thu, 5 Jan 2017 19:47:02 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id l7so20142633qtd.1 for ; Thu, 05 Jan 2017 19:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WvUEutaNcCpTe0hJFesg8YJMreNVj7KXi1expeXX+YU=; b=oD0h1yBSbYnsIjMohplUDDolfBaJokHLTk9rf2xB/l5XHGlQ7EujlM5kftRIsVuO6f 12UQ1g5WH2keof/7CbQaVK5mPs5dG4X3oUClBG6sOJIZg867eHm3RK5wXfn4b6E3xZa8 aBIUpga2GINoKEjcerJsiqW+3RQab+qr3DN8wPXspGpDDhdDXKTEl1xa0ChudOzoxW14 7rJu6H8kr2bTfb5WKF1UsKQDyTTVQBSOjd0tFr6bjJbSJNK76pBg64jqQlCLHLm5+EBp /iVrFDPmzZFi1lpfYowA5elD9bdZAoTJ/b1hI07tN3iw6yRyeeaixa4clKqDpPensWGF Rzow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WvUEutaNcCpTe0hJFesg8YJMreNVj7KXi1expeXX+YU=; b=jRhtbajA0CnwT6B6f7FTLv/mkqZabaOCYRgJBZ2Oa51mPWDBH2N0bUBRQyUAXPWab7 m7kBOAYJLUaFz0lg6ndsJTnDk//LBprXwMwvteH56/cb8nL5Q9FCekbRdljP5rAjMdM0 WIx7ZrZZ7Ls+B9hSfuj1BMEKG4g4Bm83b+Oj9W7IFHDvbOVP0iEwjBdYrhLPKoebXOBb Yvcf91F4v6tq8tZ4rxR119O/WuxN9AOJtRInzcHWptbvdcn+96lPCkZDISOcyr91hoWD 6zfG5hf63wrvrqK4hF32iZst3BuoCVsZ2nLNn5gR1RcRLtSTYHLgDHXRNV/ZxDywERtw z/sw== X-Gm-Message-State: AIkVDXI/aBlb8PLZ13zdWV+rrwdhKeCbeux+bn64a85V2nb7yjZ+/66ZGys02J3xJIRE6qQp7ykFW0qK5ZAjAkkg X-Received: by 10.200.50.93 with SMTP id y29mr79095589qta.124.1483674421074; Thu, 05 Jan 2017 19:47:01 -0800 (PST) MIME-Version: 1.0 References: <6cdc7899-f0f4-e735-a844-1a40bf1314fb@gmail.com> In-Reply-To: From: Warren Kumari Date: Fri, 06 Jan 2017 03:46:50 +0000 Message-ID: To: Sara Dickinson , dns-privacy@ietf.org Content-Type: multipart/alternative; boundary=001a1137b834d4b2ae054564de6c Archived-At: Subject: Re: [dns-privacy] More WGLC reviews for TLS Profiles draft? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 03:47:03 -0000 --001a1137b834d4b2ae054564de6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 8, 2016 at 4:52 AM Sara Dickinson wrote: > Hi All, > > Just to follow up on Tim=E2=80=99s mail. Any reviews of > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/= would > be much appreciated to try to wind up the WGLC asap. > I'm not sure I'd count this as ASAP, but the chairs finally got a chance to discuss this, and believe that we now have sufficient discussions and feedback to judge there to be consensus for progressing this document. Thanks to the authors for hanging in there, and to those who reviewed and provided feedback on this document. Warren (for the chairs) > > Regards > > Sara. > > > Begin forwarded message: > > *From: *Tim Wicinski > *Subject: **[dns-privacy] Thanks for input on padding-profile > draft....now can we talk TLS Profiles?* > *Date: *29 November 2016 17:54:21 GMT > *To: *"dns-privacy@ietf.org" > > > All > > We are grateful for the feedback on edns-padding-profile document, The > Chairs would like to get some more comments on the TLS Profiles draft, > found here: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ > > There was some good discussion during the meeting in Seoul, but we don't > have enough discussion on the mailing to move this draft forward. > > thanks > tim > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --001a1137b834d4b2ae054564de6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, De= c 8, 2016 at 4:52 AM Sara Dickinson <sara@sinodun.com> wrote:
Hi All,=C2=A0

Just to follow = up on Tim=E2=80=99s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-= tls-profiles/=C2=A0would be much appreciated to try to wind up the WGLC= asap.=C2=A0

I'= m not sure I'd count this as ASAP, but the chairs finally got a chance = to discuss this, and believe that we now have sufficient discussions and fe= edback to judge there to be consensus for progressing this document.
<= div>
Thanks to the authors for hanging in there, and to those= who reviewed and provided feedback on this document.

<= div>Warren (for the chairs)


=C2=A0<= /div>

Regards

Sara.=C2=A0


Begin forwa= rded message:

From: Tim Wicinski <tjw.ietf@gmail.com>
Subject: [dns-privacy] Thanks for input on = padding-profile draft....now can we talk TLS Profiles?
Date: 29 November 2016 17:54:21 GMT
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org&= gt;


All

We are grateful for the feedback on edns-padding-profile doc= ument, The Chairs would like to get some more comments on the TLS Profiles = draft, found here:

https://datatracker.ietf.org/doc/= draft-ietf-dprive-dtls-and-tls-profiles/

There was some good discussion during the meeting in Seoul= , but we don't have enough discussion on the mailing to move this draft= forward.

thanks
tim

____________= ___________________________________
dns-privacy mail= ing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-= privacy

__________________________________________= _____
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/li= stinfo/dns-privacy
--001a1137b834d4b2ae054564de6c-- From nobody Fri Jan 6 14:03:10 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B960012967C for ; Fri, 6 Jan 2017 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD4dGRgh3QCY for ; Fri, 6 Jan 2017 14:03:08 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359EC12965F for ; Fri, 6 Jan 2017 14:03:08 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id x49so24965241qtc.2 for ; Fri, 06 Jan 2017 14:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8+C+E/3wv3Yt8z/vJdHH0Bp7Tc+/q7O9cHK7h01ch1o=; b=dI3DRAwzmCwR6fB0TFlqx8fQbK/Z2LIvso4di1gd/kO2Vqud3ERTY0nQMFLhvIxWd2 weGxQbXSV9/NujOpjhVZoqI7ijLDtv+w0EhjHk05Sl7DA6SIsFFle3mLgINXti8ZG4ay KAWpaq8/3z7NMS+8FotJB0FICp5ZKGAxFPUAfT83V9jGToylRTTOX4Orojt3kH3VvwwX 8e/nGkUC/hcHUvqoCEbk5ztlBy+hvcnyLFq533CWsgPNCS9KaDOcWVT6LaYwLgo/Q3j9 E8Uv/a0ktGj3bp+qOxdEAVRCxTPd/wt1Ksd82ee/S0qi8AbbeTQzBN1tXaVVEIb42+Bu hwVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8+C+E/3wv3Yt8z/vJdHH0Bp7Tc+/q7O9cHK7h01ch1o=; b=LvORFRJ+ge73bYTPXaYgczgIx8SkCreBP2U3Yg52txdFajtgi4lP9wZBN9DY0TFDbC 0UpEooY5HwVbHOOmRTL8Y5lRSOfiiLXlkSUtHvJdTox+v36RVk9QLoX8byl5yKoAoNWR MqirdhZ/DadRJ+e/QNUjGGlQpWLqsM6QeTcJhQTGzEXgfq55x603Fpw9D9C9M0VZeFjm TPx0/6pW6a5mVOqL7SXvxSIg1VIjcExBpSnDqCkQ5mmsmcZ4d5iechaNd5B9Nbv8LgI2 zv8hRFoaB9tB+wVH5Sr0ivejPnWtVjhVPiRc3tT4ATzyYbUmVW+6YhHyGOyXLlECJMyP A/sg== X-Gm-Message-State: AIkVDXIwLPNf8is8GRajdxzJyYYeHOMIw1LcGghdeO6/3is4lAAXxOZfGTdzVeVE3WOj5HlMAJss5PsfDxo6lL2N X-Received: by 10.237.54.97 with SMTP id e88mr80066178qtb.57.1483740186812; Fri, 06 Jan 2017 14:03:06 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Fri, 06 Jan 2017 22:02:56 +0000 Message-ID: To: "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary=001a11443c98c6c4b20545742e33 Archived-At: Subject: [dns-privacy] Reminder: DNS Privacy Workshop - co-located with NDSS X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:03:09 -0000 --001a11443c98c6c4b20545742e33 Content-Type: text/plain; charset=UTF-8 Hi all, This was announced on the list a while back -- http://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-call-papers Location and Important Dates Workshop Location: San Diego, CA, USA Workshop date: 2017-02-26 (co-located with NDSS 2016) I figured it was worth reminding people about this, as many people are starting to organize their travel. W --001a11443c98c6c4b20545742e33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,


Location an= d Important Dates
Workshop Location: San Diego, CA, USA
Workshop date: 2017-02-26 (co-located with NDSS 2016)

=
I figured it was worth reminding people about this, as many peop= le are starting to organize their travel.

W
<= /div> --001a11443c98c6c4b20545742e33-- From nobody Mon Jan 9 03:50:25 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973BD129C13 for ; Mon, 9 Jan 2017 03:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 dMuAOjph5pTx for ; Mon, 9 Jan 2017 03:50:21 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1329129C0F for ; Mon, 9 Jan 2017 03:50:21 -0800 (PST) Received: from [2001:b98:204:102:fffa::a] (port=49317) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cQYSx-0005HU-OE; Mon, 09 Jan 2017 11:50:20 +0000 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FD6B12C9-3F18-4FE0-AF80-99E42437E288" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 9 Jan 2017 11:50:13 +0000 In-Reply-To: To: Warren Kumari References: <6cdc7899-f0f4-e735-a844-1a40bf1314fb@gmail.com> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] More WGLC reviews for TLS Profiles draft? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 11:50:24 -0000 --Apple-Mail=_FD6B12C9-3F18-4FE0-AF80-99E42437E288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Jan 2017, at 03:46, Warren Kumari wrote: >=20 >=20 > On Thu, Dec 8, 2016 at 4:52 AM Sara Dickinson > wrote: > Hi All,=20 >=20 > Just to follow up on Tim=E2=80=99s mail. Any reviews of = https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ = would be much appreciated to try to wind up the WGLC asap.=20 >=20 > I'm not sure I'd count this as ASAP, but the chairs finally got a = chance to discuss this, and believe that we now have sufficient = discussions and feedback to judge there to be consensus for progressing = this document. >=20 > Thanks to the authors for hanging in there, and to those who reviewed = and provided feedback on this document. >=20 > Warren (for the chairs) Hi Warren,=20 Thanks for this. I=E2=80=99ll get an updated version of the draft out = asap to address the most recent comments.=20 Sara.=20 --Apple-Mail=_FD6B12C9-3F18-4FE0-AF80-99E42437E288 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 6 Jan 2017, at 03:46, Warren Kumari <warren@kumari.net> = wrote:


On Thu, Dec 8, 2016 at 4:52 AM Sara Dickinson = <sara@sinodun.com> wrote:
Hi All, 

Just to follow up on = Tim=E2=80=99s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-= and-tls-profiles/ would be much appreciated to try to wind up = the WGLC asap. 

I'm not sure I'd count = this as ASAP, but the chairs finally got a chance to discuss this, and = believe that we now have sufficient discussions and feedback to judge = there to be consensus for progressing this document.

Thanks to the authors = for hanging in there, and to those who reviewed and provided feedback on = this document.

Warren (for the = chairs)

Hi = Warren, 

Thanks for this. = I=E2=80=99ll get an updated version of the draft out asap to address the = most recent comments. 

Sara. 

= --Apple-Mail=_FD6B12C9-3F18-4FE0-AF80-99E42437E288-- From nobody Mon Jan 9 04:15:53 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B8D129C45 for ; Mon, 9 Jan 2017 04:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQPzz2c8PHlH for ; Mon, 9 Jan 2017 04:15:50 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3702E129C3C for ; Mon, 9 Jan 2017 04:15:50 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id x49so67619836qtc.2 for ; Mon, 09 Jan 2017 04:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GRuXqwRvKLndqi0Q4guj/pknWiQHP5BgJU6jM/iGstc=; b=cqNSu05ki/b1cVgiF7MlT+QlrqzcvXft1OkRVc4gKBPDKpon2OfHhrY005URthco9c fsLfF4+YRX8/16zEI/qUnhyd/0tUizJHVBNFaQ/EEbKSNqqXo+EoP1EehgXTg7z4cz+g nLsxfnXRX9Mlbtt2ypVHt7VWL83FTp27ogIizqpeeN/4br4k7qcHU2CLreo6+q6U5HTx 6qJ9eh5ftrmfJ05I8n9zQ7VdRPfB0c97nTTUR5kobfuXn7A6i8H99QMYJ+riJ0BCUNLL EWdALPf+pNhRdMu/Z97pZVnlIF+qB7yfZEYHrXksIpfp2dDue5Hqa01eoBXceLNF4cGq NmmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GRuXqwRvKLndqi0Q4guj/pknWiQHP5BgJU6jM/iGstc=; b=NA70ZBTZjn8DDQKcqg/74oro7e27jVGpF1ZiUVVLtPqQqvbL3vbumL1+vaLl0CLb6m IZRVGlQvGGennNREGt35+nrSQ+Tlu5hjyFV4kAkL6qhU4BmstgUe4CBRdWKXBbzWRfEN FZdShQpNRjjIBCV2OwijLpXQKUNSB9654H6KMLCY8+FnFFOv+7vZugTprxpGOTWSfZt8 +gXK5UEP0gv+YTc9ZFhGR7SklInsXfOdeROa7AlvIx4AgWP9zrdag4uRyeTIjhs3K7zL Zr3cJNrYURggkmqpfUt58QToahuvS2pqfdDBQopvwsOMhUGJpTCeZOZBvupcqAdSj/HM zEmg== X-Gm-Message-State: AIkVDXLhj5960VOoyOdndXBXn4UCsnuvXXIw/uehlLMcJ+Hq1+5K93RkhCazOp0JU/Yxe4rToLxCUQ14ZFEteoNE X-Received: by 10.237.35.246 with SMTP id k51mr82662730qtc.263.1483964148747; Mon, 09 Jan 2017 04:15:48 -0800 (PST) MIME-Version: 1.0 References: <6cdc7899-f0f4-e735-a844-1a40bf1314fb@gmail.com> In-Reply-To: From: Warren Kumari Date: Mon, 09 Jan 2017 12:15:38 +0000 Message-ID: To: Sara Dickinson Content-Type: multipart/alternative; boundary=001a113f6202f2605a0545a85301 Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] More WGLC reviews for TLS Profiles draft? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:15:52 -0000 --001a113f6202f2605a0545a85301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great, thanks! W On Mon, Jan 9, 2017, 6:50 AM Sara Dickinson wrote: > > On 6 Jan 2017, at 03:46, Warren Kumari wrote: > > > On Thu, Dec 8, 2016 at 4:52 AM Sara Dickinson wrote: > > Hi All, > > Just to follow up on Tim=E2=80=99s mail. Any reviews of > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/= would > be much appreciated to try to wind up the WGLC asap. > > > I'm not sure I'd count this as ASAP, but the chairs finally got a chance > to discuss this, and believe that we now have sufficient discussions and > feedback to judge there to be consensus for progressing this document. > > Thanks to the authors for hanging in there, and to those who reviewed and > provided feedback on this document. > > Warren (for the chairs) > > > Hi Warren, > > Thanks for this. I=E2=80=99ll get an updated version of the draft out asa= p to > address the most recent comments. > > Sara. > > --001a113f6202f2605a0545a85301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Great, thanks!

W


On Mon, Jan 9, 2017, 6:50 A= M Sara Dickinson <sara@sinodun.com> wrote:

On 6 Jan 2017, at 03:46, Warren Kumari <warren@kumari.net> w= rote:


On Thu, Dec 8, 2016 at 4:52 AM Sara Dickinson <sara@sinodu= n.com> wrote:
Hi All,=C2=A0<= div class=3D"gmail_msg">
Just to follow up on Tim=E2=80=99s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ie= tf-dprive-dtls-and-tls-profiles/=C2=A0would be much appreciated to try = to wind up the WGLC asap.=C2=A0

I&= #39;m not sure I'd count this as ASAP, but the chairs finally got a cha= nce to discuss this, and believe that we now have sufficient discussions an= d feedback to judge there to be consensus for progressing this document.

Thanks to the authors for hanging in there, and to those who review= ed and provided feedback on this document.
Warren (for the chairs= )

<= div style=3D"word-wrap:break-word" class=3D"gmail_msg">
Hi Warren,=C2=A0

Thanks for this. I=E2=80=99ll get an update= d version of the draft out asap to address the most recent comments.=C2=A0<= /div>

Sar= a.=C2=A0

--001a113f6202f2605a0545a85301-- From nobody Wed Jan 11 13:38:11 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1091295B6 for ; Wed, 11 Jan 2017 13:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFEmuwl8Ftwp for ; Wed, 11 Jan 2017 13:38:06 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F6D129579 for ; Wed, 11 Jan 2017 13:38:06 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id 137so654360vkl.0 for ; Wed, 11 Jan 2017 13:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KF3Aort7gQb3vWOatSCMJ/wfrxf2PVUqxJN+h9z4OC8=; b=cF9IHa4tN/+U9SgEeD+DalnY2yMwN8uykBa+/FRHmhGNPYqydqZ5ncxEVkfFrGbwp0 22ASB/s0juRp/fL47lWZ+gVDJk6qIV64a8N0l9Ofj1BXSJY1w2JMARc07lSwdxhyg0vp 4dDj9J5ipirLaR113wkBaDD9vf1+vxZBIg3mbQA+Kqd5MMl8bXz1Vrxw74gvmc37teqY 5D1ciHX33zkJ3HYJj0bb7o5mWxfi57uXSG+5fJbj5PtBqztigH5A8dbVekRGehuSMqXR cyTKcHVzU+R6qRp5OQrtFCLhXidcIkvg9xrqn3BDmfKy05ez8ti17DOABaFmlnW/S4Oa CZhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KF3Aort7gQb3vWOatSCMJ/wfrxf2PVUqxJN+h9z4OC8=; b=VGVmWWut0bgoynfoTj4LGKhP0SyivB/wF547KjsNiwinELiIQVSCzNvUhdthX8RjQc 5OozX7Q3yfsLecdaevKNo4kcDeOwK1vDoGI5n/EDhMQkpZ7Te4qn0mISWodKoEUPaj8q XOPtbgc8xamhJr9KzefQiIODc9nRXdg19wZnd17wJc80xQ/Wi2QSO9plbzuBGJyf8BnM fwJN2PTxTHkfDrXHl258OZ1J5mPo1k9IrxPeuNEoY3uifTnzSP2mfeFfpvHbdGJonS44 p+3mF2UtIbOwEb36HCnD2aNLl9ra3r/Ai/ssllPxM2gwoVzEuJRoV1M5Zjez1mXuJIWk C7Sg== X-Gm-Message-State: AIkVDXKjbxa8fVhoBmXLLNbz8F90cKikyFIJjKHgHQZ0y6JquzqAAXfrTNl1s6X0AgCBvTPZdoBvs8YY0E3ixw== X-Received: by 10.31.14.206 with SMTP id 197mr5239363vko.38.1484170685450; Wed, 11 Jan 2017 13:38:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.138.6 with HTTP; Wed, 11 Jan 2017 13:38:04 -0800 (PST) From: Allison Mankin Date: Wed, 11 Jan 2017 16:38:04 -0500 Message-ID: To: dns-privacy@ietf.org Content-Type: multipart/alternative; boundary=001a11457f287e10020545d86a8a Archived-At: Subject: [dns-privacy] DEADLINE EXTENSION until January 18: DNS Privacy Workshop X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:38:09 -0000 --001a11457f287e10020545d86a8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Apologies for possible multiple copies] We have extended the submission deadline for the NDSS DNS Privacy Workshop to Wednesday, January 18 because of the intervening holidays for many interested people. Please contact us (Sara and Allison) if you have questions. Note that the formats are flexed a bit as well: page lengths and format are flexible now and we are also willing to receive draft presentations as long as they have an abstract early in the deck. The goal of the workshop is interchange and advancing the state of play for DNS privacy and its adjacent technologies. The call for papers is here: DPRIV17 . The deadline on the web page at NDSS hasn't been changed yet, but the submission system is set with the new deadline. Elevator pitch: DNS queries and domain names are metadata and there are many new directions (and open questions) for mitigating privacy issues for them. Location and Important dates: Workshop Location: San Diego, CA, USA Workshop date: 2017-02-26 (co-located with NDSS 2017) Submissions: 2017-01-18 anywhere-on-earth Final date for notifications and invitations to present at the workshop: 2017-02-03 Submissions may be new papers, papers already published, Short Papers, or Position Papers. Also, please contact the TPC chairs if you want to suggest a panel. Allison and Sara allison.mankin@gmail.com sara@sinodun.com ------------ *Workshop on DNS Privacy DPRIV17 (#NoMoreCowbell)* BackgroundDNS Privacy has been a growing concern of the IETF and others in the Internet engineering community for the last few years. Almost every activity on the Internet starts with a DNS query (and often several). - Those queries can reveal not only what websites an individual visits but also metadata about other services such as the domains of email contacts or chat services. - Whilst the data in the DNS is public, individual DNS transactions made by an end user *should not* be public. - Today, however DNS queries are sent in *clear text* (using UDP or TCP) which means passive eavesdroppers can observe all the DNS lookups performed. - The DNS is a globally distributed system that crosses international boundaries and often uses servers in many different countries in order t= o provide resilience. - It is well known that the NSA used the MORECOWBELL tool to perform mass surveillance of DNS traffic, and other surveillance techniques involving DNS almost certainly are in play today. - Some ISPs embed user information (e.g. a user ID or MAC address) within DNS queries that go to the ISP=E2=80=99s resolver in order to pro= vide services such as Parental Filtering. This allows for fingerprinting of individual users. - Some CDNs embed user information (e.g. client subnets) in queries from resolvers to authoritative servers (to geo-locate end users). This allow= s for correlation of queries to particular subnets. - Some ISPs log DNS queries at the resolver and share this information with third-parties in ways not known or obvious to end users. The IETF's DPRIVE (*D*NS *PRIV*ate *E*xchange) Working Group has taken initial protocol steps to address these concerns (with much of the early work focussing on the stub to resolver problem), publishing DNS Privacy Considerations (RFC 7626), Specification for DNS over Transport Layer Security (RFC 7858), and The EDNS(0) Padding Option (RFC 7830), and DNS Query Name Minimisation to Improve Privacy (RFC 7816). However because of the great diversity of the DNS ecosystem, and the pervasive role of DNS and domain names in Internet applications and security, much is not fully understood or resolved. The goal of this workshop is to bring together privacy and Internet researchers with a diversity of backgrounds and views, to identify promising long-term mitigations of the broad space of DNS privacy risks. --001a11457f287e10020545d86a8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Apologies for possible multiple copies]

We have extended the submission deadline for the NDSS DNS Privacy Work= shop to Wednesday, January 18 because of the intervening holidays for many = interested people.=C2=A0 Please contact us (Sara and Allison) if you have q= uestions.=C2=A0 Note that the formats are flexed a bit as well:=C2=A0 page = lengths and format are flexible now and we are also willing to receive draf= t presentations as long as they have an abstract early in the deck.=C2=A0 T= he goal of the workshop is interchange and advancing the state of play for = DNS privacy and its adjacent technologies.

The call for pap= ers is here: =C2=A0 DPRIV17.=C2=A0 The deadline on the web page at NDSS hasn&#= 39;t been changed yet, but the submission system is set with the new deadli= ne.

Elevator pitch:=C2=A0 DNS queries and domain names are metadata and there are many= =20 new directions (and open questions) for mitigating privacy issues for=20 them.

Location and Important dates:
Workshop Location: San Diego,= CA, USA

Workshop date: 2017-02-26 (co-located with NDSS 2017)=C2=A0

Submissions: 2017-01-18 anywhere-on-earth

Final date for notifications and invitations to present at the workshop:= 2017-02-03

Submissions may be new papers, papers already published, Short Papers, or Position=20 Papers.=C2=A0 Also, please contact the TPC chairs if you want to suggest a= =20 panel.

Allison and Sara

allison.mankin@gmail.com
sara@sinodun.com

------------=

Workshop on DNS Privacy DPRIV17 (#NoMoreCowbell)

Background

= DNS Privacy has been a growing concern of the IETF and others in the=20 Internet engineering community for the last few years.=C2=A0 Almost every= =20 activity on the Internet starts with a DNS query (and often several).=C2=A0

  • Those queries can reveal not only what websites = an individual visits but also metadata about other services such as the domains of email=20 contacts or chat services. =E2=80=A8
  • Whilst the data in the DNS is = public, individual DNS transactions made by an end user should not<= /strong> be public.=E2=80=A8
  • Today, however DNS queries are sent in= clear text (using UDP or TCP) which means passive eavesdr= oppers can observe all the DNS lookups performed.=E2=80=A8
  • The DNS = is a globally distributed system that crosses international=20 boundaries and often uses servers in many different countries in order=20 to provide resilience.=E2=80=A8
  • It is well known that the NSA used = the MORECOWBELL tool to perform=20 mass surveillance of DNS traffic, and other surveillance techniques=20 involving DNS almost certainly are in play today. =C2=A0=E2=80=A8
  • S= ome ISPs embed user information (e.g. a user ID or MAC address)=20 within DNS queries that go to the ISP=E2=80=99s resolver in order to provid= e=20 services such as Parental Filtering. This allows for fingerprinting of=20 individual users.=E2=80=A8
  • Some CDNs embed user information (e.g. c= lient subnets) in queries=20 from resolvers to authoritative servers (to geo-locate end users). This=20 allows for correlation of queries to particular subnets.=E2=80=A8
  • S= ome ISPs log DNS queries at the resolver and share this information with third-parties in ways not known or obvious to end users.=C2=A0

    • The IETF's DPRIVE (DNS PRIVate Exchange) Working Group has taken initial protocol steps to address these=20 concerns (with much of the early work focussing on the stub to resolver=20 problem), publishing DNS Privacy Considerations (RFC 7626),=20 Specification for DNS over Transport Layer Security (RFC 7858), and The=20 EDNS(0) Padding Option (RFC 7830), and DNS Query Name Minimisation to=20 Improve Privacy (RFC 7816). However because of the great diversity of=20 the DNS ecosystem, and the pervasive role of DNS and domain names in=20 Internet applications and security, much is not fully understood or=20 resolved. =C2=A0

    The goal of this workshop is to bring together privacy and Internet=20 researchers with a diversity of backgrounds and views, to identify=20 promising long-term mitigations of the broad space of DNS privacy risks.



--001a11457f287e10020545d86a8a-- From nobody Tue Jan 17 02:22:49 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D7129450 for ; Tue, 17 Jan 2017 02:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3Amhny9O8n1N for ; Tue, 17 Jan 2017 02:22:47 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8A712941E for ; Tue, 17 Jan 2017 02:22:47 -0800 (PST) Received: from [240c:f:1:4000:8a63:3b33:66a5:1600] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1cTQuf-0002ay-0D for dns-privacy@ietf.org; Tue, 17 Jan 2017 10:22:49 +0000 Date: Tue, 17 Jan 2017 18:22:29 +0800 From: Shane Kerr To: dns-privacy@ietf.org Message-ID: <20170117182229.73efff48@pallas.home.time-travellers.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/nGacZm/fu4MiFxv.czFZsfg"; protocol="application/pgp-signature" Archived-At: Subject: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 10:22:48 -0000 --Sig_/nGacZm/fu4MiFxv.czFZsfg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I'm sorry if it has already been discussed, but has there been any work done on using TLS for AXFR/IXFR? It seems like it should be relatively straightforward, compared to the stub-to-resolver and resolver-to-authority links. While it does not seem as big of a problem either, obviously somebody cares about hiding the contents of zones or everybody wouldn't block zone transfers, right?=20 There are still some issues to consider, such as what the interaction of TSIG and TLS certificates means, as well as what method a master can use to signal TLS support (this seems desirable to me, although not necessary). Does this seem like something worth working on? Or is it a distraction from the resolver-to-authority work? Note also that it might be worthwhile building a new zone transfer protocol that can perform better in areas where AXFR and IXFR don't work well today (unnecessary data in IXFR of signed zones, inefficiency for synchronizing lots of zones, automatic fallback to full zone transfer on IXFR failure, and so on). That's not really something for DPRIVE, of course, but adding TLS to the protocol could be rolled into such an activity. Cheers, -- Shane --Sig_/nGacZm/fu4MiFxv.czFZsfg Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdhRx2J+MnJeBOVlgNzKXnPlnswYFAlh98GUACgkQNzKXnPln swZ5yRAAh+n8B2B2RxhkMb8OlEn2cnL0wzMz3GinEbAGsGnKLXXpiMTpJy5bhPR/ Zrk5b6MpUroM7D6apCEsdt4ogmtkTZBFx98LaZiwR1YSr/DiVgOizt+S71UdAZ1J OQiHOms7J0EMw3ERjyV7FkJT6snDp2Q6xOgPtEGmchHg5bdxqhlFusB3K3pLAnT8 CU0BeZ/lLVQaB+1Q/NSZAF+kqzzicNuzJ/1IQaVO9hSuqMMMtHb5TQd+C25BRTse tR/nEKmFoblZEb6+J7eo6AbHSHdk9ePumD8LX8XfueUp2rYzlsYTSR2U9nFzxJ/1 nK1w4oB7LK2rjLYkE0JEFE00VbkhnG4UAH6A8pXy4ymxw6Rb4McGEm6Zlw9KcuHP go0bi9rTg1vAIPYOLqvHw8d/aNrXlOWcONjJcI5WYNRAgKj0BXaryWm3BYd9WgK0 54m2iZqeJGHRgSbH/mmKJCGUi1r9cg4fLJfIRJ/NfVgHzguC00kmtgFTR5Vk52CC BrlcS7e7MvDfitL2dEXDE6ELmnPxTjBQDRQhLFlEyejc6vO1+Jh8K6ju5kd9UhKe A/IqZDvrKKUPFtR1y9oV7G/0C5DUOa67jByby4R6tO04uvHxpmxIdHLxWNflOKew dq0kNDEoxsp8fyGc5Ui9H+Yp7nqIIRkjDSiv1lgAXCVfVZz7pG0= =NwgU -----END PGP SIGNATURE----- --Sig_/nGacZm/fu4MiFxv.czFZsfg-- From nobody Tue Jan 17 02:47:37 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC43512999F for ; Tue, 17 Jan 2017 02:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 7zMdDO-vsTok for ; Tue, 17 Jan 2017 02:47:34 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 9203112998E for ; Tue, 17 Jan 2017 02:47:34 -0800 (PST) Received: from jurassic (unknown [115.118.26.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 5BA522FA02A1; Tue, 17 Jan 2017 10:47:32 +0000 (GMT) Date: Tue, 17 Jan 2017 16:17:27 +0530 From: Mukund Sivaraman To: Shane Kerr Message-ID: <20170117104727.GA28530@jurassic> References: <20170117182229.73efff48@pallas.home.time-travellers.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20170117182229.73efff48@pallas.home.time-travellers.org> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 10:47:36 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 17, 2017 at 06:22:29PM +0800, Shane Kerr wrote: > Note also that it might be worthwhile building a new zone transfer > protocol that can perform better in areas where AXFR and IXFR don't > work well today (unnecessary data in IXFR of signed zones, inefficiency > for synchronizing lots of zones, automatic fallback to full zone > transfer on IXFR failure, and so on). That's not really something for > DPRIVE, of course, but adding TLS to the protocol could be rolled into > such an activity. On a side note, because any encryption will require a change to the DNS protocol (i.e., putting things into a crypto box which isn't backwards compatible) IMO it would be worthwhile to consider revisiting the DNS message format. For parsing queries at nearly link speed, the DNS message format isn't best suited: * DNS owner name fields are variable length which makes the message difficult to filter (e.g., it requires a DNS specific packet filter to match on the question type field because the name field is variable length and has no length prefix either, so one has to parse almost the entire name to find out how long it is). * when parsing a query, the implementation wants to know whether to accept/serve the query at all, e.g., by examining things in the OPT RR (cookie, etc.) and TSIG RR, which come in the additional section and requires skipping variable length fields (owner names) on the way which isn't fast. * DNS name compression isn't the greatest idea. Compression code needs to be extremely fast (and it can't be skipped according to RFC 1123), and this is best left to general purpose compression libraries than having to implement this protocol-specific method (which has its issues btw.. limited to RFC 1035 names with some quirks, limited to 16k offset from 0 => poor AXFR, etc.). It's not easy for DNS implementors to get high compression to performance ratio even with the lacklustre name compression scheme. * There's redundancy in fields when considering RRsets. Sara Dickinson said something in her talk in Seoul that their DNS traffic recording system achieved a low per-message space utilization. Things to achieve would be to allow implementations to: - get at things they need to parse quickly - avoid redundancy in messages - remove compression or use general purpose compression - prefix names with whole-name lengths so they can be quickly skipped if necessary Mukund --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYffY/AAoJEB9EXrAiC5LsBNcP/3r2YukUXs5un7BUSLmvU2sv y1iEvisy+5fST3J+X2mGUi4vYmhK0cfVJXHlzYUH+DEiHHgk5BB+FQfW3lYBUI6O jKMSvfBukeA/jY0ANBhNBSEEtA5P1eJ541nUDe+NsNFWZroMKZ+eLraOVfuGEz47 uIIurFUza6JaJE7txOYEBOMvgKwXtF7VBR8Yi6DidkcT3+sw9ZfwQk3BcKhFedF/ wB3e32lCULYDpDzO3q3vI1YIIlKjIMQUwmM6Z01yaLPplK+8WJzG7JsrMl8idpfU qxSvZbvfl9AVHkJzOnhsVGNaMFu0xEWtluGbpG/2PhyUmWqntnEl5C0LJXi1rymy Ys+sfbl/0QlrwxSHCko/7cF0HErOMBYbEjsVJpwPuX0KIhcRm1MO/lHmq3Rr3XX5 AJu77rTAWm2WkfKFFsFJRXfhCvt3ngbcS1odkNlAGpgAXVIQ6SDWVDgNVbC27IPx u5KSNqxGxKGWeMhOrJZupvRoWxQrW9/+/J7p+t8IReAIPiBD8PLpxX5FV8Mou3cx /ZhwjtGSzQXWyXzhSl5vtsbffvCF3kMTu2DJewHdokZJHjh/Q0Tp5JEmx7Kcv9VK AvxCliJfdxajnp22/1OCs9vXRwVYPRvibLMH1yooz7HJgv0EJC7yoQl/vdv0bet8 u9HM2J/YE/DsoPenxm8L =cQbX -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From nobody Tue Jan 17 05:32:10 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB656126FDC for ; Tue, 17 Jan 2017 05:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NXzxprRE5jSx for ; Tue, 17 Jan 2017 05:32:07 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D311293EE for ; Tue, 17 Jan 2017 05:32:07 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 9E3061FCAB6; Tue, 17 Jan 2017 13:32:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5319C160072; Tue, 17 Jan 2017 13:32:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 346E6160070; Tue, 17 Jan 2017 13:32:02 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 799_3VesENEt; Tue, 17 Jan 2017 13:32:02 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C490216006F; Tue, 17 Jan 2017 13:32:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7DABD5F9D85E; Wed, 18 Jan 2017 00:31:57 +1100 (EST) To: Shane Kerr From: Mark Andrews References: <20170117182229.73efff48@pallas.home.time-travellers.org> In-reply-to: Your message of "Tue, 17 Jan 2017 18:22:29 +0800." <20170117182229.73efff48@pallas.home.time-travellers.org> Date: Wed, 18 Jan 2017 00:31:57 +1100 Message-Id: <20170117133157.7DABD5F9D85E@rock.dv.isc.org> Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 13:32:09 -0000 In message <20170117182229.73efff48@pallas.home.time-travellers.org>, Shane Kerr writes: > Hello, > > I'm sorry if it has already been discussed, but has there been any work > done on using TLS for AXFR/IXFR? > > It seems like it should be relatively straightforward, compared to the > stub-to-resolver and resolver-to-authority links. While it does not > seem as big of a problem either, obviously somebody cares about hiding > the contents of zones or everybody wouldn't block zone transfers, > right? People do lots of things which for the most part do nothing useful like the mistaken belief that preventing people seeing the zone content provides some sort of real security. This rose out of the rsh days where if you could poision caches with false PTR/A record pairs of known machine names you could break into machines using rsh. From this came the misguided advise to block zone transfers whereas increasing zone transfers would actually prevent the poisoning actually happening. Replacing rsh with ssh removed this vulnerability but people still continued to believe the myth. Machine names get learnt all the time. If you security depends on machines names being unknown you have no security. > There are still some issues to consider, such as what the interaction of > TSIG and TLS certificates means, as well as what method a master can > use to signal TLS support (this seems desirable to me, although not > necessary). > > Does this seem like something worth working on? Or is it a distraction > from the resolver-to-authority work? > > Note also that it might be worthwhile building a new zone transfer > protocol that can perform better in areas where AXFR and IXFR don't > work well today (unnecessary data in IXFR of signed zones, inefficiency > for synchronizing lots of zones, automatic fallback to full zone > transfer on IXFR failure, and so on). That's not really something for > DPRIVE, of course, but adding TLS to the protocol could be rolled into > such an activity. > > Cheers, > > -- > Shane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jan 17 07:54:52 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9812955B for ; Tue, 17 Jan 2017 07:54:50 -0800 (PST) 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 autolearn_force=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 PrR9uYYevG-g for ; Tue, 17 Jan 2017 07:54:49 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86080129553 for ; Tue, 17 Jan 2017 07:54:49 -0800 (PST) Received: from [10.32.60.145] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v0HFrnfp019731 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Jan 2017 08:53:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.145] From: "Paul Hoffman" To: "Mukund Sivaraman" Date: Tue, 17 Jan 2017 07:54:45 -0800 Message-ID: In-Reply-To: <20170117104727.GA28530@jurassic> References: <20170117182229.73efff48@pallas.home.time-travellers.org> <20170117104727.GA28530@jurassic> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:54:50 -0000 On 17 Jan 2017, at 2:47, Mukund Sivaraman wrote: > On Tue, Jan 17, 2017 at 06:22:29PM +0800, Shane Kerr wrote: >> Note also that it might be worthwhile building a new zone transfer >> protocol that can perform better in areas where AXFR and IXFR don't >> work well today (unnecessary data in IXFR of signed zones, >> inefficiency >> for synchronizing lots of zones, automatic fallback to full zone >> transfer on IXFR failure, and so on). That's not really something for >> DPRIVE, of course, but adding TLS to the protocol could be rolled >> into >> such an activity. > > On a side note, because any encryption will require a change to the > DNS > protocol (i.e., putting things into a crypto box which isn't backwards > compatible) IMO it would be worthwhile to consider revisiting the DNS > message format. Shane was talking about wrapping the DNS traffic in TLS. This does not "require a change to the DNS protocol", as we have already seen in this WG. --Paul Hoffman From nobody Tue Jan 17 08:36:30 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9D1299A5; Tue, 17 Jan 2017 08:36:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148467098359.32027.17947941261903106337.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 08:36:23 -0800 Archived-At: Cc: Tim Wicinski , The IESG , draft-ietf-dprive-dnsodtls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, terry.manderson@icann.org, rfc-editor@rfc-editor.org Subject: [dns-privacy] Document Action: 'Specification for DNS over Datagram Transport Layer Security (DTLS)' to Experimental RFC (draft-ietf-dprive-dnsodtls-15.txt) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:36:24 -0000 The IESG has approved the following document: - 'Specification for DNS over Datagram Transport Layer Security (DTLS)' (draft-ietf-dprive-dnsodtls-15.txt) as Experimental RFC This document is the product of the DNS PRIVate Exchange Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/ Technical Summary This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. Working Group Summary The working group chose Experimental over Proposed Standard because the authors have indicated they are not willing to attempt implemntating this, nor have they attempted to find anyone to implement this. While the working group confirmed publication, this document shepherd (and working group co-chair) is conflicted. The lack of implementation anytime in the near future means this will get published but never actually used. While the working group does not see this as a problem, I feel it sets a bad precedent. Document Quality The document was reviewed very heavily by the working group, and c compared to the previous document DNS-over TLS https://datatracker.ietf.org/doc/rfc7858/ The working group made several requests which the authors performed. The biggest one was the removal of the Authenication profiles and placed in a separate document draft-ietf-dprive-dtls-and-tls- profiles which is currently working through the working group and is slated for last call. The consensus was positive on adopting and publishing this draft, and the working group did not have many comments about the lack of implementations, or if a document without any planned implementations should be published. Personnel Document Shepherd: Tim Wicinski Area Director: Terry Manderson RFC Editor Note Please note the IESG note as follows =-=-=-=-=-=-=-=- This DTLS solution was considered by the DPRIVE working group as a potential option to use in case that the TLS based approach specified in RFC7858 is shown to have detrimental deployment issues. At the time of writing, it was expected that RFC7858 will be deployed, and so this specification is primarily intended as a backup and has therefore been designated as experimental. This solution should not be deployed in the wild while in this experimental state as an RFC, however experimentation is encouraged. =-=-=-=-=-=-=-=- From nobody Tue Jan 17 12:04:45 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D649129480 for ; Tue, 17 Jan 2017 12:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HzBu0mXGPJMF for ; Tue, 17 Jan 2017 12:04:41 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1851129485 for ; Tue, 17 Jan 2017 12:04:40 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id BD61212C1045; Tue, 17 Jan 2017 15:04:39 -0500 (EST) Date: Tue, 17 Jan 2017 15:04:39 -0500 From: Robert Edmonds To: Shane Kerr Message-ID: <20170117200439.zqypip3hp27qnhxy@mycre.ws> References: <20170117182229.73efff48@pallas.home.time-travellers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170117182229.73efff48@pallas.home.time-travellers.org> Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:04:43 -0000 Hi, Shane: Shane Kerr wrote: > I'm sorry if it has already been discussed, but has there been any work > done on using TLS for AXFR/IXFR? There was a mini-thread back in June 2016, but I think that was it: https://mailarchive.ietf.org/arch/msg/dns-privacy/eNHQx5KT3MzqjFObqgDRswCpxi4 > It seems like it should be relatively straightforward, compared to the > stub-to-resolver and resolver-to-authority links. While it does not > seem as big of a problem either, obviously somebody cares about hiding > the contents of zones or everybody wouldn't block zone transfers, > right? I think this was explicitly mentioned at least in passing in "DNS Privacy Considerations" (RFC 7626), in §2.1 "The Alleged Public Nature of DNS Data". DPRIVE has done some work to foil traffic analysis attacks with the EDNS0 padding option, so it makes sense to me to also encrypt zone contents during distribution, because zone contents are the exact data you would need to execute a traffic analysis attack. DNSEXT defined NSEC3 on the explicit rationale of preventing zone enumeration. Implementing TLS for zone transfers would address the collection of zone content by pervasive monitoring. > There are still some issues to consider, such as what the interaction of > TSIG and TLS certificates means, as well as what method a master can > use to signal TLS support (this seems desirable to me, although not > necessary). The easiest thing to do is probably to make it all a matter of explicit configuration in server configuration files, for which system administrators have a well-known solution (configuration management). Zone transfers already require explicit configuration of several parameters, anyway, and adding TLS will require a bunch more (e.g., permitted TLS versions, permitted cipher suites, certificate validation, etc). > Does this seem like something worth working on? Or is it a distraction > from the resolver-to-authority work? I think if resolver-to-authority confidentiality is implemented, the next logical plaintext leak to plug would be zone transfers, and if the full charter were implemented ("…or provide end-to-end confidentiality of DNS transactions"), then the lack of zone transfer confidentiality would be a glaring omission. > Note also that it might be worthwhile building a new zone transfer > protocol that can perform better in areas where AXFR and IXFR don't > work well today (unnecessary data in IXFR of signed zones, inefficiency > for synchronizing lots of zones, automatic fallback to full zone > transfer on IXFR failure, and so on). That's not really something for > DPRIVE, of course, but adding TLS to the protocol could be rolled into > such an activity. But if an enhanced zone transfer (EXFR?) type were implemented, it seems like it would be nice to be able to run it over plaintext port 53, so I don't see why it should be tied to the transport. (BTW, one thing I wonder about is, for operators who *don't* use AXFR/IXFR on port 53 to distribute their zones, does the transport they use support confidentiality equivalent to TLS/SSH?) -- Robert Edmonds From nobody Tue Jan 17 17:23:52 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5AE129496 for ; Tue, 17 Jan 2017 17:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 rLaD5czGiSGZ for ; Tue, 17 Jan 2017 17:23:50 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 691BE12948C for ; Tue, 17 Jan 2017 17:23:50 -0800 (PST) Received: from jurassic (unknown [115.118.62.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 210BF2FA0021; Wed, 18 Jan 2017 01:23:47 +0000 (GMT) Date: Wed, 18 Jan 2017 06:53:44 +0530 From: Mukund Sivaraman To: Paul Hoffman Message-ID: <20170118012344.GA10453@jurassic> References: <20170117182229.73efff48@pallas.home.time-travellers.org> <20170117104727.GA28530@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:23:51 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2017 at 07:54:45AM -0800, Paul Hoffman wrote: > > On a side note, because any encryption will require a change to the DNS > > protocol (i.e., putting things into a crypto box which isn't backwards > > compatible) IMO it would be worthwhile to consider revisiting the DNS > > message format. >=20 > Shane was talking about wrapping the DNS traffic in TLS. This does not > "require a change to the DNS protocol", as we have already seen in this W= G. It does. It won't work on port 53 with an existing client. Mukund --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYfsOfAAoJEB9EXrAiC5Lsl3oP/1dLby0Y5o3qOoJkcb25Eu3/ XFVP2RiN4zKfSZ/kFxQ21kyt7/IJQAxbajJBggoPMoDd2afcfEi70UDBWZ8aeH3R YxwF1DJ5e2NH+7E5oTeuxamH8O2eOBDZXTyL2ZrFNJsr0wpPw4BeyQ9B/aV9Osjb ZiePIpnmVGSBf5h6b2KX9ILYc3lWfsCfNe3t2UwcLXlsACFM7sS1bXIWhpgb+gph CYkhuWckt9BLrIMRyN2QyT5CX25+/A/lol3olrsDdePsiG/f4Z+SNEk1CcWamb0Q dZr3xJhIDCa0GesX+aEnzNEmJG4ICyLV8OaaNP7XhMXatHOys+CW8WDsJVVUm3JM 1c8V18HSj5hfMv8VBoDExqQZ3sJZjdxku3r1WbYq6DHPu1f81rjOz6HlvAkJGcs2 ILJZp6dfzWY0mQ+V/0peJY1ehW52TNa+ZZaAzqk0RpRz+aP88RZpwWIuWFJHUWq6 p21DL0xHQSbH/6rC+QEwcBhSrpJObOVKFAR/4zunveHWLK5CKBF8tlSfkips36zt J/wPirrlSOO5anaKw7eKt56nRwJexeCGr5mxx4GiqDWaCVfqMZzfmR3HLqncKi9L HdY8dvlRuWTSQ/0C5abersl+0sehttAmmFTnu+n+OGJXLSdczmE7+55doxR4mQiP A6YLBN61UTFOTi8erB7J =cOTw -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From nobody Tue Jan 17 17:34:54 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF823129496 for ; Tue, 17 Jan 2017 17:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 QXZqrImFDQla for ; Tue, 17 Jan 2017 17:34:51 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 166A91293F0 for ; Tue, 17 Jan 2017 17:34:51 -0800 (PST) Received: from jurassic (unknown [115.118.62.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 89E092FA0021; Wed, 18 Jan 2017 01:34:49 +0000 (GMT) Date: Wed, 18 Jan 2017 07:04:46 +0530 From: Mukund Sivaraman To: Paul Hoffman Message-ID: <20170118013446.GA10581@jurassic> References: <20170117182229.73efff48@pallas.home.time-travellers.org> <20170117104727.GA28530@jurassic> <20170118012344.GA10453@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20170118012344.GA10453@jurassic> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:34:52 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 18, 2017 at 06:53:44AM +0530, Mukund Sivaraman wrote: > On Tue, Jan 17, 2017 at 07:54:45AM -0800, Paul Hoffman wrote: > > > On a side note, because any encryption will require a change to the D= NS > > > protocol (i.e., putting things into a crypto box which isn't backwards > > > compatible) IMO it would be worthwhile to consider revisiting the DNS > > > message format. > >=20 > > Shane was talking about wrapping the DNS traffic in TLS. This does not > > "require a change to the DNS protocol", as we have already seen in this= WG. >=20 > It does. It won't work on port 53 with an existing client. BTW, the email I sent wasn't exactly a follow-up to Shane's DNS over TLS for AXFR email. My mail was about the resolver -> auth communications. Maybe it was not clear from the original mail: when a different mechanism (port and related protocol change) is being introduced for encrypted traffic which current implementations cannot use without changes to them, it would be good to consider revisiting the DNS message format. The reasons for this have been given, and some of these are things we have recently had performance or filtering issues with with in the implementation I work on. After a point, no amount of tweaking the implementation is going to help an inferior format. Mukund --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYfsY1AAoJEB9EXrAiC5Lss80P/0ui72PH4/+IZ9PO4K3she+0 HeqdHjgoQxCO3iS3z127YoI8PTNS24vcSOJXvT6utcMKi/PTSCVfyU9DUUCBXOgz PZSoI1ntP7xDcFBPI4YEnbQf5bbqmRHT61pB7Mt8JJNVOjfwDfJvgi0VNFpAlSqy QVYxOu5P/kPB8gcFiMPilX3DHaFBnINn5zCcw1LBGI0xCgKygc4uKQj/eQ1+JO7A OYN56cTiklEU2NnY8L0mdbtjTy3lNKJUClIiaL8lvNCgZzYIJ7/11z4yPhFJYIWi RaYxiC8zl9OlTLtiIPJoBB/rPGB1Z4eZ/+Gq/GQbzAlTGCIwER8pNys5d3oWrhRy rpTWBl7mQUm9KSlFygtaezAlhqOmUk/BidYwdPeTw8j3ydQEwSsvAaVQsbro5YSE ydTz9QHukiGD9xMliRM2YGl2o23rh/PH6ygAnl3u9bVzUtxh7vhBQkCmeqiwecPP oe/jJZQ5EzL1RHdqFIOZa3z5a/+8EYIKi9j2wJqWTT2pN/xO7eCIMX9d0bxEZKcb l8KFrQycRphtnCX5iUqhD0AvI/vqmpZqXOD//rWEodUTcN0UzyXxDt6XEQtJb4Hm CyHGy8ENiQN8uYDDd/cgrBrj3mql5IFiNW+Jxmfi8S35e6jY8WSulWtgfbDSlpjE R7Ad3WuIp1kanQirSFIC =o3d2 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From nobody Tue Jan 17 18:26:04 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04691289B0 for ; Tue, 17 Jan 2017 18:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uxoG5Qc2Slbb for ; Tue, 17 Jan 2017 18:26:02 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3E129621 for ; Tue, 17 Jan 2017 18:26:01 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 5B1E3175E96 for ; Tue, 17 Jan 2017 18:26:00 -0800 (PST) Received: (qmail 679 invoked from network); 18 Jan 2017 02:25:59 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.201.128?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 18 Jan 2017 02:25:59 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= X-Mailer: iPhone Mail (14D27) In-Reply-To: <20170117182229.73efff48@pallas.home.time-travellers.org> Date: Tue, 17 Jan 2017 18:25:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170117182229.73efff48@pallas.home.time-travellers.org> To: Shane Kerr Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:26:03 -0000 > On Jan 17, 2017, at 02:22, Shane Kerr wrote: >=20 > Does this seem like something worth working on? I'd use it if it was available. Internally one can use any of many methods t= o add encryption (IPSec, stunnel, etc), but working with external parties it= 'd be very nice to have a standard method. There are many facets to security. Keeping zone data private does cover some= . I don't see why this would be tied to a new zone transfer mechanism or messa= ge format Ask= From nobody Tue Jan 17 18:49:12 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1983B12962D for ; Tue, 17 Jan 2017 18:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 P4EXqANwlpgL for ; Tue, 17 Jan 2017 18:49:10 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B33129619 for ; Tue, 17 Jan 2017 18:49:10 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 73C1D12C1045; Tue, 17 Jan 2017 21:49:09 -0500 (EST) Date: Tue, 17 Jan 2017 21:49:09 -0500 From: Robert Edmonds To: Mukund Sivaraman Message-ID: <20170118024909.2edowia27msswehw@mycre.ws> References: <20170117182229.73efff48@pallas.home.time-travellers.org> <20170117104727.GA28530@jurassic> <20170118012344.GA10453@jurassic> <20170118013446.GA10581@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170118013446.GA10581@jurassic> Archived-At: Cc: dns-privacy@ietf.org, Paul Hoffman Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:49:11 -0000 Mukund Sivaraman wrote: > Maybe it was not clear from the original mail: when a different > mechanism (port and related protocol change) is being introduced for > encrypted traffic which current implementations cannot use without > changes to them, it would be good to consider revisiting the DNS message > format. >From the DPRIVE charter: The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring (RFC 7258). … DPRIVE is chartered to work on mechanisms that add confidentiality to the DNS. While it may be tempting to solve other DNS issues while adding confidentiality, DPRIVE is not the working group to do this. DNS transactions are carried over DNS messages, and RFC 1035 §4 "MESSAGES" divides the message protocol into a "Format" (§4.1) and a "Transport" (§4.2). DPRIVE has introduced a new "Transport" backwards incompatible with existing clients (DNS-over-TLS), but it hasn't introduced any backwards incompatible changes to the message "Format". There have been backwards compatible changes, though (EDNS0 padding), using the existing DNS message format extension mechanism, in support of transaction confidentiality. If I understand correctly, you'd need to show that making backwards *in*compatible changes to the DNS message format are necessary to providing DNS transaction confidentiality. (Or re-charter.) > The reasons for this have been given, and some of these are > things we have recently had performance or filtering issues with with in > the implementation I work on. After a point, no amount of tweaking the > implementation is going to help an inferior format. What does poor message decoding performance from a particular implementation have to do with DNS transaction confidentiality? (There are DNS implementations that advertise high query rates with filtering, so I'm skeptical that backwards incompatible changes to the message format would deliver substantial speedups.) -- Robert Edmonds From nobody Tue Jan 17 19:17:43 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B91293E8 for ; Tue, 17 Jan 2017 19:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 7SyNDNz1_Ab3 for ; Tue, 17 Jan 2017 19:17:42 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id D12CD129438 for ; Tue, 17 Jan 2017 19:17:41 -0800 (PST) Received: from jurassic (unknown [115.118.62.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 12E172FA0021; Wed, 18 Jan 2017 03:17:38 +0000 (GMT) Date: Wed, 18 Jan 2017 08:47:35 +0530 From: Mukund Sivaraman To: Robert Edmonds Message-ID: <20170118031735.GA13976@jurassic> References: <20170117182229.73efff48@pallas.home.time-travellers.org> <20170117104727.GA28530@jurassic> <20170118012344.GA10453@jurassic> <20170118013446.GA10581@jurassic> <20170118024909.2edowia27msswehw@mycre.ws> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20170118024909.2edowia27msswehw@mycre.ws> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dns-privacy@ietf.org, Paul Hoffman Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:17:43 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'll not continue with the charter topic, because you're right that it's offtopic on a privacy list. However the point was made because it was an opportunity as a protocol change would be introduced when introducing encryption. On Tue, Jan 17, 2017 at 09:49:09PM -0500, Robert Edmonds wrote: > What does poor message decoding performance from a particular > implementation have to do with DNS transaction confidentiality? >=20 > (There are DNS implementations that advertise high query rates with > filtering, so I'm skeptical that backwards incompatible changes to the > message format would deliver substantial speedups.) No software implementations that I know of advertise link speed rates, even considering a single 10gbe link. The fastest I've come across is about 2.4 million QPS from a well-known commercial product. There's a higher overhead to parsing DNS messages and constructing DNS messages[1] than need be, especially when the service is hit with attack traffic. The points I'd listed are from real situations we've encountered. [1] Unlike for protocols such as HTTP that can serve pre-compressed resources, DNS name compression is performed on-the-fly during message rendering. It is a burden on implementations because efficient implementation of matching would require implementing it in assembly, something that a general purpose compression library can easily provide if it were not DNS specific. I don't think any high-level language implementation (C and above) can efficiently render something like a COM. delegation (which contains 29 RRs) without a hit on performance. Profile it and you'll see. If you argue that "DNS implementations .. advertise high query rates", they could be doing better. Mukund --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYft5OAAoJEB9EXrAiC5LsCi8P/iy0VlEbNcvxVOcgrKmQB8wh 5QOX1W1K8zmgWVRGm0puBaFyKQlhF3kUshtntHmU0y89gBxFNPdTdgEVLRwbw4vQ cPwU4PCWUBnUuq/SUj+cmWObGFEhUEtKA9lD3Of17CQk66gHO9uH1p7O6TGF59fg lfYgm9QVeEtTCgu//ayh02K0HRcJcllimhKHpFSKQ9VtzFlX7XsrYBzUSCO4th8T p626RQs4CBx1oVAPwcU3dAmBl4StyFKjwYe56Avu+AT0u3GYcBX8ohxPqJ5rRQbL AfElcQ8KlanLIPb2IP1QMEYfMfnp+B141an7Wpw1E0kipp75QorFT2/YpN7Spapt oE8V5R8Wpvbug1Y15+yQ6pzRWlyoTcY3FK//2t+IOUHCEyJ1oruMayuRqY+9WySn 2DDswbWwMfwYqg4H0cILohhCGgk6zMxXsPuts4z/UiuXIyGjnTcJBjq6YrnIYO3F ydIJTRxrylQS8Ib5gEdq9gbpNWTJMAPQkO1/EXDMEVLAHaiBZtJOMJ7QuhzUm9zd ABUX1OZOFv9bOTXNOZDW3QXR1r/PG9FNKWc+2yd1Cu0PE9i4pn1/T7ViDKQu1Ur+ VkGfr37eEb3VyubLk9BDSf+S5d8keUQYDT2YVomo0c+OBhtcdpkQkDIhZG/U7yN5 843olCWk+c55Ywbu7qtL =dN73 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From nobody Tue Jan 17 20:00:45 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FCC129671 for ; Tue, 17 Jan 2017 20:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 YuFDnFLvG6u0 for ; Tue, 17 Jan 2017 20:00:43 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7715F1294F9 for ; Tue, 17 Jan 2017 20:00:43 -0800 (PST) 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 v0I40ALm012733; Tue, 17 Jan 2017 20:00:11 -0800 (PST) Received: from dash.isi.edu (localhost6.localdomain6 [IPv6:::1]) by dash.isi.edu (Postfix) with ESMTP id 4663C2801AD; Tue, 17 Jan 2017 20:00:09 -0800 (PST) From: John Heidemann To: Shane Kerr In-reply-to: <20170117182229.73efff48@pallas.home.time-travellers.org> References: <20170117182229.73efff48@pallas.home.time-travellers.org> 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: Tue, 17 Jan 2017 20:00:09 -0800 Message-ID: <17839.1484712009@dash.isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: johnh@isi.edu Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] DNS over TLS for zone transfers? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 04:00:44 -0000 On Tue, 17 Jan 2017 18:22:29 +0800, Shane Kerr wrote: >Hello, > >I'm sorry if it has already been discussed, but has there been any work >done on using TLS for AXFR/IXFR? > >It seems like it should be relatively straightforward, compared to the >stub-to-resolver and resolver-to-authority links. While it does not >seem as big of a problem either, obviously somebody cares about hiding >the contents of zones or everybody wouldn't block zone transfers, >right? > >There are still some issues to consider, such as what the interaction of >TSIG and TLS certificates means, as well as what method a master can >use to signal TLS support (this seems desirable to me, although not >necessary). > >Does this seem like something worth working on? Or is it a distraction >from the resolver-to-authority work? That seems like a good idea. Wouldn't a straightforward signalling method be the same as rfc7858: use port 853? Is there some reason that wouldn't work? >Note also that it might be worthwhile building a new zone transfer >protocol that can perform better in areas where AXFR and IXFR don't >work well today (unnecessary data in IXFR of signed zones, inefficiency >for synchronizing lots of zones, automatic fallback to full zone >transfer on IXFR failure, and so on). That's not really something for >DPRIVE, of course, but adding TLS to the protocol could be rolled into >such an activity. A more modern prototocol may may not be a good idea, but if just using port 853 works, then the two should be decoupled. -John Heidemann From nobody Wed Jan 18 09:37:49 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 427D91294EF; Wed, 18 Jan 2017 09:37:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 09:37:39 -0800 Archived-At: Cc: dns-privacy@ietf.org Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:37:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS PRIVate Exchange of the IETF. Title : Authentication and (D)TLS Profile for DNS-over-(D)TLS Authors : Sara Dickinson Daniel Kahn Gillmor Tirumaleswar Reddy Filename : draft-ietf-dprive-dtls-and-tls-profiles-08.txt Pages : 26 Date : 2017-01-18 Abstract: This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). This document also specifies new authentication mechanisms - it describes several ways a DNS client can use an authentication domain name to authenticate a DNS server. Additionally, it defines (D)TLS profiles for DNS clients and servers implementing DNS-over-(D)TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 18 09:41:38 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338E31294E2 for ; Wed, 18 Jan 2017 09:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 BPE1QKKAC2cD for ; Wed, 18 Jan 2017 09:41:35 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C35E12943E for ; Wed, 18 Jan 2017 09:41:35 -0800 (PST) Received: from [2001:b98:204:102:fffa::9] (port=63136) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cTuEm-0006CB-Sy for dns-privacy@ietf.org; Wed, 18 Jan 2017 17:41:33 +0000 From: Sara Dickinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 18 Jan 2017 17:41:31 +0000 References: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> To: dns-privacy@ietf.org In-Reply-To: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> Message-Id: <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:41:37 -0000 Hi All,=20 Here is (finally) an updated draft with 2 main changes based on the = recent reviews: * Added a new section comparing all the Authentication Mechanisms * Removed hard failure as an option for Opportunistic Usage profile Regards Sara. > On 18 Jan 2017, at 17:37, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DNS PRIVate Exchange of the IETF. >=20 > Title : Authentication and (D)TLS Profile for = DNS-over-(D)TLS > Authors : Sara Dickinson > Daniel Kahn Gillmor > Tirumaleswar Reddy > Filename : draft-ietf-dprive-dtls-and-tls-profiles-08.txt > Pages : 26 > Date : 2017-01-18 >=20 > Abstract: > This document discusses Usage Profiles, based on one or more > authentication mechanisms, which can be used for DNS over Transport > Layer Security (TLS) or Datagram TLS (DTLS). This document also > specifies new authentication mechanisms - it describes several ways = a > DNS client can use an authentication domain name to authenticate a > DNS server. Additionally, it defines (D)TLS profiles for DNS = clients > and servers implementing DNS-over-(D)TLS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-08 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dprive-dtls-and-tls-profile= s-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Wed Jan 18 10:14:45 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53571294AC for ; Wed, 18 Jan 2017 10:14:43 -0800 (PST) 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 autolearn_force=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 s7nIYCzWLoWR for ; Wed, 18 Jan 2017 10:14:42 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD0712945E for ; Wed, 18 Jan 2017 10:14:42 -0800 (PST) Received: from [10.32.60.131] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v0IIDghF097515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jan 2017 11:13:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.131] From: "Paul Hoffman" To: "Sara Dickinson" Date: Wed, 18 Jan 2017 10:14:36 -0800 Message-ID: <2AD6F9DE-F6FE-41B2-8351-9D68C07F7780@vpnc.org> In-Reply-To: <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> References: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:14:44 -0000 Thanks! This version fixes the problem I brought up in WG Last Call, and I like the new table as well. --Paul Hoffman From nobody Fri Jan 20 10:46:35 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F19129C5F for ; Fri, 20 Jan 2017 10:46:33 -0800 (PST) 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 autolearn_force=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 EiRO24F_N4HQ for ; Fri, 20 Jan 2017 10:46:31 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 29A38129C5B for ; Fri, 20 Jan 2017 10:46:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 23022115B1 for ; Fri, 20 Jan 2017 18:46:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K55rPsW8kwyr for ; Fri, 20 Jan 2017 18:46:29 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 3B9CA10A0C for ; Fri, 20 Jan 2017 18:46:29 +0000 (UTC) Date: Fri, 20 Jan 2017 13:46:26 -0500 From: Andrew Sullivan To: dns-privacy@ietf.org Message-ID: <20170120184626.GE1699@mx2.yitter.info> References: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:46:33 -0000 Hi, Only two months late, I have managed at last to look at this. I think I may have an overcommit problem. Anyway, this document is totally ready to proceed and should do so as soon as possible. Good work. One tiny thing in the event the editors have another reason to open an editing window: the definition of "DNS server" wouldn't be hurt if the sentence, "For emphasis, in this document the term does not apply to authoritative servers," or something like that. The document in general is clear about this, but it's an unusual definition of "DNS server" even though I know we all use it that way when talking about "the recursive server" in any informal context. I do not think this is terribly important, but it might help a few people. Best regards, and apologies for my tardy review, A On Wed, Jan 18, 2017 at 05:41:31PM +0000, Sara Dickinson wrote: > Hi All, > > Here is (finally) an updated draft with 2 main changes based on the recent reviews: > > * Added a new section comparing all the Authentication Mechanisms > * Removed hard failure as an option for Opportunistic Usage profile > > Regards > > Sara. > > > On 18 Jan 2017, at 17:37, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the DNS PRIVate Exchange of the IETF. > > > > Title : Authentication and (D)TLS Profile for DNS-over-(D)TLS > > Authors : Sara Dickinson > > Daniel Kahn Gillmor > > Tirumaleswar Reddy > > Filename : draft-ietf-dprive-dtls-and-tls-profiles-08.txt > > Pages : 26 > > Date : 2017-01-18 > > > > Abstract: > > This document discusses Usage Profiles, based on one or more > > authentication mechanisms, which can be used for DNS over Transport > > Layer Security (TLS) or Datagram TLS (DTLS). This document also > > specifies new authentication mechanisms - it describes several ways a > > DNS client can use an authentication domain name to authenticate a > > DNS server. Additionally, it defines (D)TLS profiles for DNS clients > > and servers implementing DNS-over-(D)TLS. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-08 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > dns-privacy mailing list > > dns-privacy@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jan 20 15:29:57 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87211295A8 for ; Fri, 20 Jan 2017 15:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UbzEMwwHOEB for ; Fri, 20 Jan 2017 15:29:54 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444A9129593 for ; Fri, 20 Jan 2017 15:29:54 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id j126so5168546qkf.1 for ; Fri, 20 Jan 2017 15:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zk/A2DTmhpSovWEGXd2ZseWmeBAKJ8utAOjL1tVfNvg=; b=Bi/Or5g1v+37YtsX3bcEHkxkSMHAElQ8YAJhreDclvW39opr2XuZoPFl3SUzGDnoun 91yM6/oRUlrFhzrGT37ExGQspyorVjOp1lirq91SW5ou0tc6sSziMBgZzZZX6J8ReJgC fkTsoEo/qdnfLoiFibAIFDEHwEKqyXNSO5tOCMOMWPvJtngmsE1oYlTycEg6h/Wi1Znm P3/6JqBTkmw0MFh104cr6Jc6pZ3c0YqTtoBDmk2i6gPOXj99r6iB9zYfrq1Fmzq8WJIs 63sey9DQSF+ZNSZhP/EGnpBN3e/hWnm4z2nY3d/TRL3RGk0fJR8nrY7KfpDqlF8WOYVU f/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zk/A2DTmhpSovWEGXd2ZseWmeBAKJ8utAOjL1tVfNvg=; b=BqMxWbGSG16Z7VqoKG6hvkVtfZ1Or0rcL+G1CGuu4YKRFogrKXPC6dUEsYRjH6d48G Bbv741B2DLlCENeUS48ctUxXyA7q27sF4yYJMod0tEMoSO7/aMwIG4MkSNwmNO+V7+Xv RiR3u05hiHAcODIZr/Jvo+mJZAh9BzRossaC+YlYANI/BNyLkbC4/VJm9YTnzs03PGy+ +V0U5oabNBTYHZYTPW96hQLp4EOq79U+Wt3jQId9l7+y/UJTzikqkfsConL9QOd4mySv b2sr1eK4JNPsx1gKOn7+gFEAAU4dBCgj413qOGD+aUkw5ftikH1E5bk4cKp9/bmyuxZv s5WA== X-Gm-Message-State: AIkVDXK9vGvhI5xwelCOsi2b0CysCfh/dSmDGG/1q29IGMyvStbVy8oTcSHTpStpxRRe/qKQT6kabCFhinRCTGGW X-Received: by 10.237.38.65 with SMTP id z59mr14243205qtc.5.1484954992996; Fri, 20 Jan 2017 15:29:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Fri, 20 Jan 2017 15:29:22 -0800 (PST) In-Reply-To: <20170120184626.GE1699@mx2.yitter.info> References: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> <20170120184626.GE1699@mx2.yitter.info> From: Warren Kumari Date: Fri, 20 Jan 2017 18:29:22 -0500 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dns-privacy@ietf.org" Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 23:29:56 -0000 On Fri, Jan 20, 2017 at 1:46 PM, Andrew Sullivan wrote: > Hi, > > Only two months late, I have managed at last to look at this. I think > I may have an overcommit problem. > > Anyway, this document is totally ready to proceed and should do so as > soon as possible. Good work. > Thank you -- we believe that the most recent version captures all outstanding issues, and is done (and,. yes, like Paul mentioned, the table is useful). Huge thanks to the authors for working through all this, and integrating the changes / suggestions. I just realized that the datatracker still says "In WGLC" -- I'll go press the "Done" button. Tim is shepherding, but is a little swamped at the moment; he'll have the shepherd written up soon and then we toss it over the wall at the IESG. > One tiny thing in the event the editors have another reason to open an > editing window: the definition of "DNS server" wouldn't be hurt if the > sentence, "For emphasis, in this document the term does not apply to > authoritative servers," or something like that. The document in > general is clear about this, but it's an unusual definition of "DNS > server" even though I know we all use it that way when talking about > "the recursive server" in any informal context. I do not think this > is terribly important, but it might help a few people. This seems a minor enough change that the authors can incorporate during any requested IETF/IESG/RFC Editor edits.... Thank you for your comments. W > > Best regards, and apologies for my tardy review, > > A > > On Wed, Jan 18, 2017 at 05:41:31PM +0000, Sara Dickinson wrote: >> Hi All, >> >> Here is (finally) an updated draft with 2 main changes based on the recent reviews: >> >> * Added a new section comparing all the Authentication Mechanisms >> * Removed hard failure as an option for Opportunistic Usage profile >> >> Regards >> >> Sara. >> >> > On 18 Jan 2017, at 17:37, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts directories. >> > This draft is a work item of the DNS PRIVate Exchange of the IETF. >> > >> > Title : Authentication and (D)TLS Profile for DNS-over-(D)TLS >> > Authors : Sara Dickinson >> > Daniel Kahn Gillmor >> > Tirumaleswar Reddy >> > Filename : draft-ietf-dprive-dtls-and-tls-profiles-08.txt >> > Pages : 26 >> > Date : 2017-01-18 >> > >> > Abstract: >> > This document discusses Usage Profiles, based on one or more >> > authentication mechanisms, which can be used for DNS over Transport >> > Layer Security (TLS) or Datagram TLS (DTLS). This document also >> > specifies new authentication mechanisms - it describes several ways a >> > DNS client can use an authentication domain name to authenticate a >> > DNS server. Additionally, it defines (D)TLS profiles for DNS clients >> > and servers implementing DNS-over-(D)TLS. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-08 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-08 >> > >> > >> > Please note that it may take a couple of minutes from the time of submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > dns-privacy mailing list >> > dns-privacy@ietf.org >> > https://www.ietf.org/mailman/listinfo/dns-privacy >> >> _______________________________________________ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Jan 23 02:01:55 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8025129B11 for ; Mon, 23 Jan 2017 02:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 Alg-lYAAmXYZ for ; Mon, 23 Jan 2017 02:01:53 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20FE129B09 for ; Mon, 23 Jan 2017 02:01:53 -0800 (PST) Received: from [2001:b98:204:102:fffa::9] (port=57493) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cVbRe-0005YL-A7; Mon, 23 Jan 2017 10:01:51 +0000 From: Sara Dickinson Message-Id: <4CBF0B5E-F6DA-4D43-8EF1-6FAC1C64AFF8@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E99530D6-2BCD-4E8C-8BC0-8036D787B548" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 10:01:41 +0000 In-Reply-To: To: Warren Kumari References: <148476105926.1962.2088847069934887899.idtracker@ietfa.amsl.com> <8BE426BE-1A52-40A5-99CC-0FB7A8730A15@sinodun.com> <20170120184626.GE1699@mx2.yitter.info> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Cc: "dns-privacy@ietf.org" , Andrew Sullivan Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-08.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:01:54 -0000 --Apple-Mail=_E99530D6-2BCD-4E8C-8BC0-8036D787B548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2017, at 23:29, Warren Kumari wrote: >=20 > On Fri, Jan 20, 2017 at 1:46 PM, Andrew Sullivan = > wrote: >=20 >> One tiny thing in the event the editors have another reason to open = an >> editing window: the definition of "DNS server" wouldn't be hurt if = the >> sentence, "For emphasis, in this document the term does not apply to >> authoritative servers," or something like that. The document in >> general is clear about this, but it's an unusual definition of "DNS >> server" even though I know we all use it that way when talking about >> "the recursive server" in any informal context. I do not think this >> is terribly important, but it might help a few people. Many thanks for the review - I agree this is a good clarification.=20 >=20 > This seems a minor enough change that the authors can incorporate > during any requested IETF/IESG/RFC Editor edits.... I=E2=80=99ve updated the working document so that text will be in the = next revision. Thanks Sara.=20= --Apple-Mail=_E99530D6-2BCD-4E8C-8BC0-8036D787B548 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 20 Jan 2017, at 23:29, Warren Kumari <warren@kumari.net> = wrote:

On Fri, Jan 20, 2017 at 1:46 PM, Andrew Sullivan = <ajs@anvilwalrusden.com> = wrote:

One tiny thing in the event the editors have another reason = to open an
editing window: the definition of "DNS server" = wouldn't be hurt if the
sentence, "For emphasis, in this = document the term does not apply to
authoritative = servers," or something like that.  The document in
general is clear about this, but it's an unusual definition = of "DNS
server" even though I know we all use it that way = when talking about
"the recursive server" in any informal = context.  I do not think this
is terribly important, = but it might help a few people.

Many thanks for the review - I agree this is a good = clarification. 


This seems a minor enough change that the = authors can incorporate
during any requested IETF/IESG/RFC Editor = edits....

I=E2=80= =99ve updated the working document so that text will be in the next = revision.

Thanks

Sara. 
= --Apple-Mail=_E99530D6-2BCD-4E8C-8BC0-8036D787B548--