From nobody Mon Apr 10 09:29:32 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 D0DE7128C81; Mon, 10 Apr 2017 09:29:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149184176281.3111.16707682876344655100@ietfa.amsl.com> Date: Mon, 10 Apr 2017 09:29:22 -0700 Archived-At: Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-09.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:29:23 -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-09.txt Pages : 25 Date : 2017-04-10 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dtls-and-tls-profiles-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-09 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 Mon Apr 10 09:34:59 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 ABA39129A90 for ; Mon, 10 Apr 2017 09:34:58 -0700 (PDT) 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 WsvW2ipDbS-w for ; Mon, 10 Apr 2017 09:34:56 -0700 (PDT) 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 42F54128C81 for ; Mon, 10 Apr 2017 09:34:55 -0700 (PDT) Received: from [2001:b98:204:102:fffa::9] (port=55185) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cxcHF-0005pG-DW for dns-privacy@ietf.org; Mon, 10 Apr 2017 17:34:53 +0100 From: Sara Dickinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 17:34:51 +0100 References: <149184176281.3111.16707682876344655100@ietfa.amsl.com> To: dns-privacy@ietf.org In-Reply-To: <149184176281.3111.16707682876344655100@ietfa.amsl.com> Message-Id: <72CA583F-88DC-4240-9F08-CE18AF849BBA@sinodun.com> X-Mailer: Apple Mail (2.3273) 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-09.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:34:58 -0000 All,=20 There were a number hallway discussions at IETF around the use of SRV = records in this draft and in particular how the use of them in = combination with the TLS DNSSEC Chain Extension mechanism could be = improved e.g. to avoid having to separately validate the SRV, A/AAAA = lookups and the DNSSEC Chain records. After some debate it was eventually proposed to remove the SRV record = completely, which greatly simplifies the specification and streamlines = the above use case. A new version of the draft is available to review = which includes this change and also addresses the comments from the = TSV-ART review.=20 -09 Changelog: * Remove the SRV record to simplify the draft. * Add suggestion that clients offer DANE option to avoid using only PKIX = authentication. * Clarify that the MUST on implementing TLS session resumption updates = RFC7858. * Update page header to be '(D)TLS Authentication for TLS=E2=80=99. I=E2=80=99ll leave it to the chairs to comment on what this means = process wise for the draft at this stage. Regards Sara.=20 > On 10 Apr 2017, at 17:29, 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-09.txt > Pages : 25 > Date : 2017-04-10 >=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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 > = https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dtls-and-tls-profi= les-09 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dprive-dtls-and-tls-profile= s-09 >=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 Mon Apr 10 10:22:48 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 917CB12947E for ; Mon, 10 Apr 2017 10:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZytMquwNDMHi for ; Mon, 10 Apr 2017 10:22:45 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 E020412951C for ; Mon, 10 Apr 2017 10:22:44 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cxd1W-0002vE-W3 for dns-privacy@ietf.org; Mon, 10 Apr 2017 19:22:44 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cxd1R-00067d-RA for dns-privacy@ietf.org; Mon, 10 Apr 2017 13:22:42 -0400 Received: (qmail 14489 invoked from network); 10 Apr 2017 17:22:37 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Apr 2017 17:22:36 -0000 References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> To: "quic@ietf.org" , dns-privacy@ietf.org From: Christian Huitema X-Forwarded-Message-Id: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> Message-ID: Date: Mon, 10 Apr 2017 10:22:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> Content-Type: multipart/alternative; boundary="------------B344745BA762707BB596142A" X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoaZuMTo/Xs/YzkL90RwXaZRcOb18WfxGyg6Om6u4YYm4wySyrTKbH2WnwI act2Apo5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0D6H4iA+r VjizQnwVujXUZbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg8vcKVFCOOQYqP+ KhcSWOJOKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAzdvT3EZOBIWmsQFT+TVdxzLTor3tAVjkdK+O7DAI/GLAMS+4ayUpOtEhdxek WDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:22:47 -0000 This is a multi-part message in MIME format. --------------B344745BA762707BB596142A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FYI: Just published this draft describing transport of DNS over a dedicated QUIC connection. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.txt Date: Mon, 10 Apr 2017 09:45:37 -0700 From: internet-drafts@ietf.org To: Melinda Shore , Sara Dickinson , Christian Huitema , Allison Mankin , Janardhan Iyengar , Jana Iyengar A new version of I-D, draft-huitema-quic-dnsoquic-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-dnsoquic Revision: 00 Title: Specification of DNS over QUIC Document date: 2017-04-10 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00 Abstract: This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP. 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. The IETF Secretariat --------------B344745BA762707BB596142A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
FYI: Just published this draft describing transport of DNS over a dedicated QUIC connection.
-- Christian Huitema

-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.txt
Date: Mon, 10 Apr 2017 09:45:37 -0700
From: internet-drafts@ietf.org
To: Melinda Shore <mshore@fastly.com>, Sara Dickinson <sara@sinodun.com>, Christian Huitema <huitema@huitema.net>, Allison Mankin <amankin@salesforce.com>, Janardhan Iyengar <jri@google.com>, Jana Iyengar <jri@google.com> 


A new version of I-D, draft-huitema-quic-dnsoquic-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-dnsoquic
Revision:	00
Title:		Specification of DNS over QUIC
Document date:	2017-04-10
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00


Abstract:
   This document describes the use of QUIC to provide transport privacy
   for DNS.  The encryption provided by QUIC has similar properties to
   that provided by TLS, while QUIC transport eliminates the head-of-
   line blocking issues inherent with TCP and provides more efficient
   error corrections than UDP.  DNS over QUIC has privacy properties
   similar to DNS over TLS specified in RFC7858, and performance similar
   to classic DNS over UDP.

                                                                                  


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.

The IETF Secretariat
--------------B344745BA762707BB596142A-- From nobody Mon Apr 10 11:04:30 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 DEA0A129A91 for ; Mon, 10 Apr 2017 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 O1ZNAX_axeiU for ; Mon, 10 Apr 2017 11:04:27 -0700 (PDT) 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 E9DFC129A9D for ; Mon, 10 Apr 2017 11:04:24 -0700 (PDT) Received: from [169.254.150.39] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3AI483r029891 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 10 Apr 2017 11:04:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.150.39] From: "Paul Hoffman" To: dns-privacy@ietf.org Date: Mon, 10 Apr 2017 11:04:22 -0700 Message-ID: <7516B4DE-AE9F-49DF-94AA-BBF73A670A5F@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [dns-privacy] Additional drafts for protecting DNS traffic X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 18:04:29 -0000 Related to Christian's recent announcement of draft-huitema-quic-dnsoquic, here are two more drafts that also are of interest to DPRIVE. The drafts have different use cases. The solutions spaces for the use cases are different (reusing an existing connection instead of starting a new one). We think that both might be of interest to the IETF given that both should help make DNS traffic private. --Paul Hoffman Name: draft-hoffman-dns-in-existing-quic Revision: 00 Title: Running DNS in Existing QUIC Connections Document date: 2017-04-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-existing-quic-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-quic/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-existing-quic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dns-in-existing-quic-00 Abstract: Intermediaries such as governments and ISPs spoof DNS responses, and block DNS requests to particular recursive resolvers, for a variety of reasons. They spoof by capturing traffic on port 53, or by redirecting port 853 traffic in the hopes that the client is using opportunistic encryption. They block if they know the address of a resolver that they don't like, such as public resolvers that give honest answers. This document describes how to run DNS service over existing QUIC connections, such as those being used for HTTP for basic web service. This design prevents intermediaries from spoofing DNS responses, and makes it impossible for intermediaries to block the use of those recursive resolvers without blocking the desired HTTP connections. It also prevents intermediaries or passive observers from seeing the DNS traffic. This design is meant for communication between a DNS stub resolver and a DNS recursive resolver. A new version of I-D, draft-hoffman-dns-in-existing-http2-00.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository. Name: draft-hoffman-dns-in-existing-http2 Revision: 00 Title: Running DNS in Existing HTTP/2 Connections Document date: 2017-04-10 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-existing-http2-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-http2/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-existing-http2-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dns-in-existing-http2-00 Abstract: Intermediaries such as governments and ISPs spoof DNS responses, and block DNS requests to particular recursive resolvers, for a variety of reasons. They spoof by capturing traffic on port 53, or by redirecting port 853 traffic in the hopes that the client is using opportunistic encryption. They block if they know the address of a resolver that they don't like, such as public resolvers that give honest answers. This document describes how to run DNS service over existing HTTP/2 connections over TLS, such as those being used for HTTP for basic web service. This design prevents intermediaries from spoofing DNS responses, and makes it impossible for intermediaries to block the use of those recursive resolvers without blocking the desired HTTP connections. It also prevents intermediaries or passive observers from seeing the DNS traffic. This design is meant for communication between a DNS stub resolver and a DNS recursive resolver. From nobody Mon Apr 10 13:18:46 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 18BF4126D73; Mon, 10 Apr 2017 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 hJT2CCf-CMKB; Mon, 10 Apr 2017 13:18:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18407124234; Mon, 10 Apr 2017 13:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F800BE73; Mon, 10 Apr 2017 21:18:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7ooQiCmiFML; Mon, 10 Apr 2017 21:18:29 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 70995BE5B; Mon, 10 Apr 2017 21:18:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1491855506; bh=VOLdDCdIv0qUku8v1KuWuOaPOLMHJ0HfIt5B2Th/TI0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gotk0OzE+M5GVy2tVea1kwPaA3H6nLop2h4RzL4EsWgrTwR3qeVnO2wlaTjGLizXH hGqunRU2p4GJcRCYrS8iv0Du2MHrzTMHi1fbyvWB8Tqh3KTi0KGLCrYZ2ycxCgUo3C gQXIw0A0+ReCSsQi7gW4HWQpJopun67IUJki5Bdw= To: Christian Huitema , "quic@ietf.org" , dns-privacy@ietf.org References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9c04d3fc-dc76-cbdc-32a2-618289e91254@cs.tcd.ie> Date: Mon, 10 Apr 2017 21:18:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs" Archived-At: Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:18:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs Content-Type: multipart/mixed; boundary="NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , "quic@ietf.org" , dns-privacy@ietf.org Message-ID: <9c04d3fc-dc76-cbdc-32a2-618289e91254@cs.tcd.ie> Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: --NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great to see this. I hope it gets traction and am willing to read comment etc if this gets adopted somewhere. Cheers, S. On 10/04/17 18:22, Christian Huitema wrote: >=20 > FYI: Just published this draft describing transport of DNS over a > dedicated QUIC connection. > -- Christian Huitema >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-quic-dnsoquic-00.t= xt > Date: Mon, 10 Apr 2017 09:45:37 -0700 > From: internet-drafts@ietf.org > To: Melinda Shore , Sara Dickinson > , Christian Huitema , Allison > Mankin , Janardhan Iyengar , > Jana Iyengar >=20 >=20 >=20 > A new version of I-D, draft-huitema-quic-dnsoquic-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. >=20 > Name: draft-huitema-quic-dnsoquic > Revision: 00 > Title: Specification of DNS over QUIC > Document date: 2017-04-10 > Group: Individual Submission > Pages: 18 > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic= -dnsoquic-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dns= oquic/ > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic= -00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-qui= c-dnsoquic-00 >=20 >=20 > Abstract: > This document describes the use of QUIC to provide transport privacy= > for DNS. The encryption provided by QUIC has similar properties to > that provided by TLS, while QUIC transport eliminates the head-of- > line blocking issues inherent with TCP and provides more efficient > error corrections than UDP. DNS over QUIC has privacy properties > similar to DNS over TLS specified in RFC7858, and performance simila= r > to classic DNS over UDP. >=20 > = =20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >=20 --NIMkHQBeRQrtkR06hAAxmlRDKPDKS203U-- --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY6+iQAAoJEC88hzaAX42iNR8H/2lIMXxPCfZz4wdUjvOr2KER wI7ck0L9IRMDe8930tNtH7xU2cFfAjmqzWNMQFInwrFakX2TPbJWLzC8L/AStPIU Xc7SD+9NA7x4adoQIhq8x4/PXJcMOTiSgWz60S9yXG9ZTMWZ0hBE0ewabMN/2uFG mRyZGW2epF/d++HabcuUbmj/lcxYjpTe13POQSv6XwRBPcfwTt/JrgLIAiRRvQKI 9EHNjmg5AzOCY8amExyclza+Y58V6o4m0BJR4LO0N0FLZeeYA+kvhPPxBtdAkEYz wCIzKzyH/FIzL1myQkyLlRFQqIg4MotI8p5LZ8vWYL9b0GoYxvpSaYfam6jGthk= =d+fq -----END PGP SIGNATURE----- --FXpiClvO6FDcdO81AeOiLgP8XIAVlcWFs-- From nobody Mon Apr 10 23:43:34 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 BFE341287A3; Mon, 10 Apr 2017 23:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.889 X-Spam-Level: X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 Umrf5BCdN7ij; Mon, 10 Apr 2017 23:43:29 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 EBCE0128B8D; Mon, 10 Apr 2017 23:43:27 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.52f ; Tue, 11 Apr 2017 08:43:21 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 08:43:20 +0200 From: Alexander Mayrhofer To: Christian Huitema , "quic@ietf.org" , "dns-privacy@ietf.org" Thread-Index: AQHSsh8cNI/htzqFBkW5pWYvd2Daa6G/thFg Date: Tue, 11 Apr 2017 06:43:19 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.13] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_" MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 06:43:33 -0000 --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hyaXN0aWFuLA0KDQpncmVhdCB0byBzZWUgdGhpcyDigJMgaSByZW1lbWJlciB3aGVu IGkgbWVudGlvbmVkIFFVSUMgYXMgYW4gb3B0aW9uIGR1cmluZyB0aGUgRE5TLW92ZXItSFRUUCBC YXIgQm9GIGluIFNlb3VsIGkgZ290IHF1aXRlIGEgZmV3IHdlaXJkIGxvb2tzIDopLiBJIGxpa2Ug dGhpcy4gSXQgbG9va3MgbGlrZSBhIGxvZ2ljYWwgY2hvaWNlIHNvbWV3aGVyZSDigJ5iZXR3ZWVu 4oCcIFRMUyBhbmQgRFRMUy4NCg0KSSBoYXZlIHNvbWUgYmFja2dyb3VuZCBvbiBTZWN0aW9uIDYu NSAoUGFkZGluZykg4oCTIGJhY2sgd2hlbiB3ZSBzcGVjaWZpZWQgRE5TIG92ZXIgVExTLCB3ZSBo YWQgYSBzaW1pbGFyIGRpc2N1c3Npb24gd2hldGhlciB0byBwYWQgb24gdGhlIEROUyBvciB0aGUg dHJhbnNwb3J0IChUTFMsIGluIHRoYXQgY2FzZSkgbGF5ZXIuIFdlIGRlY2lkZWQgaW4gdGhhdCBj YXNlIHRoYXQgcGFkZGluZyBvbiB0aGUgRE5TIGxheWVyIGlzIHByZWZlcnJlZCwgc2luY2UgaXQg YWxsb3dzIGZvciBncmVhdGVyIGNvbnRyb2wgYnkgdGhlIGFwcGxpY2F0aW9uLiBUaGlzIHdhcyBh Y3R1YWxseSB0aGUgcmVhc29uIFJGQyA3ODMwIHdhcyBjcmVhdGVkIGluIHRoZSBmaXJzdCBwbGFj ZS4NCg0KVGhlIHNpdHVhdGlvbiBtaWdodCBiZSBkaWZmZXJlbnQgZm9yIFFVSUMgYXMgdGhlcmXi gJlzIGEgdGlnaHRlciBjb3VwbGluZyBiZXR3ZWVuIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24s IHRob3VnaCBwYWRkaW5nIG9uIHRoZSBETlMgbGF5ZXIgd291bGQgYWxsb3cgcmUtdXNpbmcgdGhl IG9uZ29pbmcgcmVzZWFyY2ggYW5kIHNwZWNpZmljYXRpb24gd29yayBpbiBEUFJJVkUuIChEaXNj bGFpbWVyOiBJIGtub3cgbGl0dGxlIGFib3V0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHN1Y2ggcmVz ZWFyY2ggZm9yIFFVSUMpLg0KDQpiZXN0LA0KQWxleA0KDQpWb246IGRucy1wcml2YWN5IFttYWls dG86ZG5zLXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQ2hyaXN0aWFu IEh1aXRlbWENCkdlc2VuZGV0OiBNb250YWcsIDEwLiBBcHJpbCAyMDE3IDE5OjIzDQpBbjogcXVp Y0BpZXRmLm9yZzsgZG5zLXByaXZhY3lAaWV0Zi5vcmcNCkJldHJlZmY6IFtkbnMtcHJpdmFjeV0g RndkOiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVpdGVtYS1xdWlj LWRuc29xdWljLTAwLnR4dCBbeF9waGlzaGluZ10NCg0KDQpGWUk6IEp1c3QgcHVibGlzaGVkIHRo aXMgZHJhZnQgZGVzY3JpYmluZyB0cmFuc3BvcnQgb2YgRE5TIG92ZXIgYSBkZWRpY2F0ZWQgUVVJ QyBjb25uZWN0aW9uLg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KLS0tLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dA0KDQpEYXRlOg0KDQpNb24sIDEw IEFwciAyMDE3IDA5OjQ1OjM3IC0wNzAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KTWVsaW5kYSBT aG9yZSA8bXNob3JlQGZhc3RseS5jb20+PG1haWx0bzptc2hvcmVAZmFzdGx5LmNvbT4sIFNhcmEg RGlja2luc29uIDxzYXJhQHNpbm9kdW4uY29tPjxtYWlsdG86c2FyYUBzaW5vZHVuLmNvbT4sIENo cmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjxtYWlsdG86aHVpdGVtYUBodWl0 ZW1hLm5ldD4sIEFsbGlzb24gTWFua2luIDxhbWFua2luQHNhbGVzZm9yY2UuY29tPjxtYWlsdG86 YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbT4sIEphbmFyZGhhbiBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNv bT48bWFpbHRvOmpyaUBnb29nbGUuY29tPiwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT48 bWFpbHRvOmpyaUBnb29nbGUuY29tPg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBDaHJpc3RpYW4gSHVpdGVtYSBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRGIHJl cG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgIGRyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVp Yw0KDQpSZXZpc2lvbjogICAgIDAwDQoNClRpdGxlOiAgICAgICAgU3BlY2lmaWNhdGlvbiBvZiBE TlMgb3ZlciBRVUlDDQoNCkRvY3VtZW50IGRhdGU6IDIwMTctMDQtMTANCg0KR3JvdXA6ICAgICAg ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAxOA0KDQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEt cXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy8NCg0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWl0ZW1hLXF1aWMtZG5z b3F1aWMtMDANCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwDQoNCg0KDQoNCg0KQWJzdHJh Y3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgUVVJQyB0byBwcm92 aWRlIHRyYW5zcG9ydCBwcml2YWN5DQoNCiAgIGZvciBETlMuICBUaGUgZW5jcnlwdGlvbiBwcm92 aWRlZCBieSBRVUlDIGhhcyBzaW1pbGFyIHByb3BlcnRpZXMgdG8NCg0KICAgdGhhdCBwcm92aWRl ZCBieSBUTFMsIHdoaWxlIFFVSUMgdHJhbnNwb3J0IGVsaW1pbmF0ZXMgdGhlIGhlYWQtb2YtDQoN CiAgIGxpbmUgYmxvY2tpbmcgaXNzdWVzIGluaGVyZW50IHdpdGggVENQIGFuZCBwcm92aWRlcyBt b3JlIGVmZmljaWVudA0KDQogICBlcnJvciBjb3JyZWN0aW9ucyB0aGFuIFVEUC4gIEROUyBvdmVy IFFVSUMgaGFzIHByaXZhY3kgcHJvcGVydGllcw0KDQogICBzaW1pbGFyIHRvIEROUyBvdmVyIFRM UyBzcGVjaWZpZWQgaW4gUkZDNzg1OCwgYW5kIHBlcmZvcm1hbmNlIHNpbWlsYXINCg0KICAgdG8g Y2xhc3NpYyBETlMgb3ZlciBVRFAuDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkUtTWFpbEZvcm1h dHZvcmxhZ2UyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJERSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhlbGxvIENocmlzdGlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPmdyZWF0IHRvIHNlZSB0aGlzIOKAkyBpIHJlbWVtYmVyIHdoZW4g aSBtZW50aW9uZWQgUVVJQyBhcyBhbiBvcHRpb24gZHVyaW5nIHRoZSBETlMtb3Zlci1IVFRQIEJh ciBCb0YgaW4gU2VvdWwgaSBnb3QgcXVpdGUgYSBmZXcgd2VpcmQNCiBsb29rcyA6KS4gSSBsaWtl IHRoaXMuIEl0IGxvb2tzIGxpa2UgYSBsb2dpY2FsIGNob2ljZSBzb21ld2hlcmUg4oCeYmV0d2Vl buKAnCBUTFMgYW5kIERUTFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JIGhhdmUgc29tZSBiYWNrZ3JvdW5kIG9uIFNlY3Rpb24gNi41IChQYWRkaW5nKSDigJMgYmFj ayB3aGVuIHdlIHNwZWNpZmllZCBETlMgb3ZlciBUTFMsIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vz c2lvbiB3aGV0aGVyIHRvIHBhZCBvbg0KIHRoZSBETlMgb3IgdGhlIHRyYW5zcG9ydCAoVExTLCBp biB0aGF0IGNhc2UpIGxheWVyLiBXZSBkZWNpZGVkIGluIHRoYXQgY2FzZSB0aGF0IHBhZGRpbmcg b24gdGhlIEROUyBsYXllciBpcyBwcmVmZXJyZWQsIHNpbmNlIGl0IGFsbG93cyBmb3IgZ3JlYXRl ciBjb250cm9sIGJ5IHRoZSBhcHBsaWNhdGlvbi4gVGhpcyB3YXMgYWN0dWFsbHkgdGhlIHJlYXNv biBSRkMgNzgzMCB3YXMgY3JlYXRlZCBpbiB0aGUgZmlyc3QgcGxhY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgc2l0dWF0aW9uIG1pZ2h0IGJlIGRpZmZlcmVu dCBmb3IgUVVJQyBhcyB0aGVyZeKAmXMgYSB0aWdodGVyIGNvdXBsaW5nIGJldHdlZW4gdHJhbnNw b3J0IGFuZCBhcHBsaWNhdGlvbiwgdGhvdWdoIHBhZGRpbmcgb24gdGhlIEROUw0KIGxheWVyIHdv dWxkIGFsbG93IHJlLXVzaW5nIHRoZSBvbmdvaW5nIHJlc2VhcmNoIGFuZCBzcGVjaWZpY2F0aW9u IHdvcmsgaW4gRFBSSVZFLiAoRGlzY2xhaW1lcjogSSBrbm93IGxpdHRsZSBhYm91dCB0aGUgY3Vy cmVudCBzdGF0ZSBvZiBzdWNoIHJlc2VhcmNoIGZvciBRVUlDKS4NCjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+YmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5BbGV4PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Wb246PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IGRucy1wcml2YWN5IFttYWlsdG86ZG5z LXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZ10NCjxiPkltIEF1ZnRyYWcgdm9uIDwvYj5DaHJpc3Rp YW4gSHVpdGVtYTxicj4NCjxiPkdlc2VuZGV0OjwvYj4gTW9udGFnLCAxMC4gQXByaWwgMjAxNyAx OToyMzxicj4NCjxiPkFuOjwvYj4gcXVpY0BpZXRmLm9yZzsgZG5zLXByaXZhY3lAaWV0Zi5vcmc8 YnI+DQo8Yj5CZXRyZWZmOjwvYj4gW2Rucy1wcml2YWN5XSBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0IFt4X3Bo aXNoaW5nXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSTogSnVz dCBwdWJsaXNoZWQgdGhpcyBkcmFmdCBkZXNjcmliaW5nIHRyYW5zcG9ydCBvZiBETlMgb3ZlciBh IGRlZGljYXRlZCBRVUlDIGNvbm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxicj4NCi0tLS0tLS0t IEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9 IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdo dCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9vOnA+PC9iPjwv cD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVpdGVtYS1x dWljLWRuc29xdWljLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpy aWdodCI+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9uLCAxMCBBcHIg MjAxNyAwOTo0NTozNyAtMDcwMDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpy aWdodCI+PGI+RnJvbTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDxvOnA+ PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lbGluZGEgU2hvcmUgPGEgaHJlZj0ibWFpbHRvOm1z aG9yZUBmYXN0bHkuY29tIj4mbHQ7bXNob3JlQGZhc3RseS5jb20mZ3Q7PC9hPiwgU2FyYSBEaWNr aW5zb24NCjxhIGhyZWY9Im1haWx0bzpzYXJhQHNpbm9kdW4uY29tIj4mbHQ7c2FyYUBzaW5vZHVu LmNvbSZndDs8L2E+LCBDaHJpc3RpYW4gSHVpdGVtYSA8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBo dWl0ZW1hLm5ldCI+DQombHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8L2E+LCBBbGxpc29uIE1h bmtpbiA8YSBocmVmPSJtYWlsdG86YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbSI+DQombHQ7YW1hbmtp bkBzYWxlc2ZvcmNlLmNvbSZndDs8L2E+LCBKYW5hcmRoYW4gSXllbmdhciA8YSBocmVmPSJtYWls dG86anJpQGdvb2dsZS5jb20iPiZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8L2E+LCBKYW5hIEl5ZW5n YXINCjxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+Jmx0O2pyaUBnb29nbGUuY29tJmd0 OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHByZT5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVpdGVtYS1x dWljLWRuc29xdWljLTAwLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hyaXN0aWFuIEh1aXRlbWEgYW5kIHBvc3RlZCB0byB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmFtZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljPG86cD48L286cD48L3ByZT4NCjxwcmU+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDAwPG86cD48L286cD48L3ByZT4NCjxwcmU+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNwZWNpZmljYXRpb24gb2YgRE5TIG92ZXIgUVVJQzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkRvY3VtZW50IGRhdGU6IDIwMTctMDQtMTA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+UGFnZXM6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4PG86cD48L286cD48L3By ZT4NCjxwcmU+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0w MC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMvPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVp dGVtYS1xdWljLWRuc29xdWljLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aHVpdGVtYS1xdWljLWRuc29xdWljLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxp emVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVp Yy0wMCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1odWl0ZW1h LXF1aWMtZG5zb3F1aWMtMDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSB1c2Ugb2YgUVVJQyB0byBwcm92aWRlIHRyYW5zcG9ydCBwcml2YWN5PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZvciBETlMuJm5ic3A7IFRoZSBlbmNyeXB0aW9u IHByb3ZpZGVkIGJ5IFFVSUMgaGFzIHNpbWlsYXIgcHJvcGVydGllcyB0bzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGF0IHByb3ZpZGVkIGJ5IFRMUywgd2hpbGUgUVVJQyB0 cmFuc3BvcnQgZWxpbWluYXRlcyB0aGUgaGVhZC1vZi08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgbGluZSBibG9ja2luZyBpc3N1ZXMgaW5oZXJlbnQgd2l0aCBUQ1AgYW5kIHBy b3ZpZGVzIG1vcmUgZWZmaWNpZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGVycm9yIGNvcnJlY3Rpb25zIHRoYW4gVURQLiZuYnNwOyBETlMgb3ZlciBRVUlDIGhhcyBwcml2 YWN5IHByb3BlcnRpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2ltaWxh ciB0byBETlMgb3ZlciBUTFMgc3BlY2lmaWVkIGluIFJGQzc4NTgsIGFuZCBwZXJmb3JtYW5jZSBz aW1pbGFyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRvIGNsYXNzaWMgRE5T IG92ZXIgVURQLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+dW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_19F54F2956911544A32543B8A9BDE07598F48DC7NICSEXCH2sbgnic_-- From nobody Tue Apr 11 04:28:50 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 71E1412944A for ; Tue, 11 Apr 2017 04:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 PIS0JGC3YMi1 for ; Tue, 11 Apr 2017 04:28:46 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568B1129444 for ; Tue, 11 Apr 2017 04:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=Uv8jX1vt0iUoAeQyCYmM9LV7Vj/OV8TWFw1wTeAcEi8=; b=Wq2AsEyTseUJNYHSmsyucOulC4hBvOzKEKxIQCFCYT7TGmRSaeCgyoUsO+z3FBHKYmF1mkAmciK0WtoqU97/mbaFqg/XrNEMQSBc8kzBHYVvfpbmw5ZBQQ/cC4c32dJNZK/+/Y4d2oyqUc0C6PDRhy3CF9aGIhTHgj0HhDn9XxR+CxQ9vTpe980g9vl/GAbA45p2FFdNP55t59NE0MJE8gCg4l7Qz/w78kunM3/P+9T2cSZnX4O4swGCAvQA6bMeYeNb8MSD+Cn4XzCgwxKkvHwTdAg7IXOmqRXFHI23qh/pUsTvTyeNAqoZBYe50DtLXkUTSbC6g9uihcxnv4Z5cw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id v3BBSi9V001892-v3BBSi9X001892 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Tue, 11 Apr 2017 13:28:44 +0200 Received: from MAC-01-09.local (94.198.159.155) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 11 Apr 2017 13:28:44 +0200 To: References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> From: "Marco Davids (IETF IMAP)" Message-ID: <40838cb2-347e-f852-4304-315473057f5a@sidn.nl> Date: Tue, 11 Apr 2017 13:28:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.155] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.155, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.155 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:28:48 -0000 On 4/10/17 7:22 PM, Christian Huitema wrote: > > FYI: Just published this draft describing transport of DNS over a > dedicated QUIC connection. > I like it. I see why port 953 was chosen. But it is also a longtime de facto default for the rndc communications channel of BIND. -- Marco From nobody Tue Apr 11 04:33:41 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 8DC7C129444 for ; Tue, 11 Apr 2017 04:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 NhRuk1q6aI7p for ; Tue, 11 Apr 2017 04:33:38 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F2A126C25 for ; Tue, 11 Apr 2017 04:33:38 -0700 (PDT) Received: from [46.227.151.81] (port=50806 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cxu3D-0000Ef-8M (Exim 4.72) for dns-privacy@ietf.org (return-path ); Tue, 11 Apr 2017 12:33:35 +0100 To: dns-privacy@ietf.org References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> <40838cb2-347e-f852-4304-315473057f5a@sidn.nl> From: Ray Bellis Message-ID: Date: Tue, 11 Apr 2017 12:33:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <40838cb2-347e-f852-4304-315473057f5a@sidn.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:33:40 -0000 On 11/04/2017 12:28, Marco Davids (IETF IMAP) wrote: > I see why port 953 was chosen. But it is also a longtime de facto > default for the rndc communications channel of BIND. Yes, it is. I am trying to make that formal rather than de facto with IANA at the moment. Ray From nobody Tue Apr 11 10:52:30 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 ABEF512EB6D for ; Tue, 11 Apr 2017 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 MqJjPp-5CcoE for ; Tue, 11 Apr 2017 10:52:12 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 9D84312EB6E for ; Tue, 11 Apr 2017 10:52:01 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1cxzxK-00085d-Um for dns-privacy@ietf.org; Tue, 11 Apr 2017 19:51:59 +0200 Received: from internal.xmail04.myhosting.com ([10.5.2.14] helo=xmail04.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cxzxH-00005C-9P for dns-privacy@ietf.org; Tue, 11 Apr 2017 13:51:52 -0400 Received: (qmail 20926 invoked from network); 11 Apr 2017 17:51:50 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.160]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2017 17:51:49 -0000 To: Alexander Mayrhofer , "quic@ietf.org" , "dns-privacy@ietf.org" References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> From: Christian Huitema Message-ID: <39db2dc5-bc88-4d65-afff-bacc97402fb9@huitema.net> Date: Tue, 11 Apr 2017 10:51:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <19F54F2956911544A32543B8A9BDE07598F48DC7@NICS-EXCH2.sbg.nic.at> Content-Type: multipart/alternative; boundary="------------D776AC8F48E84B34AD3A6136" X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.32) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpYUUAfN/uHlsKUvyareoJVRcOb18WfxGyg6Om6u4YYm6YbEHJjOwFnlwY7 4BqyDH85hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0ZLDOn82b cl2hf/mZzuAjP7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oax12d5xFluaUpdcIw0lU4eCXo/JDSYH6njpM EWxyzAPnxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6TTOn8sE7YQgPmIwOMrYG7J2iKbNGCUng3Y2EXketiO X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 17:52:15 -0000 This is a multi-part message in MIME format. --------------D776AC8F48E84B34AD3A6136 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote: > > Hello Christian, > > =20 > > great to see this =E2=80=93 i remember when i mentioned QUIC as an opti= on > during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird > looks :). I like this. It looks like a logical choice somewhere > =E2=80=9Ebetween=E2=80=9C TLS and DTLS. > > =20 > > I have some background on Section 6.5 (Padding) =E2=80=93 back when we > specified DNS over TLS, we had a similar discussion whether to pad on > the DNS or the transport (TLS, in that case) layer. We decided in that > case that padding on the DNS layer is preferred, since it allows for > greater control by the application. This was actually the reason RFC > 7830 was created in the first place. > > =20 > > The situation might be different for QUIC as there=E2=80=99s a tighter > coupling between transport and application, though padding on the DNS > layer would allow re-using the ongoing research and specification work > in DPRIVE. (Disclaimer: I know little about the current state of such > research for QUIC). > > =20 > The situation is different in QUIC, because a single QUIC packet may carry several DNS packets, using separate STREAM-DATA frames to carry the content of different streams. Of course, the DNS application does not know whether the QUIC transport will in fact pack data from several streams in a single packet, so what we need here is some kind of API contract. The efficient solution would be to instruct the transport to perform a particular padding strategy, similar to the padding strategies developed for DNS. This would cover many applications, not just DNS. Failing that, padding at the DNS layer has the advantage of being easy to implement. -- Christian Huitema --------------D776AC8F48E84B34AD3A6136 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote:

Hello Christian,

 

great to see this – i remember when i mentioned QUIC as an option during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird looks :). I like this. It looks like a logical choice somewhere „between“ TLS and DTLS.

 

I have some background on Section 6.5 (Padding) – back when we specified DNS over TLS, we had a similar discussion whether to pad on the DNS or the transport (TLS, in that case) layer. We decided in that case that padding on the DNS layer is preferred, since it allows for greater control by the application. This was actually the reason RFC 7830 was created in the first place.

 

The situation might be different for QUIC as there’s a tighter coupling between transport and application, though padding on the DNS layer would allow re-using the ongoing research and specification work in DPRIVE. (Disclaimer: I know little about the current state of such research for QUIC).

 

The situation is different in QUIC, because a single QUIC packet may carry several DNS packets, using separate STREAM-DATA frames to carry the content of different streams. Of course, the DNS application does not know whether the QUIC transport will in fact pack data from several streams in a single packet, so what we need here is some kind of API contract.

The efficient solution would be to instruct the transport to perform a particular padding strategy, similar to the padding strategies developed for DNS. This would cover many applications, not just DNS. Failing that, padding at the DNS layer has the advantage of being easy to implement.

-- Christian Huitema
--------------D776AC8F48E84B34AD3A6136-- From nobody Tue Apr 11 11:39: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 9774812EBFF; Tue, 11 Apr 2017 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 9CMT48ObGhKN; Tue, 11 Apr 2017 11:39:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC62A12EC0A; Tue, 11 Apr 2017 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wp4IyPCfB3nzTk2HxI8QMxpc3/LAqybgADDs1JHDQpI=; b=QSBCphzt5Ky2rjiNj/LSdbXGywmY4RVi2NRwX3IrxKpH77Hwsq9wuzRo5tBRZdpys3zp7mgQxyWsmKA+TFmKSpeGA+cfNgrp45org4Vv6IvrQPJj7XI+lZJcLLrT8puQGmit7Z1z864M0uzKAZbtMXyWf6DPw+mdsGjvTZtaqpc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Tue, 11 Apr 2017 18:39:36 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1019.025; Tue, 11 Apr 2017 18:39:36 +0000 From: Mike Bishop To: huitema , "quic@ietf.org" , "dns-privacy@ietf.org" Thread-Topic: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt Thread-Index: AQHSsh8Zi+JVfi/DOEOY9pX/8e8kBKHAfzMA Date: Tue, 11 Apr 2017 18:39:36 +0000 Message-ID: References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:AjVtyhmG4GMJpDFGRD4RDxtRiM84FDJz/2O6ScDNFWx2/fPIERrcctuJZQskjXv/xPeKGMQ6cE1Z8Jer4H7iWi67sbAxly05KZZjs4CHve4efsjOWqI4RBZtiUOJi4gDMI2gAWj/pQ+2ruvt/unDc2q1czu7VGepYSeJ3Aku40UleDIqIZHpMHemS+1aMuSV3zuo/2jg+Wyya/++5k4LTPHEQHsXs9JCIH0tfjc9pfIMirqIRS+cpkI8ZhO0Z5Znb7GxqKrpXxbOyFQu14DWMvH/8M+sPIlRearogMaTqFUMsa7f4cAbQsOa4M1tQkw1EnxxAt6U4738pJl1Ws7/Vj/Ri6ywN4PHzhoURLbsxzg= x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: dfda9b37-821e-4cdb-fc0f-08d4810a1b0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(189930954265078)(788757137089)(211936372134217)(206333022235701)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(39450400003)(377454003)(377424004)(6506006)(53936002)(54896002)(99286003)(606005)(9686003)(55016002)(77096006)(236005)(6436002)(6306002)(230783001)(2906002)(102836003)(790700001)(122556002)(6116002)(25786009)(76176999)(6246003)(8936002)(50986999)(5005710100001)(10290500002)(15650500001)(2950100002)(2420400007)(3280700002)(3660700001)(54356999)(10710500007)(10090500001)(86362001)(189998001)(2900100001)(33656002)(2501003)(81166006)(38730400002)(7110500001)(8676002)(229853002)(8990500004)(5660300001)(53546009)(7736002)(2201001)(7906003)(7696004)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 18:39:36.8333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Subject: Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:39:47 -0000 --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ3JlYXQg4oCTIEnigJltIGV4Y2l0ZWQgdG8gaGF2ZSBhbm90aGVyIGNvbmNyZXRlIGFw cGxpY2F0aW9uIHByb2ZpbGUgd2UgY2FuIGxvb2sgYXQuDQoNCkFzIGEgc2lkZSBub3RlLCBJIHRo aW5rIDQuNCBtaXNjaGFyYWN0ZXJpemVzIGFueSByZWNlbnQgZHJhZnQgb2YgSFRUUC9RVUlDLiAg QW4gSFRUUCBzZXJ2ZXIgZG9lcyBleHBsaWNpdGx5IG5lZWQgdG8gbGlzdGVuIGZvciBjbGllbnQt aW5pdGlhdGVkIHN0cmVhbXMgb3BlbmluZzsgdGhlcmXigJlzIG5vIGFubm91bmNlbWVudCBvZiB0 aGlzIGhhcHBlbmluZyBvbiBTdHJlYW0gMyBhcyB5b3UgZGVzY3JpYmUuICBUaGUgbWFpbiBlZmZl Y3Qgb2YgY2hvb3NpbmcgdG8gaGF2ZSBubyBjb250cm9sIHN0cmVhbSBpcyB0aGF0IHRoZXJlIGNh biBiZSBubyByZWxpYWJsZSBzZXNzaW9uLWxldmVsIGFwcGxpY2F0aW9uIGNvbnRleHQsIHNpbmNl IGRhdGEgb24gYW55IHN0cmVhbSBjYW4gYmUgbG9zdCB2aWEgYSBzdHJlYW0gcmVzZXQgYXQgdGhl IHdyb25nIHRpbWUuDQoNCjUuMi4yIGlzIGFuIGV4YW1wbGUgb2YgdGhpcyBpc3N1ZSDigJMgaG93 IHdpbGwgdGhlIFNFUlZGQUlMIGJlIHJlbGlhYmx5IGRlbGl2ZXJlZCBpZiB0aGUgc3RyZWFtIGlz IHJlc2V0PyAgWW91IHByb2JhYmx5IG5lZWQgdG8gZWl0aGVyIGRlZmluZSBlcnJvciBjb2RlcyBm b3IgRE5TL1FVSUMgYW5kIHJlcGxhY2UgU0VSVkZBSUwgd2l0aCB0aG9zZSwgb3IgcmVsaWFibHkg ZGVsaXZlciB0aGUgU0VSVkZBSUwgKHNvbWVob3cg4oCTIGJ5IG5ldmVyIHJlc2V0dGluZyBzdHJl YW1zPykuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMCwgMjAxNyAx MDoyMyBBTQ0KVG86IHF1aWNAaWV0Zi5vcmc7IGRucy1wcml2YWN5QGlldGYub3JnDQpTdWJqZWN0 OiBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDAudHh0DQoNCg0KRllJOiBKdXN0IHB1Ymxpc2hlZCB0aGlzIGRyYWZ0IGRl c2NyaWJpbmcgdHJhbnNwb3J0IG9mIEROUyBvdmVyIGEgZGVkaWNhdGVkIFFVSUMgY29ubmVjdGlv bi4NCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0t LS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1 aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQNCg0KRGF0ZToNCg0KTW9uLCAxMCBBcHIgMjAxNyAw OTo0NTozNyAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNCk1lbGluZGEgU2hvcmUgPG1zaG9y ZUBmYXN0bHkuY29tPjxtYWlsdG86bXNob3JlQGZhc3RseS5jb20+LCBTYXJhIERpY2tpbnNvbiA8 c2FyYUBzaW5vZHVuLmNvbT48bWFpbHRvOnNhcmFAc2lub2R1bi5jb20+LCBDaHJpc3RpYW4gSHVp dGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD48bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+LCBB bGxpc29uIE1hbmtpbiA8YW1hbmtpbkBzYWxlc2ZvcmNlLmNvbT48bWFpbHRvOmFtYW5raW5Ac2Fs ZXNmb3JjZS5jb20+LCBKYW5hcmRoYW4gSXllbmdhciA8anJpQGdvb2dsZS5jb20+PG1haWx0bzpq cmlAZ29vZ2xlLmNvbT4sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+PG1haWx0bzpqcmlA Z29vZ2xlLmNvbT4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Q2hyaXN0aWFuIEh1aXRlbWEgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5Lg0K DQoNCg0KTmFtZTogICAgICAgICAgZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljDQoNClJldmlz aW9uOiAgICAgIDAwDQoNClRpdGxlOiAgICAgICAgIFNwZWNpZmljYXRpb24gb2YgRE5TIG92ZXIg UVVJQw0KDQpEb2N1bWVudCBkYXRlOiAyMDE3LTA0LTEwDQoNCkdyb3VwOiAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAxOA0KDQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1k bnNvcXVpYy0wMC50eHQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpbnRlcm5ldC1kcmFmdHMlMkZk cmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0JmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwu YmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVkZjAwYTUxYmZlNjRiMTZjYTRiMDhkNDgwMzYzYWIz JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NDQxNzc4 MjMzMjIyMiZzZGF0YT1ReERnZVlqNk5NSHNlVktjZ1klMkZ2OHBnTHFqMDlhdlYxUG5HYU9Kdjcl MkIzYyUzRCZyZXNlcnZlZD0wPg0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLzxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljJTJGJmRh dGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVkZjAwYTUxYmZl NjRiMTZjYTRiMDhkNDgwMzYzYWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjI3NDQxNzc4MjMzMjIyMiZzZGF0YT1jN011T3hxMnczTDJqejNNV2N3QTk2 Z0NKcThsM2NrR2puQ0Y2ZkhKZk5rJTNEJnJlc2VydmVkPTA+DQoNCkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAw PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljLTAwJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzVk ZjAwYTUxYmZlNjRiMTZjYTRiMDhkNDgwMzYzYWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI3NDQxNzc4MjMzMjIyMiZzZGF0YT1pNG5CSm1zMVdad1Jv Nzh2QVpXRlNBbGZ1SDQ5SDh6RDJXalFJdTJHcXdjJTNEJnJlc2VydmVkPTA+DQoNCkh0bWxpemVk OiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWh1aXRl bWEtcXVpYy1kbnNvcXVpYy0wMDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMCZkYXRhPTAyJTdDMDElN0NtaWNo YWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2 M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0 MTc3ODIzMzIyMjImc2RhdGE9Snl3WlllaHkzQXhjN3NEWHNrTTJtR2VXNGtkaWlQQlNNWmxiaWNE MU41OCUzRCZyZXNlcnZlZD0wPg0KDQoNCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIFFVSUMgdG8gcHJvdmlkZSB0cmFuc3BvcnQgcHJpdmFj eQ0KDQogICBmb3IgRE5TLiAgVGhlIGVuY3J5cHRpb24gcHJvdmlkZWQgYnkgUVVJQyBoYXMgc2lt aWxhciBwcm9wZXJ0aWVzIHRvDQoNCiAgIHRoYXQgcHJvdmlkZWQgYnkgVExTLCB3aGlsZSBRVUlD IHRyYW5zcG9ydCBlbGltaW5hdGVzIHRoZSBoZWFkLW9mLQ0KDQogICBsaW5lIGJsb2NraW5nIGlz c3VlcyBpbmhlcmVudCB3aXRoIFRDUCBhbmQgcHJvdmlkZXMgbW9yZSBlZmZpY2llbnQNCg0KICAg ZXJyb3IgY29ycmVjdGlvbnMgdGhhbiBVRFAuICBETlMgb3ZlciBRVUlDIGhhcyBwcml2YWN5IHBy b3BlcnRpZXMNCg0KICAgc2ltaWxhciB0byBETlMgb3ZlciBUTFMgc3BlY2lmaWVkIGluIFJGQzc4 NTgsIGFuZCBwZXJmb3JtYW5jZSBzaW1pbGFyDQoNCiAgIHRvIGNsYXNzaWMgRE5TIG92ZXIgVURQ Lg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+TG9va3MgZ3JlYXQg4oCTIEnigJltIGV4Y2l0ZWQg dG8gaGF2ZSBhbm90aGVyIGNvbmNyZXRlIGFwcGxpY2F0aW9uIHByb2ZpbGUgd2UgY2FuIGxvb2sg YXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BcyBhIHNpZGUg bm90ZSwgSSB0aGluayA0LjQgbWlzY2hhcmFjdGVyaXplcyBhbnkgcmVjZW50IGRyYWZ0IG9mIEhU VFAvUVVJQy4mbmJzcDsgQW4gSFRUUCBzZXJ2ZXIgZG9lcyBleHBsaWNpdGx5IG5lZWQgdG8gbGlz dGVuIGZvciBjbGllbnQtaW5pdGlhdGVkIHN0cmVhbXMgb3BlbmluZzsgdGhlcmXigJlzIG5vIGFu bm91bmNlbWVudCBvZiB0aGlzIGhhcHBlbmluZyBvbg0KIFN0cmVhbSAzIGFzIHlvdSBkZXNjcmli ZS4mbmJzcDsgVGhlIG1haW4gZWZmZWN0IG9mIGNob29zaW5nIHRvIGhhdmUgbm8gY29udHJvbCBz dHJlYW0gaXMgdGhhdCB0aGVyZSBjYW4gYmUgbm8gcmVsaWFibGUgc2Vzc2lvbi1sZXZlbCBhcHBs aWNhdGlvbiBjb250ZXh0LCBzaW5jZSBkYXRhIG9uIGFueSBzdHJlYW0gY2FuIGJlIGxvc3Qgdmlh IGEgc3RyZWFtIHJlc2V0IGF0IHRoZSB3cm9uZyB0aW1lLiZuYnNwOw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij41LjIuMiBpcyBhbiBleGFtcGxlIG9mIHRoaXMg aXNzdWUg4oCTIGhvdyB3aWxsIHRoZSBTRVJWRkFJTCBiZSByZWxpYWJseSBkZWxpdmVyZWQgaWYg dGhlIHN0cmVhbSBpcyByZXNldD8mbmJzcDsgWW91IHByb2JhYmx5IG5lZWQgdG8gZWl0aGVyIGRl ZmluZSBlcnJvciBjb2RlcyBmb3IgRE5TL1FVSUMgYW5kIHJlcGxhY2UgU0VSVkZBSUwgd2l0aCB0 aG9zZSwgb3IgcmVsaWFibHkNCiBkZWxpdmVyIHRoZSBTRVJWRkFJTCAoc29tZWhvdyDigJMgYnkg bmV2ZXIgcmVzZXR0aW5nIHN0cmVhbXM/KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RpYW4gSHVpdGVt YTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDEwLCAyMDE3IDEwOjIzIEFNPGJyPg0K PGI+VG86PC9iPiBxdWljQGlldGYub3JnOyBkbnMtcHJpdmFjeUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBGd2Q6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o dWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RllJOiBKdXN0IHB1Ymxpc2hlZCB0aGlzIGRyYWZ0IGRlc2NyaWJpbmcgdHJh bnNwb3J0IG9mIEROUyBvdmVyIGEgZGVkaWNhdGVkIFFVSUMgY29ubmVjdGlvbi4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIENocmlzdGlhbiBIdWl0ZW1h PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0gPG86cD48L286 cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVj dDogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5EYXRlOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Nb24sIDEwIEFwciAyMDE3IDA5OjQ1OjM3IC0wNzAwPG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu OnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVsaW5kYSBTaG9y ZSA8YSBocmVmPSJtYWlsdG86bXNob3JlQGZhc3RseS5jb20iPiZsdDttc2hvcmVAZmFzdGx5LmNv bSZndDs8L2E+LCBTYXJhIERpY2tpbnNvbg0KPGEgaHJlZj0ibWFpbHRvOnNhcmFAc2lub2R1bi5j b20iPiZsdDtzYXJhQHNpbm9kdW4uY29tJmd0OzwvYT4sIENocmlzdGlhbiBIdWl0ZW1hIDxhIGhy ZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij4NCiZsdDtodWl0ZW1hQGh1aXRlbWEubmV0 Jmd0OzwvYT4sIEFsbGlzb24gTWFua2luIDxhIGhyZWY9Im1haWx0bzphbWFua2luQHNhbGVzZm9y Y2UuY29tIj4NCiZsdDthbWFua2luQHNhbGVzZm9yY2UuY29tJmd0OzwvYT4sIEphbmFyZGhhbiBJ eWVuZ2FyIDxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+Jmx0O2pyaUBnb29nbGUuY29t Jmd0OzwvYT4sIEphbmEgSXllbmdhcg0KPGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIj4m bHQ7anJpQGdvb2dsZS5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWMtMDAudHh0PG86cD48L286cD48L3ByZT4N CjxwcmU+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJpc3RpYW4gSHVpdGVt YSBhbmQgcG9zdGVkIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklFVEYgcmVwb3NpdG9y eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5O YW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkcmFmdC1odWl0ZW1hLXF1aWMtZG5zb3F1aWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZp c2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU3BlY2lmaWNhdGlvbiBvZiBETlMgb3ZlciBRVUlDPG86cD48L286cD48L3ByZT4NCjxwcmU+ RG9jdW1lbnQgZGF0ZTogMjAxNy0wNC0xMDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkdyb3VwOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFs IFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QYWdlczombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTg8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaW50ZXJuZXQt ZHJhZnRzJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAwLnR4dCZhbXA7ZGF0YT0wMiU3 QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDNWRmMDBhNTFiZmU2NGIxNmNh NGIwOGQ0ODAzNjNhYjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2Mjc0NDE3NzgyMzMyMjIyJmFtcDtzZGF0YT1ReERnZVlqNk5NSHNlVktjZ1klMkZ2OHBn THFqMDlhdlYxUG5HYU9KdjclMkIzYyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy0wMC50eHQ8 L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljJTJGJmFtcDtkYXRhPTAy JTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2 Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1wO3NkYXRhPWM3TXVPeHEydzNMMmp6M01XY3dBOTZn Q0pxOGwzY2tHam5DRjZmSEpmTmslM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtcXVpYy1kbnNvcXVpYy88L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaHVpdGVt YS1xdWljLWRuc29xdWljLTAwJmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1p Y3Jvc29mdC5jb20lN0M1ZGYwMGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1w O3NkYXRhPWk0bkJKbXMxV1p3Um83OHZBWldGU0FsZnVINDlIOHpEMldqUUl1Mkdxd2MlM0QmYW1w O3Jlc2VydmVkPTAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWl0ZW1hLXF1 aWMtZG5zb3F1aWMtMDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaHVpdGVtYS1xdWljLWRuc29xdWljLTAw JmFtcDtkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M1ZGYw MGE1MWJmZTY0YjE2Y2E0YjA4ZDQ4MDM2M2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzQ0MTc3ODIzMzIyMjImYW1wO3NkYXRhPUp5d1pZZWh5M0F4 YzdzRFhza00ybUdlVzRrZGlpUEJTTVpsYmljRDFONTglM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaHVpdGVtYS1xdWljLWRuc29x dWljLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNl IG9mIFFVSUMgdG8gcHJvdmlkZSB0cmFuc3BvcnQgcHJpdmFjeTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBmb3IgRE5TLiZuYnNwOyBUaGUgZW5jcnlwdGlvbiBwcm92aWRlZCBi eSBRVUlDIGhhcyBzaW1pbGFyIHByb3BlcnRpZXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgdGhhdCBwcm92aWRlZCBieSBUTFMsIHdoaWxlIFFVSUMgdHJhbnNwb3J0IGVs aW1pbmF0ZXMgdGhlIGhlYWQtb2YtPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGxpbmUgYmxvY2tpbmcgaXNzdWVzIGluaGVyZW50IHdpdGggVENQIGFuZCBwcm92aWRlcyBtb3Jl IGVmZmljaWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBlcnJvciBjb3Jy ZWN0aW9ucyB0aGFuIFVEUC4mbmJzcDsgRE5TIG92ZXIgUVVJQyBoYXMgcHJpdmFjeSBwcm9wZXJ0 aWVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNpbWlsYXIgdG8gRE5TIG92 ZXIgVExTIHNwZWNpZmllZCBpbiBSRkM3ODU4LCBhbmQgcGVyZm9ybWFuY2Ugc2ltaWxhcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0byBjbGFzc2ljIEROUyBvdmVyIFVEUC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYg U2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708062197E49BF2F98402B487000BN6PR03MB2708namp_-- From nobody Mon Apr 17 16:20:05 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 6FD941242F7; Mon, 17 Apr 2017 16:20:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: tjw.ietf@gmail.com, dns-privacy@ietf.org, terry.manderson@icann.org, dprive-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149247120341.17811.5858475129525269994.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 16:20:03 -0700 Archived-At: Subject: [dns-privacy] dprive - New Meeting Session Request for IETF 99 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:20:03 -0000 A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dprive working group. --------------------------------------------------------- Working Group Name: DNS PRIVate Exchange Area Name: Internet Area Session Requester: Tim Wicinski Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 70 Conflicts to Avoid: First Priority: dnsop homenet dnssd opsawg Second Priority: intarea saag People who must be present: Terry Manderson Warren Kumari Tim Wicinski Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Apr 24 17:48: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 48BF5131987 for ; Mon, 24 Apr 2017 17:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 2ap1_O_XwrBB for ; Mon, 24 Apr 2017 17:48:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 784C9131983 for ; Mon, 24 Apr 2017 17:48:50 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 257F1F997 for ; Mon, 24 Apr 2017 20:48:49 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8727720965; Mon, 24 Apr 2017 20:48:45 -0400 (EDT) From: Daniel Kahn Gillmor To: dns-privacy@ietf.org Date: Mon, 24 Apr 2017 20:48:42 -0400 Message-ID: <87inlt9us5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 00:48:52 -0000 --===-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Hi all-- I just pushed an individual submission that folks in DPRIVE might be interested in: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ It describes how a TLS server can offer both HTTPS and DNS-over-TLS on the same port because valid initial messages from each protocol are always distinguishable by the server. I have a functional implementation listening on TCP port 443 on dns.cmrg.net right now, if anyone wants to experiment with it. Consider all the possibilities of this terrible layering violation! Both of these commands works just fine: wget -O- https://dns.cmrg.net/ kdig +tls +tls-ca +tls-hostname=dns.cmrg.net @dns.cmrg.net:443 www.ietf.org I believe my analysis of DNS and HTTP message framing is correct, but if that's not the case, i hope someone will helpfully correct me. Constructive criticism is welcome on-list, and minor editorial cleanup can be made as merge requests to https://gitlab.com/dkg/hddemux or by private e-mail. Please send flames by private e-mail only :) --dkg --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: internet-drafts@ietf.org To: "Daniel Kahn Gillmor" Subject: New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149307849760.14644.3525296892539437682.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 17:01:37 -0700 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-dkg-dprive-demux-dns-http-00.txt has been successfully submitted by Daniel Kahn Gillmor and posted to the IETF repository. Name: draft-dkg-dprive-demux-dns-http Revision: 00 Title: Demultiplexing Streamed DNS from HTTP Document date: 2017-04-24 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-dkg-dprive-demux= -dns-http-00.txt Status: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns= -http/ Htmlized: https://tools.ietf.org/html/draft-dkg-dprive-demux-dns-http= -00 Htmlized: https://datatracker.ietf.org/doc/html/draft-dkg-dprive-demu= x-dns-http-00 Abstract: DNS over TCP and traditional HTTP are both stream-oriented, client- speaks-first protocols. They can both be run over a stream-based security protocol like TLS. A server accepting a stream-based client can distinguish between a valid stream of DNS queries and valid stream of HTTP requests by simple observation of the first few octets sent by the client. This can be done without any external demultiplexing mechanism like TCP port number or ALPN. Implicit multiplexing of the two protocols over a single listening port can be useful for obscuring the presence of DNS queries from a network observer, which makes it relevant for DNS privacy. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=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. The IETF Secretariat --=-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlj+nOoACgkQFJitxsGS MjdKbg//Ug0X3xUUfkFYsjonz2FljuKqzJB/ho3M9E8QsAdmqU3b+SH2hVWYQtUE zDY9AfcxvH+qHOfJnH/RkMy5jcs0f93MjtwHCjEsceQBbiI31PaeBSP6L8yLP3Ps xClXy8kc3Mhw2WSvw/SBeXelkKHDz8GDhaB8YZd8ZZrOv/Xj/B3NLpX9CtoOmm67 BbVQYRi+sB5pRgUztTa9P/KnNTORhlRMHeXlUoU2+XtbNM7wicGa4LRPtAUEXQww lHVsndxJ21ln3BJ3w27JPmR6TxRkVXnIUTZ1T36mG1Dd/ZjaRIL7pgtvNh26uklF dpqkkoEUh/6K+UWxxw7vTls+1i4iF7LrYIx7GFJYmY7lZfbR8j+lzTHynsd2p2DW rcokxAOHy9qxP087C+MszCoVVDmjcH1sT5jnew+OfTG03I3R2QcKpOxyzr9XekAl 956XBzVgoW/FN5kU/io1C3pTkODC8ESINot1TWWV/by5ZxTn2Szty4mWGnSIjuZK EfAY1C61Dd++9SpVZ46LiNTmQELda+zHKcN3mKaZXm7kprD9V0c7LwMpVh1DJeSV LQ7DCHaYqpow8vgb0a6jN546Y8KHKdEmf5GcdDk6p3cJrx098HXWWccabuHPbi1x ii58+J6RzsS96XUhy88winibEr9EjndAkwpvH7gnysVJbv68+co= =7taz -----END PGP SIGNATURE----- --===-=-=-- From nobody Wed Apr 26 02:05:58 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 827D6131A4C for ; Wed, 26 Apr 2017 02:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz 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 o7pnCqMdL0B5 for ; Wed, 26 Apr 2017 02:05:55 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 23A43131A34 for ; Wed, 26 Apr 2017 02:05:54 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id h2so146691535uaa.1 for ; Wed, 26 Apr 2017 02:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U7wyKAhyvBtclP5wDewE1mLHLtZkH4TQKsKxQSXbdgM=; b=HDVxEMvjkQ5IwYwuv8i9uigjI+DTBdCO2BjsgbFzw+4r94A8668bWARZaMdc7ZXlkV 3nSf9a9yCuZG+h3NXRjb1dUZoFzdOBRrvge8axSQ0vUdqtlD8pFmGVXtihfmYfaj+BDs UQ334Twf1HhW620/slKmpLzQY9ZLg5fAHMfxM= 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=U7wyKAhyvBtclP5wDewE1mLHLtZkH4TQKsKxQSXbdgM=; b=fmPpSz+/oZPYB7WRHx8+fDuauhcCCVBQNnmAISbMufgPQ0rGb36dF+utKnAnrn+VCR xOTPgo1mQ/XtzWCgc7kfUUmz2hWv3iR2bK8BxH8mZpscvPdxzZLVv/6PglOnd5UKHBqG ZY6qz989mjxKp9Wyw1yJDNah4anBGG4s58nqdasTyKdfyZrNGy3G9gg9oxtWToDm2yGr 8ZpImS/+IK4qHIWqCB0STCteuoHaseQhPQqDpemCBazOLQlnj9o1/OyXUHExjeZwmOog PFJlK/RlQOqDkejZEwe8JcYea4AE8fxjratqpcj2HN904NdDOorViNp7NAFl3roRsOEK FbDQ== X-Gm-Message-State: AN3rC/5V1AaHS78oo4j+OchkQXmtnzV3kZnAc5pNwPH5t/TffGgphkk9 pDAxoSmMPGLsK09k8H7/ykgXqgN6d3uE X-Received: by 10.176.24.223 with SMTP id d31mr19119848uah.140.1493197553923; Wed, 26 Apr 2017 02:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.69 with HTTP; Wed, 26 Apr 2017 02:05:33 -0700 (PDT) X-Originating-IP: [89.103.145.110] In-Reply-To: <87inlt9us5.fsf@fifthhorseman.net> References: <87inlt9us5.fsf@fifthhorseman.net> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Wed, 26 Apr 2017 11:05:33 +0200 Message-ID: To: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:05:57 -0000 Hello Daniel, thank you for writing this down. The draft is great. And it's awesome that it's accompanied with an actual running code. A have just a few notes after reading the draft for the first time: - For the sake of simplicity, I would suggest dropping the part about HTTP/0.9. I don't think it's worth the effort keeping it supported. - The Section 3 (Overview of initial octets) is a little bit chaotic and scattered. Maybe it would be more readable if you just provided pointers to specification of the protocols without providing much details, then shown the initial octets (or headers) side by side without analysing the content, and in the end walked by the bytes from the beginning while discussing the values. - I love how simple the algorithm is in the end. And the proof is great. Cheers, Jan On Tue, Apr 25, 2017 at 2:48 AM, Daniel Kahn Gillmor wrote: > Hi all-- > > I just pushed an individual submission that folks in DPRIVE might be > interested in: > > https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ > > It describes how a TLS server can offer both HTTPS and DNS-over-TLS on > the same port because valid initial messages from each protocol are > always distinguishable by the server. > > I have a functional implementation listening on TCP port 443 on > dns.cmrg.net right now, if anyone wants to experiment with it. Consider > all the possibilities of this terrible layering violation! > > Both of these commands works just fine: > > wget -O- https://dns.cmrg.net/ > > kdig +tls +tls-ca +tls-hostname=dns.cmrg.net @dns.cmrg.net:443 www.ietf.org > > I believe my analysis of DNS and HTTP message framing is correct, but if > that's not the case, i hope someone will helpfully correct me. > > Constructive criticism is welcome on-list, and minor editorial cleanup can > be made as merge requests to https://gitlab.com/dkg/hddemux or by > private e-mail. Please send flames by private e-mail only :) > > --dkg > > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > To: Daniel Kahn Gillmor > Cc: > Bcc: > Date: Mon, 24 Apr 2017 17:01:37 -0700 > Subject: New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt > > A new version of I-D, draft-dkg-dprive-demux-dns-http-00.txt > has been successfully submitted by Daniel Kahn Gillmor and posted to the > IETF repository. > > Name: draft-dkg-dprive-demux-dns-http > Revision: 00 > Title: Demultiplexing Streamed DNS from HTTP > Document date: 2017-04-24 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-dkg-dprive-demux-dns-http-00.txt > Status: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ > Htmlized: https://tools.ietf.org/html/draft-dkg-dprive-demux-dns-http-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dkg-dprive-demux-dns-http-00 > > > Abstract: > DNS over TCP and traditional HTTP are both stream-oriented, client- > speaks-first protocols. They can both be run over a stream-based > security protocol like TLS. A server accepting a stream-based client > can distinguish between a valid stream of DNS queries and valid > stream of HTTP requests by simple observation of the first few octets > sent by the client. This can be done without any external > demultiplexing mechanism like TCP port number or ALPN. > > Implicit multiplexing of the two protocols over a single listening > port can be useful for obscuring the presence of DNS queries from a > network observer, which makes it relevant for DNS privacy. > > > > > 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. > > The IETF Secretariat > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > From nobody Wed Apr 26 22:31:20 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 D40EE1315AB for ; Wed, 26 Apr 2017 22:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 Keg5npXpsZLr for ; Wed, 26 Apr 2017 22:31:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 528D41315A5 for ; Wed, 26 Apr 2017 22:31:17 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id B93F7F99C; Thu, 27 Apr 2017 01:31:16 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B77132032F; Wed, 26 Apr 2017 20:43:31 -0400 (EDT) From: Daniel Kahn Gillmor To: Jan =?utf-8?B?VsSNZWzDoWs=?= Cc: dns-privacy@ietf.org In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> Date: Wed, 26 Apr 2017 20:43:28 -0400 Message-ID: <87efwe7k9b.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 05:31:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jan-- On Wed 2017-04-26 11:05:33 +0200, Jan V=C4=8Del=C3=A1k wrote: > thank you for writing this down. The draft is great. And it's awesome > that it's accompanied with an actual running code. thanks! and thanks for the quick review :) > A have just a few notes after reading the draft for the first time: > - For the sake of simplicity, I would suggest dropping the part about > HTTP/0.9. I don't think it's worth the effort keeping it supported. That would definitely make the document much simpler :) I suppose i should float this by the HTTP community, to see whether they agree that it's ok to drop HTTP/0.9. > - The Section 3 (Overview of initial octets) is a little bit chaotic > and scattered. Maybe it would be more readable if you just provided > pointers to specification of the protocols without providing much > details, then shown the initial octets (or headers) side by side > without analysing the content, and in the end walked by the bytes from > the beginning while discussing the values. I understand what you're saying, i'm not sure how to do this exactly. With DNS, the fields are fixed size and have fixed meaning, but with HTTP, there's an abstract grammar. So they don't just "line up" side by side, as it were. I can certainly remove the copied text and just leave pointers to other documents, but that seems like it effectively asks the reader to do a bunch of pointer chasing when i've already done the pointer-chasing for them. Any concrete suggestions for how to improve it? It's maintained in markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests or patches! > - I love how simple the algorithm is in the end. And the proof is > great. I'm glad you like it too -- i'm happy that it seems possible to be strictly confident in the demuxing. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkBPrAACgkQFJitxsGS MjenTRAAovLXTl3HEiLJB8amIxDV14mcl/u5bUGe9SFYLdyc0uNp851cJO4CN+2j UZXVr+AEWCgVaafE1O6TDEywq8yf8sK5ycTY82pR/UzRPqALqgQgzjjyjBDJsPpY T04m9/3kKkd/8vGX5cFIxjmzAs6Cws5cjF+e3AOFFVrp1/UkMyYNA4U5GqsdyMFe Gu86QH2RnJyUCHkz0m400ZQaRYvNWvNU+0OuPSeNideG/OqrVkkDzE79+PbTF3aZ HJdRtcQcRaAfpussJs+M2yh66GZ3Q+v/8ObRbJankNUMZKfgIiSKc3cck8AXy3LF asQ5AOWR/ywaY9T1tqw1MYD+QIM9aHhIfkwZaGjgUeKp3NkoaxHZyviB4/+e0BR3 6o4eGcfcdnVzKRNFt9IJaj50lTN5qIDa/4FtWLiZzII/KvUC4Tmed7gVZij8Dh9k OnhQfhHkdZz8In7fKJGhyjI/9WYZO/lcEQ92oq7oyyA1E6X1xj186neifqXWtbnZ IlwA63zFhWc3BLzpY/w8ftPI1YNf1ACx7VvBwVCRbg50FswXVajAWEz47lP1lIft mlj+i5V182yzxZzgvbOMBxav8JphwYM+nUF2GRBVzsFfiPeH/smQKLSKDZbOsnPq Id/fiEaVxTA7sJBF1LdvfnQA1fvhlLckMRcNcvBWtAdCiqp6zcQ= =iF8f -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 27 00:53:26 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 C9576128B37 for ; Thu, 27 Apr 2017 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 YrI83-IxwNUf for ; Thu, 27 Apr 2017 00:53:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 3825D126BF6 for ; Thu, 27 Apr 2017 00:53:23 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a] (unknown [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a]) by mail.nic.cz (Postfix) with ESMTPSA id A246B621A1 for ; Thu, 27 Apr 2017 09:53:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1493279601; bh=f5TWDdswzS+a2yjnbn6DM23hc/zk9KGhDwzm9w3cuU4=; h=To:From:Date; b=YJ0dzVluTzghTfOGJ7MgKJ9b9xb3ksEq3CbYjFBIe5T3j1/fC86VAOIv5PpebR9QE 9mzl12iez/tV62BaSU6uqFBnzOsv5Oau5qhYlEw+DRcPMNk1zh7B/KsXkfDeUhkcid M5G0rdsj0s2kD/ysGX6bseDDwLiy1m8nKNh140KI= To: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <18ca2706-6c1d-e1d9-e2c2-d770ad9d79b2@nic.cz> Date: Thu, 27 Apr 2017 09:53:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <87efwe7k9b.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 07:53:25 -0000 On 27.4.2017 02:43, Daniel Kahn Gillmor wrote: > Hi Jan-- > > On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote: >> thank you for writing this down. The draft is great. And it's awesome >> that it's accompanied with an actual running code. > > thanks! and thanks for the quick review :) > >> A have just a few notes after reading the draft for the first time: >> - For the sake of simplicity, I would suggest dropping the part about >> HTTP/0.9. I don't think it's worth the effort keeping it supported. > > That would definitely make the document much simpler :) I suppose i > should float this by the HTTP community, to see whether they agree that > it's ok to drop HTTP/0.9. > >> - The Section 3 (Overview of initial octets) is a little bit chaotic >> and scattered. Maybe it would be more readable if you just provided >> pointers to specification of the protocols without providing much >> details, then shown the initial octets (or headers) side by side >> without analysing the content, and in the end walked by the bytes from >> the beginning while discussing the values. > > I understand what you're saying, i'm not sure how to do this exactly. > With DNS, the fields are fixed size and have fixed meaning, but with > HTTP, there's an abstract grammar. So they don't just "line up" side by > side, as it were. > > I can certainly remove the copied text and just leave pointers to other > documents, but that seems like it effectively asks the reader to do a > bunch of pointer chasing when i've already done the pointer-chasing for > them. Let me state that I like current version with copied text. For me it is really easier to follow than jumping between documents. Petr Špaček @ CZ.NIC > > Any concrete suggestions for how to improve it? It's maintained in > markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests > or patches! > >> - I love how simple the algorithm is in the end. And the proof is >> great. > > I'm glad you like it too -- i'm happy that it seems possible to be > strictly confident in the demuxing. > > --dkg From nobody Thu Apr 27 03:28:21 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 892CA1200DF for ; Thu, 27 Apr 2017 03:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 rJrj-KjqA4ZK for ; Thu, 27 Apr 2017 03:28:18 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A11761200C1 for ; Thu, 27 Apr 2017 03:28:18 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47652) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1d3gel-0001FU-fF (Exim 4.89) (return-path ); Thu, 27 Apr 2017 11:28:15 +0100 Date: Thu, 27 Apr 2017 11:28:15 +0100 From: Tony Finch To: Daniel Kahn Gillmor cc: dns-privacy@ietf.org In-Reply-To: <87efwe7k9b.fsf@fifthhorseman.net> Message-ID: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 10:28:20 -0000 Section 3.2.2 HTTP/1 Is there a SP missing between the request-target and the HTTP-version in the diagram of the shortest possible request? Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT Do you want to support UPDATE? If not it should probably be ruled out up front, since it changes some of the analysis (though not the result, since octet 5 will be zero for DNS). Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Thames, Dover, Wight, Portland, Plymouth: North or northwest, backing west for a time, 4 or 5, decreasing 3 at times. Slight or moderate. Showers, then rain for a time except in Plymouth. Good, occasionally moderate. From nobody Thu Apr 27 08:25: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 1CFFD129572 for ; Thu, 27 Apr 2017 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 Ex7prjSWXEpg for ; Thu, 27 Apr 2017 08:25:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3393A129568 for ; Thu, 27 Apr 2017 08:24:37 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.12]) by che.mayfirst.org (Postfix) with ESMTPSA id 95858F98C; Thu, 27 Apr 2017 11:24:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0FD752035F; Thu, 27 Apr 2017 10:42:46 -0400 (EDT) From: Daniel Kahn Gillmor To: Tony Finch Cc: dns-privacy@ietf.org In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> Date: Thu, 27 Apr 2017 07:42:42 -0700 Message-ID: <87bmrh7vz1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:25:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2017-04-27 11:28:15 +0100, Tony Finch wrote: > Section 3.2.2 HTTP/1 > > Is there a SP missing between the request-target and the HTTP-version in > the diagram of the shortest possible request? whoops, i can't believe i missed that. thanks! fixed in git: https://gitlab.com/dkg/hddemux/commit/bc88fd5dd65cded1c20a61e55d1e747bb= a769c1c > Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT > > Do you want to support UPDATE? If not it should probably be ruled out up > front, since it changes some of the analysis hm, i don't want to rule out UPDATE, i just hadn't thought about it. -- i can imagine someone wanting to make use of UPDATE over this mechanism, so it'd be nice to keep it. I've opened a ticket to track that concern: https://gitlab.com/dkg/hddemux/issues/1 > (though not the result, since octet 5 will be zero for DNS). Is that guaranteed? It seems likely in practice, but RFC 2136 says: RCODE Response code - this four bit field is undefined in requests and set in responses.=20 So it seems conceivable that some client fiddles with these undefined bits somehow -- they're not required to be zeros, the way the Z section is :/ the way i'm reading RFC 2136, though, the formats of the four sections remain the same, so the "Combinations of octets" calculation seems to still hold, which means the "Proof" section should still hold too, i think. Or am i missing something there? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkCA2MACgkQFJitxsGS MjfKxw//Vw7OBAg08LolDLDVSK4J4AweCCs3OfPYPzmWJXDcxmHNXVyZi16LlBJS kN9xlYAy0vvByiMeQJde1unhWCZVqqZQ2eX1QXFOPULjTQrSfNMc965Qm3DTWzw6 TJK12tynzAhczks7SzQicDs/MSy8kZL0RAi5m+rNPZwXdxc+JGpPlPeHWtDzWMMV ig1dw9u7gIKYv8x0gAYKQ6xw+7qiFSjVd/H13cc3p2Qoh1WZAbtpvqUmhPEjcu40 P4O4EX2LJ833jZLi5caL5QwfTuo2pKiLztO1IQ8fKtaOyp7yBhuAQlEF7eOgjSXn dofNUcSGufWdyi/pXwipUmC8alCEWjGLaX6coy1BYGS6JD0i4tc0wbNhwZg46MAf wAbWbRZEKECH3zXxQTf9Gtacet5ramEB7G7sFGv+9Rl8tIV41cZflybUkwhWPJOC 4P3NTswCAP7HiyhYv7B6Edh0Z7Ku1LZ4frZw6uJzWrsjEgMdfGqReGB93o79dNhe e+mISsjgSuS5PNr0QYbh51R29w+p6tZxm97c8R8Qq1GxUZQ39kvwYKRC+AWa+yz3 hH80VF6Pvfvc8KUXj6/i7RuBTN01V7bDPtezw6OYC/1hntEJQYor8gJC/Kj+5JdF IBwVMBJU+eZj7bDdXLAGjZLEmxtW3VMEhYRcZeMaQto5yHy44lo= =olz/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 27 10:17: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 D6052129B3A for ; Thu, 27 Apr 2017 10:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 vUHs-6RXun-G for ; Thu, 27 Apr 2017 10:17:10 -0700 (PDT) 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 B75CC129494 for ; Thu, 27 Apr 2017 10:14:40 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RHDshN010843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 10:13:55 -0700 (PDT) To: Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> From: Joe Touch Message-ID: <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> Date: Thu, 27 Apr 2017 10:13:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <87efwe7k9b.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:17:11 -0000 Hi, all, Speaking as an IANA ports team reviewer: IMO this document needs to UPDATE the HTTPS specification. Otherwise, it's basically encouraging squatting on port 443 TCP, which is inappropriate. Keep in mind that any bit pattern that you *think* differentiates DNS from HTTPS is not yours to define - it is the purview of HTTPS to define or delegate in any way they see fit. You can certainly ask IANA for a new port on which to run both HTTPS and DNS, but it is inappropriate to change port 443 without coordination. Joe From nobody Thu Apr 27 10:37:34 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 C56C3129A98 for ; Thu, 27 Apr 2017 10:37:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 N6GUN_G71FOB for ; Thu, 27 Apr 2017 10:37:29 -0700 (PDT) Received: from spamfilter4.dtu.dk (spamfilter4.dtu.dk [192.38.80.33]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0250129AF3 for ; Thu, 27 Apr 2017 10:34:36 -0700 (PDT) Received: from ait-pexedg02.win.dtu.dk (ait-pexedg02.win.dtu.dk [192.38.82.192]) by spamfilter4.dtu.dk with ESMTP id v3RHYSFa013884-v3RHYSFc013884 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 27 Apr 2017 19:34:28 +0200 Received: from ait-pex01mbx03.win.dtu.dk (192.38.80.17) by ait-pexedg02.win.dtu.dk (192.38.82.192) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Apr 2017 19:34:25 +0200 Received: from ait-pex01mbx01.win.dtu.dk ([169.254.1.88]) by ait-pex01mbx03.win.dtu.dk ([169.254.3.202]) with mapi id 14.03.0319.002; Thu, 27 Apr 2017 19:34:28 +0200 From: Hugo Maxwell Connery To: Joe Touch , Daniel Kahn Gillmor , =?iso-8859-2?Q?Jan_V=E8el=E1k?= CC: "dns-privacy@ietf.org" Thread-Topic: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] Thread-Index: AQHSvV3GK12C0e4dlk2cqwEyc/eIXKHXPEKAgAEGDQCAARS5AIAAJDqU Date: Thu, 27 Apr 2017 17:34:27 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net>, <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> In-Reply-To: <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:37:32 -0000 Hi all, This is the argument that I expected; single port allocation looks clean, and enables "simple" delivery of processing resources. That's why we created ports, no? (please flame here, I have no idea about this historical claim). The underlying question raised by this lovely proposition is: Was that such a great idea in the first place, now that we know that surveillance is **what happens on the internet**. We need the tech community to re-evaluate assumptions based on what has been learned since RFC7258. I do not suggest that DKG's suggestion is the answer, but I suggest that it is worth consideration, and more importantly, the concepts=20 behind it need considering. Should we mandate that all future protocols are "demuxible" from all previous? For me, I say "looks like a good idea" (stream based over TLS). =20 Bring on the discussion. Regards, Hugo Connery -- Head of IT, DTU Environment, http://www.env.dtu.dk ________________________________________ From: dns-privacy [dns-privacy-bounces@ietf.org] on behalf of Joe Touch [to= uch@isi.edu] Sent: Thursday, 27 April 2017 19:13 To: Daniel Kahn Gillmor; Jan V=E8el=E1k Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener= [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] Hi, all, Speaking as an IANA ports team reviewer: IMO this document needs to UPDATE the HTTPS specification. Otherwise, it's basically encouraging squatting on port 443 TCP, which is inappropriate. Keep in mind that any bit pattern that you *think* differentiates DNS from HTTPS is not yours to define - it is the purview of HTTPS to define or delegate in any way they see fit. You can certainly ask IANA for a new port on which to run both HTTPS and DNS, but it is inappropriate to change port 443 without coordination. Joe _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Thu Apr 27 10:51:47 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 4665D129B59 for ; Thu, 27 Apr 2017 10:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 CYEPreGPSyxD for ; Thu, 27 Apr 2017 10:51:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 D6B44129B69 for ; Thu, 27 Apr 2017 10:48:52 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3RHmRWX014190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 10:48:27 -0700 (PDT) To: Hugo Maxwell Connery , Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: "dns-privacy@ietf.org" References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> From: Joe Touch Message-ID: Date: Thu, 27 Apr 2017 10:48:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Content-Language: en-US X-MailScanner-ID: v3RHmRWX014190 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:51:46 -0000 Hi, Hugo, On 4/27/2017 10:34 AM, Hugo Maxwell Connery wrote: > Hi all, > > This is the argument that I expected; single port allocation looks > clean, and enables "simple" delivery of processing resources. > > That's why we created ports, no? (please flame here, I have no > idea about this historical claim). See RFC7605, which includes a detailed history. In brief: Ports serve two purposes - demultiplexing IDs to enable multiple connections to a host with a single IP address, and (for first-contact from client to server) to indicate the default service that receives incoming "first contact" requests. You could certainly define a new service that combines HTTPS and DNS on a single port. Note that RFC6335 and RFC7605 both recommend against creating new ports for existing services, but it *might* be arguable that the combined service is somehow uniquely distinct (that would need to be successfully argued, though). > The underlying question raised by this lovely proposition is: > > Was that such a great idea in the first place, now that we know > that surveillance is **what happens on the internet**. > > We need the tech community to re-evaluate assumptions based > on what has been learned since RFC7258. > > I do not suggest that DKG's suggestion is the answer, but I suggest > that it is worth consideration, and more importantly, the concepts > behind it need considering. > > Should we mandate that all future protocols are "demuxible" from > all previous? Well, that's the role ports serve within transport protocols. And the role that the "protocol" field serves in IPv4, the "next header" field serves in IPv6, and the "ethertype" field serves in Ethernet... We always need a way to demux based on protocol, either by a signal from the lower-level protocol (these fields) or in-band (as in TCPMUX, though only historic now, or out of band, e.g., mDNS). However, if you're proposing we do this for ALL services currently assigned to ports, IMO that's a bad idea - it just serves to push port demuxing one layer in, which only creates a war of escalation with NATs, firewalls, and routers - creating an Internet within a flow. So the question here is - why these two? Joe > For me, I say "looks like a good idea" (stream based over TLS). > > Bring on the discussion. > > Regards, > Hugo Connery > -- > Head of IT, DTU Environment, http://www.env.dtu.dk > ________________________________________ > From: dns-privacy [dns-privacy-bounces@ietf.org] on behalf of Joe Touch [touch@isi.edu] > Sent: Thursday, 27 April 2017 19:13 > To: Daniel Kahn Gillmor; Jan Velk > Cc: dns-privacy@ietf.org > Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] > > Hi, all, > > Speaking as an IANA ports team reviewer: > > IMO this document needs to UPDATE the HTTPS specification. > > Otherwise, it's basically encouraging squatting on port 443 TCP, which > is inappropriate. > > Keep in mind that any bit pattern that you *think* differentiates DNS > from HTTPS is not yours to define - it is the purview of HTTPS to define > or delegate in any way they see fit. > > You can certainly ask IANA for a new port on which to run both HTTPS and > DNS, but it is inappropriate to change port 443 without coordination. > > Joe > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Thu Apr 27 11:54: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 36FF7126579 for ; Thu, 27 Apr 2017 11:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 eDxK2hYELmSP for ; Thu, 27 Apr 2017 11:54:51 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 53B44129BB0 for ; Thu, 27 Apr 2017 11:51:50 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d3oW4-0003mw-Dx for dns-privacy@ietf.org; Thu, 27 Apr 2017 20:51:49 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d3oW1-0008TE-OF for dns-privacy@ietf.org; Thu, 27 Apr 2017 14:51:47 -0400 Received: (qmail 3910 invoked from network); 27 Apr 2017 18:51:40 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Apr 2017 18:51:40 -0000 To: Joe Touch , Hugo Maxwell Connery , Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> Cc: "dns-privacy@ietf.org" From: Christian Huitema Message-ID: <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> Date: Thu, 27 Apr 2017 11:51:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49I98TYJ6ZsqWtR/HDmWTg9dTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpyTcbs0+yZanmlbTyr1x1XRcOb18WfxGyg6Om6u4YYm2CiA3+1HZYAFaBC Gp7uRHw5hjoyEb9Oq0NWpyO3vrfYJa7GnXDffeBY//TcvM3Flj3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBqW+JovcC0XtHTtanzqbG/HTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0nbTCn7RP t/Hauxx773FS/rbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/sV/ccPPAIzwUs9bYOpC55wGJup4S9zw3Uyx 7POi0R1TGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+b9mlnvEtfZrycMUgF0W/W/z0IiXE+0L8SRVLX+bQiWq X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 18:54:53 -0000 On 4/27/2017 10:48 AM, Joe Touch wrote: > ... > In brief: > Ports serve two purposes - demultiplexing IDs to enable multiple > connections to a host with a single IP address, and (for first-contact > from client to server) to indicate the default service that receives > incoming "first contact" requests. > > You could certainly define a new service that combines HTTPS and DNS on= > a single port. Note that RFC6335 and RFC7605 both recommend against > creating new ports for existing services, but it *might* be arguable > that the combined service is somehow uniquely distinct (that would need= > to be successfully argued, though). Well, things do change. The most interesting thing that we did observe is the generalized used of TLS. The stack used to be IP/TCP/App, and in that case you really need to demux at the TCP layer, and you can do that using ports. The stack that we do have now is IP/TCP/TLS/App, or IP/Quic/TLS/App. We could still demux at the TCP layer, but we could also demux at the TLS layer. As DKG points out, demuxing at the TLS layer does hide some of the metadata, and thus provides better privacy and resistance to censorship than demuxing on the clear text TCP port. Of course, one only gets the privacy benefits if the TLS demuxing is not based on clear text fields like the SNI or the ALPN. DKG proposes an heuristic, based on the observation that the first bytes of application data are enough to differentiate HTTP and DNS. Heuristics like these have the advantage of being easily deployed. They do have the inconvenient of affecting the long term evolution of the application protocols. We may want to look at a robust long term alternative. HTTP2 actually took a step in that direction. This is specified in section 3.5 of RFC 7540. "Each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. The client and server each send a different connection preface." The spec goes on to specify a 24 byte string, corresponding to the ASCII value "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a "SETTINGS" frame. So maybe we could build on that, and let application register their specific 24 bytes string, allowing for demux on top of TLS. That would define an organized process. -- Christian Huitema From nobody Thu Apr 27 12:05:40 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 1686A124234 for ; Thu, 27 Apr 2017 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 3okfhY0ycHr4 for ; Thu, 27 Apr 2017 12:05:38 -0700 (PDT) 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 5E85A129B5A for ; Thu, 27 Apr 2017 12:01:50 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RJ12bF023961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 12:01:03 -0700 (PDT) To: Christian Huitema , Hugo Maxwell Connery , Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: "dns-privacy@ietf.org" References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> From: Joe Touch Message-ID: <2fdf8430-1f43-60f5-5ca3-84ed58f1a19e@isi.edu> Date: Thu, 27 Apr 2017 12:01:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:05:39 -0000 Hi, Christina, On 4/27/2017 11:51 AM, Christian Huitema wrote: > So maybe we could build on that, and let application register their > specific 24 bytes string, allowing for demux on top of TLS. That would > define an organized process. > > -- Christian Huitema This can be done for a new service to be defined, which then might qualify for a new IANA for a port assignment. AFAICT, no one can redefine any existing service, even ones that use TLS, this way, though. I'm not sure whether it would be a good idea, though - my view is that this just serves to push port demuxing - which already exists outside TLS - inside TLS. Joe From nobody Thu Apr 27 12:17:16 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 363BC1294E8 for ; Thu, 27 Apr 2017 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 SM1RTKRJk5-u for ; Thu, 27 Apr 2017 12:17:13 -0700 (PDT) Received: from smtp.parc.xerox.com (omega.xerox.com [13.1.64.95]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002C6129527 for ; Thu, 27 Apr 2017 12:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.parc.xerox.com (Postfix) with ESMTP id 82EA95201DB; Thu, 27 Apr 2017 12:13:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at parc.com Received: from smtp.parc.xerox.com ([127.0.0.1]) by localhost (smtp.parc.xerox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWnnQv_z0WPz; Thu, 27 Apr 2017 12:13:46 -0700 (PDT) Received: from exchangehub.parc.xerox.com (vertigo.parc.xerox.com [13.2.13.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.parc.xerox.com (Postfix) with ESMTPS id 55DA25201D9; Thu, 27 Apr 2017 12:13:46 -0700 (PDT) Received: from E2010DAG5.corp.ad.parc.com ([fe80::3d0b:7158:aec4:e05e]) by vertigo.corp.ad.parc.com ([fe80::606e:47ce:f5e2:fe3a%14]) with mapi id 14.03.0319.002; Thu, 27 Apr 2017 12:13:46 -0700 From: To: CC: , , , , Thread-Topic: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] Thread-Index: AQHSvV2+OXo5AQDibU62HFvDSOkxFaHX0yKAgAEGDQCAARS5AIAABb6AgAAD6ACAABGmAIAABi8A Date: Thu, 27 Apr 2017 19:13:46 +0000 Message-ID: <79085D94-71CD-4DA7-A6A3-D6367D298EEE@parc.com> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> In-Reply-To: <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.0.67.90] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:17:15 -0000 SSB0aGluayBJ4oCZbSBtaXNzaW5nIHNvbWV0aGluZyBhYm91dCB0aGlzIHByb3Bvc2FsLCBhdCBs ZWFzdCBpbiB0aGUgY2FzZSBvZiBhIGdlbmVyYWwgZGVtdXggcHJvdG9jb2wuICBJZiB5b3UgZGV0 YWNoIFRMUyBmcm9tIGEgc3BlY2lmaWMgYXBwbGljYXRpb24gY29udGV4dCwgd2hvIHByb3ZpZGVz IHRoZSBjZXJ0aWZpY2F0ZXMgYW5kIGV2YWx1YXRlcyB0aGUgdHJ1c3QgYW5jaG9ycz8gIElmIHlv dSBkb27igJl0IGhhdmUgYSB0cmFmZmljIHNlY3JldCwgaG93IGRvIHlvdSBoaWRlIHRoZSBkZW11 eCBzaWduYWxpbmc/ICBJdCBzZWVtcyBsaWtlIGhhdmluZyBhIGdlbmVyYWwgcHVycG9zZSBUTFMg ZGVtdXggd291bGQgcmVxdWlyZSBkZWxlZ2F0aW5nIGFsbCB0aGF0IHRvIHNvbWUgb3RoZXIgcHJv Y2VzcyBpbmNsdWRpbmcgdGhlIERIIGV4Y2hhbmdlPw0KDQpJIGNhbiBzZWUgaG93LCBhcyBkcmFm dCBkcmFmdC1ka2ctZHByaXZlLWRlbXV4LWRucy1odHRwLTAwIHB1dHMgaXQsIGEgc3BlY2lhbCB0 ZXJtaW5hdG9yIG1pZ2h0IG9mZmVyIHR3byBwcm90b2NvbHMgb2YgRE5TIGFuZCBIVFRQLCBidXQg dGhvc2UgYXJlIGJvdGggYmVpbmcgb2ZmZXJlZCBieSB0aGUgc2FtZSBhcHBsaWNhdGlvbiB0aGF0 IHNoYXJlIHRoZSBzYW1lIFRMUyBjcmVkZW50aWFscywgeWVzPw0KDQpUaGFua3MsDQpNYXJjDQoN Cj4gT24gQXByIDI3LCAyMDE3LCBhdCAxMTo1MSBBTSwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBPbiA0LzI3LzIwMTcgMTA6NDgg QU0sIEpvZSBUb3VjaCB3cm90ZToNCj4+IC4uLg0KPj4gSW4gYnJpZWY6DQo+PiBQb3J0cyBzZXJ2 ZSB0d28gcHVycG9zZXMgLSBkZW11bHRpcGxleGluZyBJRHMgdG8gZW5hYmxlIG11bHRpcGxlDQo+ PiBjb25uZWN0aW9ucyB0byBhIGhvc3Qgd2l0aCBhIHNpbmdsZSBJUCBhZGRyZXNzLCBhbmQgKGZv ciBmaXJzdC1jb250YWN0DQo+PiBmcm9tIGNsaWVudCB0byBzZXJ2ZXIpIHRvIGluZGljYXRlIHRo ZSBkZWZhdWx0IHNlcnZpY2UgdGhhdCByZWNlaXZlcw0KPj4gaW5jb21pbmcgImZpcnN0IGNvbnRh Y3QiIHJlcXVlc3RzLg0KPj4gDQo+PiBZb3UgY291bGQgY2VydGFpbmx5IGRlZmluZSBhIG5ldyBz ZXJ2aWNlIHRoYXQgY29tYmluZXMgSFRUUFMgYW5kIEROUyBvbg0KPj4gYSBzaW5nbGUgcG9ydC4g Tm90ZSB0aGF0IFJGQzYzMzUgYW5kIFJGQzc2MDUgYm90aCByZWNvbW1lbmQgYWdhaW5zdA0KPj4g Y3JlYXRpbmcgbmV3IHBvcnRzIGZvciBleGlzdGluZyBzZXJ2aWNlcywgYnV0IGl0ICptaWdodCog YmUgYXJndWFibGUNCj4+IHRoYXQgdGhlIGNvbWJpbmVkIHNlcnZpY2UgaXMgc29tZWhvdyB1bmlx dWVseSBkaXN0aW5jdCAodGhhdCB3b3VsZCBuZWVkDQo+PiB0byBiZSBzdWNjZXNzZnVsbHkgYXJn dWVkLCB0aG91Z2gpLg0KPiANCj4gV2VsbCwgdGhpbmdzIGRvIGNoYW5nZS4gVGhlIG1vc3QgaW50 ZXJlc3RpbmcgdGhpbmcgdGhhdCB3ZSBkaWQgb2JzZXJ2ZQ0KPiBpcyB0aGUgZ2VuZXJhbGl6ZWQg dXNlZCBvZiBUTFMuIFRoZSBzdGFjayB1c2VkIHRvIGJlIElQL1RDUC9BcHAsIGFuZCBpbg0KPiB0 aGF0IGNhc2UgeW91IHJlYWxseSBuZWVkIHRvIGRlbXV4IGF0IHRoZSBUQ1AgbGF5ZXIsIGFuZCB5 b3UgY2FuIGRvIHRoYXQNCj4gdXNpbmcgcG9ydHMuIFRoZSBzdGFjayB0aGF0IHdlIGRvIGhhdmUg bm93IGlzIElQL1RDUC9UTFMvQXBwLCBvcg0KPiBJUC9RdWljL1RMUy9BcHAuIFdlIGNvdWxkIHN0 aWxsIGRlbXV4IGF0IHRoZSBUQ1AgbGF5ZXIsIGJ1dCB3ZSBjb3VsZA0KPiBhbHNvIGRlbXV4IGF0 IHRoZSBUTFMgbGF5ZXIuIEFzIERLRyBwb2ludHMgb3V0LCBkZW11eGluZyBhdCB0aGUgVExTDQo+ IGxheWVyIGRvZXMgaGlkZSBzb21lIG9mIHRoZSBtZXRhZGF0YSwgYW5kIHRodXMgcHJvdmlkZXMg YmV0dGVyIHByaXZhY3kNCj4gYW5kIHJlc2lzdGFuY2UgdG8gY2Vuc29yc2hpcCB0aGFuIGRlbXV4 aW5nIG9uIHRoZSBjbGVhciB0ZXh0IFRDUCBwb3J0Lg0KPiANCj4gT2YgY291cnNlLCBvbmUgb25s eSBnZXRzIHRoZSBwcml2YWN5IGJlbmVmaXRzIGlmIHRoZSBUTFMgZGVtdXhpbmcgaXMgbm90DQo+ IGJhc2VkIG9uIGNsZWFyIHRleHQgZmllbGRzIGxpa2UgdGhlIFNOSSBvciB0aGUgQUxQTi4gREtH IHByb3Bvc2VzIGFuDQo+IGhldXJpc3RpYywgYmFzZWQgb24gdGhlIG9ic2VydmF0aW9uIHRoYXQg dGhlIGZpcnN0IGJ5dGVzIG9mIGFwcGxpY2F0aW9uDQo+IGRhdGEgYXJlIGVub3VnaCB0byBkaWZm ZXJlbnRpYXRlIEhUVFAgYW5kIEROUy4gSGV1cmlzdGljcyBsaWtlIHRoZXNlDQo+IGhhdmUgdGhl IGFkdmFudGFnZSBvZiBiZWluZyBlYXNpbHkgZGVwbG95ZWQuIFRoZXkgZG8gaGF2ZSB0aGUNCj4g aW5jb252ZW5pZW50IG9mIGFmZmVjdGluZyB0aGUgbG9uZyB0ZXJtIGV2b2x1dGlvbiBvZiB0aGUg YXBwbGljYXRpb24NCj4gcHJvdG9jb2xzLiBXZSBtYXkgd2FudCB0byBsb29rIGF0IGEgcm9idXN0 IGxvbmcgdGVybSBhbHRlcm5hdGl2ZS4NCj4gDQo+IEhUVFAyIGFjdHVhbGx5IHRvb2sgYSBzdGVw IGluIHRoYXQgZGlyZWN0aW9uLiBUaGlzIGlzIHNwZWNpZmllZCBpbg0KPiBzZWN0aW9uIDMuNSBv ZiBSRkMgNzU0MC4gIkVhY2ggZW5kcG9pbnQgaXMgcmVxdWlyZWQgdG8gc2VuZCBhIGNvbm5lY3Rp b24NCj4gcHJlZmFjZSBhcyBhIGZpbmFsIGNvbmZpcm1hdGlvbiBvZiB0aGUgcHJvdG9jb2wgaW4g dXNlIGFuZCB0byBlc3RhYmxpc2gNCj4gdGhlIGluaXRpYWwgc2V0dGluZ3MgZm9yIHRoZSBIVFRQ LzIgY29ubmVjdGlvbi4gIFRoZSBjbGllbnQgYW5kIHNlcnZlcg0KPiBlYWNoIHNlbmQgYSBkaWZm ZXJlbnQgY29ubmVjdGlvbiBwcmVmYWNlLiIgVGhlIHNwZWMgZ29lcyBvbiB0byBzcGVjaWZ5IGEN Cj4gMjQgYnl0ZSBzdHJpbmcsIGNvcnJlc3BvbmRpbmcgdG8gdGhlIEFTQ0lJIHZhbHVlICJQUkkg Kg0KPiBIVFRQLzIuMFxyXG5cclxuU01cclxuXHJcbiIsIHdoaWNoIHRoZSBzZXJ2ZXIgYWNrbm93 bGVkZ2VzIGJ5IHNlbmRpbmcgYQ0KPiAiU0VUVElOR1MiIGZyYW1lLg0KPiANCj4gU28gbWF5YmUg d2UgY291bGQgYnVpbGQgb24gdGhhdCwgYW5kIGxldCBhcHBsaWNhdGlvbiByZWdpc3RlciB0aGVp cg0KPiBzcGVjaWZpYyAyNCBieXRlcyBzdHJpbmcsIGFsbG93aW5nIGZvciBkZW11eCBvbiB0b3Ag b2YgVExTLiBUaGF0IHdvdWxkDQo+IGRlZmluZSBhbiBvcmdhbml6ZWQgcHJvY2Vzcy4NCj4gDQo+ IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0DQo+IGRu cy1wcml2YWN5QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG5zLXByaXZhY3kNCg0K From nobody Thu Apr 27 12:20: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 0CA79129BF8 for ; Thu, 27 Apr 2017 12:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 tE4IeR1auJIM for ; Thu, 27 Apr 2017 12:20:43 -0700 (PDT) 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 C56D4129AD8 for ; Thu, 27 Apr 2017 12:17:36 -0700 (PDT) Received: from [169.254.185.61] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3RJHB0Z011790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 12:17:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.185.61] From: "Paul Hoffman" To: "Christian Huitema" Cc: "dns-privacy@ietf.org" Date: Thu, 27 Apr 2017 12:17:30 -0700 Message-ID: <222AE00F-6306-40DE-A97D-92FBB104389C@vpnc.org> In-Reply-To: <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:20:44 -0000 On 27 Apr 2017, at 11:51, Christian Huitema wrote: > So maybe we could build on that, and let application register their > specific 24 bytes string, allowing for demux on top of TLS. That would > define an organized process. ...which would not work at all for DNS, one of the two protocols being discussed here: the first two bytes are *supposed* to be non-predictable. --Paul Hoffman From nobody Thu Apr 27 12:32:41 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 28546126DFB for ; Thu, 27 Apr 2017 12:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 A5dmZqz-Y4HY for ; Thu, 27 Apr 2017 12:32:39 -0700 (PDT) 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 23A2C129ACD for ; Thu, 27 Apr 2017 12:29:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RJSnne028147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 12:28:50 -0700 (PDT) From: Joe Touch To: Christian Huitema , Hugo Maxwell Connery , Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: "dns-privacy@ietf.org" References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> <2fdf8430-1f43-60f5-5ca3-84ed58f1a19e@isi.edu> Message-ID: Date: Thu, 27 Apr 2017 12:28:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <2fdf8430-1f43-60f5-5ca3-84ed58f1a19e@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:32:40 -0000 On 4/27/2017 12:01 PM, Joe Touch wrote: > Hi, Christina, > > On 4/27/2017 11:51 AM, Christian Huitema wrote: PS - my sincere apologies to Christian. (spellcheck is evil ;-( Joe From nobody Thu Apr 27 12:36:51 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 71AE8129B8B for ; Thu, 27 Apr 2017 12:36:49 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 3q_Omf0Z8A1x for ; Thu, 27 Apr 2017 12:36:47 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 D3DC812944E for ; Thu, 27 Apr 2017 12:33:09 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d3pA4-0004Nv-4H for dns-privacy@ietf.org; Thu, 27 Apr 2017 21:33:09 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d3p9z-0004B8-QP for dns-privacy@ietf.org; Thu, 27 Apr 2017 15:33:07 -0400 Received: (qmail 4597 invoked from network); 27 Apr 2017 19:33:02 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Apr 2017 19:33:01 -0000 To: Marc.Mosko@parc.com References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> <79085D94-71CD-4DA7-A6A3-D6367D298EEE@parc.com> Cc: touch@isi.edu, hmco@env.dtu.dk, dkg@fifthhorseman.net, jv@fcelda.cz, dns-privacy@ietf.org From: Christian Huitema Message-ID: <354f835b-d79b-ccc2-bbe9-b76f5e5158c9@huitema.net> Date: Thu, 27 Apr 2017 12:32:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <79085D94-71CD-4DA7-A6A3-D6367D298EEE@parc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqtKYkLJHN3cyJ3wIUhgjuURcOb18WfxGyg6Om6u4YYm4TelN/v+TBeWy7l RzmqS+E5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0SxiupkAy /hjkuD503u5hjrbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/sV/ccPPAIzwUs9bYOpC55xe2m/FTnYaeKpf gOxdeQOhGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+b9mlnvEtfZrycMUgF0W/W/z0IiXE+0L8SRVLX+bQiWq X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:36:49 -0000 On 4/27/2017 12:13 PM, Marc.Mosko@parc.com wrote: > I think I=E2=80=99m missing something about this proposal, at least in = the case of a general demux protocol. If you detach TLS from a specific = application context, who provides the certificates and evaluates the trus= t anchors? If you don=E2=80=99t have a traffic secret, how do you hide t= he demux signaling? It seems like having a general purpose TLS demux wou= ld require delegating all that to some other process including the DH exc= hange? > > I can see how, as draft draft-dkg-dprive-demux-dns-http-00 puts it, a s= pecial terminator might offer two protocols of DNS and HTTP, but those ar= e both being offered by the same application that share the same TLS cred= entials, yes? Yes, very much. You would use the same certificate for all applications. This is probably OK in many cases. In the cases where that doesn't work, well, don't mix them on the same address and port. Of course, if I wanted to play devil's advocate, I would point out that the proposed scheme uses the same port for different applications, put results in separate connections for each application. Unless we do something really smart and difficult, the different applications will have somewhat different traffic patterns. The adversaries will be able to recognize that, and may then start some counter measures. It might be more robust to mix the two applications on the same TCP/TLS connection. If application messages are interleaved, traffic analysis becomes significantly harder. That the approach proposed in https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-http2/, or in https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/. We are really seeing many flowers blooming in this space... -- Christian Huitema From nobody Thu Apr 27 17:54:32 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 E698612714F for ; Thu, 27 Apr 2017 17:54:29 -0700 (PDT) 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 RuYib6clYCYl for ; Thu, 27 Apr 2017 17:54:28 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 5CE85128B92 for ; Thu, 27 Apr 2017 17:51:28 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id o76so901305vkc.2 for ; Thu, 27 Apr 2017 17:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t7SJt1oVGLReXs8aALp7B6fj4DplxsYP7vY999j+24A=; b=NAvXGWlA43fIaJrl5Ua67yUJNmiRHHZGsbtCUyanfuWHrrXKYRbR90dZdMlLxxIWgR YZ8miWEbBUsxxHxB2VLqjqbCOdrUeYQEqnZIHFlXZyPrpBH1angXE3MdTYOpKoKtPrxg LIMLSQFqgRCajvVzaplUWhHfx037HlSgU5rXrpbZnpFUTy9A4bUxyTGNzB5xOZxkSDoo yaRzcIMLKH29NSAW/qSv55hdsHSSof6MtSa45zvxcbaWVx0ctTcUv+8m+POtzKVd3lcX obkzP6vTRt9WWhU+jRqW6n1puHK0B2nuJaW6Woq0aER7X2JbNwHhOR6xqj2zaKwKPWGR tG5g== 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=t7SJt1oVGLReXs8aALp7B6fj4DplxsYP7vY999j+24A=; b=A6ebVtTGHPBms4LTbCykoUaxF2j5GriY06phOPkQc6OeLmAMTdUPH4pahE2uTtupQ4 r/LK3sARYzQY+azJlm+htqq1+bFiy1LxxG2UPY8E6Ri3LXxRuMfKDzw40ZblRME8ymDZ 33hSOxOSSlPuD0tZ2SOhIxGCbz+vSA+ptwCb3B4k/y9wRrpKvlaDvELPN4M6T5/aGYfb 7KUNSvgodF9KQXRvn7J3FCmGwkqpHXWQc82VgckBDuVSuasr3nukhLGSOOXjF1Vm2tgq KldWfHanAWHUtMQXzRnRERH/QGJQC9ZKNpqFo30jfANG9CncXS5qy09CAri7+eSInEla cI6w== X-Gm-Message-State: AN3rC/490tW5hxGajM2K0f6j41jK35G2l+Pzgrun6Co/XpY8ZAgToBQX t7kcVqvI6GhRDKDNfU6Us3oyinX5+A== X-Received: by 10.31.8.144 with SMTP id 138mr4286277vki.144.1493340687496; Thu, 27 Apr 2017 17:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.197 with HTTP; Thu, 27 Apr 2017 17:51:26 -0700 (PDT) In-Reply-To: <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> From: Shumon Huque Date: Thu, 27 Apr 2017 20:51:26 -0400 Message-ID: To: Christian Huitema Cc: Joe Touch , Hugo Maxwell Connery , Daniel Kahn Gillmor , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= , "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary=001a1144f28634ff7d054e2f79d1 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 00:54:30 -0000 --001a1144f28634ff7d054e2f79d1 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 2:51 PM, Christian Huitema wrote: > > [...] > > Of course, one only gets the privacy benefits if the TLS demuxing is not > based on clear text fields like the SNI or the ALPN. DKG proposes an > heuristic, based on the observation that the first bytes of application > data are enough to differentiate HTTP and DNS. Heuristics like these > have the advantage of being easily deployed. They do have the > inconvenient of affecting the long term evolution of the application > protocols. We may want to look at a robust long term alternative. > Perhaps we should revisit the decision not to encrypt the ALPN extension (NPN redux?). It seems that might have helped use cases like these in the more robust manner. -- Shumon Huque --001a1144f28634ff7d054e2f79d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 27, 2017 at 2:51 PM, Christian Huitema <huitema@huitema.net&= gt; wrote:

[...]

Of course, one only gets the privacy benefits if the TLS demuxing is not based on clear text fields like the SNI or the ALPN. DKG proposes an
heuristic, based on the observation that the first bytes of application
data are enough to differentiate HTTP and DNS. Heuristics like these
have the advantage of being easily deployed. They do have the
inconvenient of affecting the long term evolution of the application
protocols. We may want to look at a robust long term alternative.

Perhaps we should revisit the decision not to en= crypt the ALPN=C2=A0
extension (NPN redux?). It seems that might = have helped use cases
like these in the more robust manner.
=

--=C2=A0
Shumon Huque

--001a1144f28634ff7d054e2f79d1-- From nobody Thu Apr 27 18: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 CD47312948A for ; Thu, 27 Apr 2017 18:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 eCN4B6TP0d7T for ; Thu, 27 Apr 2017 18:24:32 -0700 (PDT) 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 88E56129C27 for ; Thu, 27 Apr 2017 18:21:44 -0700 (PDT) Received: from [169.254.221.140] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3S1LLai023162 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 18:21:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.221.140] From: "Paul Hoffman" To: "Shumon Huque" Cc: "dns-privacy@ietf.org" Date: Thu, 27 Apr 2017 18:21:40 -0700 Message-ID: In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 01:24:33 -0000 On 27 Apr 2017, at 17:51, Shumon Huque wrote: > Perhaps we should revisit the decision not to encrypt the ALPN > extension (NPN redux?). The term "we" is probably not appropriate here. It was not this WG that made that decision: it was the TLS WG, after multiple threads with (I believe) hundreds of messages. > It seems that might have helped use cases > like these in the more robust manner. Yes, that was the whole point of NPN; in the end it was not persuasive to the TLS WG. --Paul Hoffman From nobody Thu Apr 27 18:33:17 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 54C9E128DF6 for ; Thu, 27 Apr 2017 18:33:16 -0700 (PDT) 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 FT8VGDzJA7vZ for ; Thu, 27 Apr 2017 18:33:15 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 2C03412953F for ; Thu, 27 Apr 2017 18:30:56 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id o76so1204235vkc.2 for ; Thu, 27 Apr 2017 18:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T2EUTzsSPrr3Vwydcq+NBoW4MN6Xu8O6XhkJ/yIyn0I=; b=foT5HEhXSGwhbjoHbAmsU/pSUgr8MVucaq5l/RtX+bG6lQxZiWwSobNFiU5v7gmm+V esh6JwGO+UIfL8IEVzwERZHwNyeevN9k9fddpK7SlBjbgd8En+eA5FQKvgL/2EXeED3O s66ChwY3jUIvOArGumbssFPXpNjUup65AbKL3mKaHvrcXhUSjdH+lrIoKDyKwrIIAlAl cYKVnbgA7DNETf0b2pfFpi8jcGxQAjJhZ4f4Tv5geYb0jvpXorDvV/5iqVdinCsgPrXZ H8AFijsBOO3rn1ozgj8b9vLlMffNDX4Zw8sYJ8lLKNIsgswYcx7GwejHpia5q491LLyu nAfw== 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=T2EUTzsSPrr3Vwydcq+NBoW4MN6Xu8O6XhkJ/yIyn0I=; b=l2E/C/jVMzeoe82pi//j+sQy7UqO8K+T6At3Sll5hn+ugsgnHI+pnY5wmCTQGoN/Oy Zw/o2EDSgafgrEjvg1N9WkFaY5FDcxxnL1eHG4EE0HF2xTy0C2Hvmpt1OODbO5rUVkES KUVgGfO3ggSjrdgDfp0uKQmj5n0EdJkXM3CCIw/5+kSa/75lQU1G22kfJNGZH9rx1sYt WpiGaZj7bj3OzXmoj/fqUJkcEn7QBKqmccfdJ7nXWM13DYkD07AVMBo5Wt0sZUPsT83f G19fGyHnQXWVlZMh7RbgZ0qou+0vamEKd35hi+6y6cStvpOUhYC40i65DYTPOjhJ9Oqf GFJg== X-Gm-Message-State: AN3rC/7FktbkWVESy/2OgkRabWpIa+6bFsu/CJRrVpi3VMCyxxhgqEa6 rfB6UQ3feOHQVsMz/WiDkU7uM3Eytw== X-Received: by 10.31.16.209 with SMTP id 78mr4498672vkq.29.1493343055347; Thu, 27 Apr 2017 18:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.197 with HTTP; Thu, 27 Apr 2017 18:30:54 -0700 (PDT) In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> From: Shumon Huque Date: Thu, 27 Apr 2017 21:30:54 -0400 Message-ID: To: Paul Hoffman Cc: "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary=001a1143672457889b054e300677 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 01:33:16 -0000 --001a1143672457889b054e300677 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 9:21 PM, Paul Hoffman wrote: > On 27 Apr 2017, at 17:51, Shumon Huque wrote: > > Perhaps we should revisit the decision not to encrypt the ALPN >> extension (NPN redux?). >> > > The term "we" is probably not appropriate here. It was not this WG that > made that decision: it was the TLS WG, after multiple threads with (I > believe) hundreds of messages. Yeah, I should have been more precise. By "we", I was referring to TLS or perhaps the larger IETF community (and not DPRIVE) .. -- Shumon Huque --001a1143672457889b054e300677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 27, 2017 at 9:21 PM, Paul Hoffman <paul.hoffman@vpnc.org&g= t; wrote:
On 27 A= pr 2017, at 17:51, Shumon Huque wrote:

Perhaps we should revisit the decision not to encrypt the ALPN
extension (NPN redux?).

 The term "we" is probably not appropriate here. It was not this W= G that made that decision: it was the TLS WG, after multiple threads with (= I believe) hundreds of messages.

Yeah, I sh= ould have been more precise. By "we", I was referring to TLS or p= erhaps the larger IETF community (and not DPRIVE) ..

--=C2=A0
Shumon Huque

--001a1143672457889b054e300677-- From nobody Fri Apr 28 00:45:30 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 E1A2812951C for ; Fri, 28 Apr 2017 00:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZOznzj4JkjCj for ; Fri, 28 Apr 2017 00:45:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D61AC1298A1 for ; Fri, 28 Apr 2017 00:42:36 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id 9AFF3F993; Fri, 28 Apr 2017 03:42:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 69B9A2009E; Fri, 28 Apr 2017 03:42:25 -0400 (EDT) From: Daniel Kahn Gillmor To: Paul Hoffman , Christian Huitema Cc: "dns-privacy\@ietf.org" In-Reply-To: <222AE00F-6306-40DE-A97D-92FBB104389C@vpnc.org> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> <222AE00F-6306-40DE-A97D-92FBB104389C@vpnc.org> Date: Fri, 28 Apr 2017 00:42:22 -0700 Message-ID: <87k2655675.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 07:45:29 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2017-04-27 12:17:30 -0700, Paul Hoffman wrote: > On 27 Apr 2017, at 11:51, Christian Huitema wrote: > >> So maybe we could build on that, and let application register their >> specific 24 bytes string, allowing for demux on top of TLS. That would >> define an organized process. > > ...which would not work at all for DNS, one of the two protocols being=20 > discussed here: the first two bytes are *supposed* to be=20 > non-predictable. itym (zero-based) octets 2 and 3 are *supposed* to be non-predictable, since the first two bytes of stream-based DNS are the message length, which is definitely *not* supposed to be non-predictable. Out of curiosity, though: is the DNS message ID supposed to be non-predictable for stream-based DNS as well? My understanding of the message id is that it was originally intended to allow servers and clients to identify and associate queries and responses that already share the same 5-tuple (transport protocol, source addr, source port, destination addr, destination port). That initial intent doesn't require non-predictability, just good bookkeeping :) But I know that a subsequent requirement for non-predictability of the DNS query message ID has arisen as a defense against off-path spoofed DNS responses: an unpredictable message ID in the query increases the entropy that an off-path spoofer attacker needs to guess from ~16 bits (UDP port only) to ~32 bits (UDP port + message ID). But does the non-predictability requirement hold in stream-based DNS, where the establishment of the stream itself provides at least as good protection against spoofed responses? If it holds in cleartext stream-based DNS, does it also hold for encrypted, streamed DNS, where the channel itself provides significantly *better* protection against spoofed responses. (again, i'm not arguing that exisiting clients *should* change their message id selection for purposes of this draft; i don't think they need to! But i'm wondering if the transport layer(s) we're talking about actually obviate the typical need for strong message ID randomizaton) --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkC8l4ACgkQFJitxsGS Mjcj4xAAueR5JtPX9+AISJ9nrSp92incwxXmenJv0pvXdGtsbQlO76hVmimvYPBF +aNDEpXolVEbjt60uBk6wg8eM3U8mBQgsLqO60jAyMd5TTnYFnmnaJLGhIj6sf6i G0w7nccB9rok/1kf7GQ97OkXj27fysjV0KOt5h5/0efjfsg3TkUtjEFVQUqRStyi 3IniabevvxlC74ih+IreAofcdKw6Ql4rXZO/I1XrjtzEvOU04T5yJRYuBIbH114I gKiOypxImw5qWsW1rgg9G3MYEczQGJmi74ioR7ALbjxBsGYCCqmy+oJx50PD5A+p FxqBT4yuy1LwR9zThM9+6Gm09q6iDxJpJ/HuROrllGtf4kRhs3f3buA/X6NH2TR8 7uUVmRFdi8UoEQ1hxx/1WZ15y8q6WGkmQ45QgitMACmIpE+KIbCIRtVM0EJUO7Bd pfDCwgicoSi2r3bUc6/Xt8Nu2Y4RJzATU2QLhVbR6Ejdfq5OOc+83n5HvRTLoypF VMtQ4iT/E/VEM2oieyGn5fQSZtBG+BOU6pc0XlPp3jlKgLx4bE0I9rT+BDMyV0t2 eM4JyfuLfX/mqzfIfbI0KWPiv8SnJOTjSTgk/4m+6KL8Z/7RXKF6RQPleXs/OlcB hCIUd4tc963OiYd35alZq/HMOuBwRVCrYXa15m+fL+Dgy7fRrtc= =QPnK -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 28 00:45:47 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 1C007129537 for ; Fri, 28 Apr 2017 00:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fgS9V4_f0c2x for ; Fri, 28 Apr 2017 00:45:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D627C129C68 for ; Fri, 28 Apr 2017 00:42:36 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id DB806F99A; Fri, 28 Apr 2017 03:42:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0F1DA1FFB8; Fri, 28 Apr 2017 02:58:28 -0400 (EDT) From: Daniel Kahn Gillmor To: Joe Touch Cc: dns-privacy@ietf.org In-Reply-To: <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> Date: Thu, 27 Apr 2017 23:58:24 -0700 Message-ID: <87shkt588f.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 07:45:30 -0000 --=-=-= Content-Type: text/plain Hi Joe-- Thanks for the feedback! On Thu 2017-04-27 10:13:54 -0700, Joe Touch wrote: > Speaking as an IANA ports team reviewer: > > IMO this document needs to UPDATE the HTTPS specification. The draft isn't strictly about HTTPS, though that context is certainly a prime motivating factor. It's about demultiplexing cleartext, streamed DNS from cleartext, streamed HTTP. This just happens to mainly be useful in evading network surveillance and censorship under cover of TLS :) That said, i definitely agree that the draft needs more input from the HTTP community. In particular, if this approach gets deployed widely, we'd want to ensure that future stream-based versions of HTTP are aware of this demuxing algorithm and don't create a start-of-stream signature that the algorithm might confuse with DNS. But will there be future stream-based versions of HTTP? afaict, HTTP-over-QUIC is likely to be the future of HTTP, and that's a place where this demuxing approach explicitly does not apply (since it's not stream-based). So maybe it'll turn out that the draft doesn't scare the HTTP community much. We should encourage their review! I initially sent the doc for discussion here in DPRIVE because DPRIVE offers one of the primary motivations for the work, and to make sure i wasn't missing anything crucial from the DNS side. But i'm certainly planning to bring the document to the attention of HTTP-specific groups. Perhaps httpbis@ietf.org comes next? I'm open to other suggestions. > Keep in mind that any bit pattern that you *think* differentiates DNS > from HTTPS is not yours to define - it is the purview of HTTPS to define > or delegate in any way they see fit. I hope it's clear from the draft that it's not defining any differentiating bit pattern. Rather, it's pointing out that the existing specifications *already* define necessarily distinguishable bit patterns. > You can certainly ask IANA for a new port on which to run both HTTPS and > DNS, but it is inappropriate to change port 443 without coordination. This seems unlikely to achieve any useful goal -- existing HTTPS isn't going to move to a new port, which means traffic on that port would be suspect to a would-be censor or a pervasive monitor, right? Joe, as a thought experiment, as an IANA ports reviewer, if both the HTTP and DNS communities were to decide that some version of draft seems OK to them, what would you want the IANA Considerations section to look like? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkC6BAACgkQFJitxsGS Mje1Ng/8CQvUljAW+82UHKuav5BVSmm1DhpNMYFKv0gdpPSdk8De80LIHC+YoKcs H7adCczw8RiCnqIA5ViCjqcBsciZGC4gpjcEgH6oJIhufJIc8xeP1JbLfWnVK0MS woVNDOXthP+I5ctU4tV/YYtReYXmAPcuWAg2oYf2YNP15KSxVhSnK4cHcoMygBfo XNNCyUZJaRLEdy+S2QsGw1PaFBDjpEn5ztUVaN3vlKj1e2jBeyT/BiEevrZfeG57 ahVSBOWnbQ/j165ofMcruAnYLQtvPvBPDgHFYE8gYPR3uEloZzTZl2ze0HjGwCTc 54d0v3vvdjPJ1Jf3TKaHjiHWuv709JUblpJ5x1YX4LFP4udYDsp83dJLY7hPg7Md NlJ+xWHzOts2cNSwYhn53L8g4cX0mP1djR5SUVXMwmsB8q66fZ2EufL0jE22Mn4R Uz00CYYCGa1jYjg3GkOv1Id7O67+WgTUWyzB7itPfYhHRqHuA+lpmCmTuAVFrLPA pkFC2ObjzNFOD8aGQUAiRlnKEqxNQAaFAlnyDozxuZ2++WmX2c/e6v6ZI3I6oi+c hCkPJa0XekfO1wZv4SPsqyc8EGO6VR60YyW372iX0nXoD8DVGnFwfuj2vQsKHi1J JiqB5rTetJb6eGw5IhsBjgDp/NE4o4Yqz4G8ly0PXcdnnsnuDi8= =UIX2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 28 00:47:31 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 4E79B127337 for ; Fri, 28 Apr 2017 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Y9e9ZQsC_NvF for ; Fri, 28 Apr 2017 00:47:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 966F612D574 for ; Fri, 28 Apr 2017 00:44:21 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id DCF42F98C; Fri, 28 Apr 2017 03:44:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 13AF22002E; Fri, 28 Apr 2017 03:14:33 -0400 (EDT) From: Daniel Kahn Gillmor To: Hugo Maxwell Connery Cc: dns-privacy@ietf.org In-Reply-To: <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> Date: Fri, 28 Apr 2017 00:14:29 -0700 Message-ID: <87pofx57hm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 07:47:30 -0000 --=-=-= Content-Type: text/plain On Thu 2017-04-27 17:34:27 +0000, Hugo Maxwell Connery wrote: > Should we mandate that all future protocols are "demuxible" from > all previous? fwiw, i'm not prepared to make any kind of statement anywhere near that grand, and i'd hope that the specific proposal under discussion doesn't hinge on us having to make such sweeping analysis. What are "all previous protocols", for example? does it need to be demuxable from tcpmux itself? or what about RFC 862? ;) In particular, the approach i've described in the draft only works for client-speaks-first, stream-based protocols. It doesn't work at all for server-speaks-first protocols like SMTP or SSH, for example, and it doesn't address non-stream-based protocols at all. The proposed approach is situated in the particular historical circumstance we find the Internet in today. It'd be great if it wasn't necessary to consider it (if there were no networks actively hostile to user privacy and "surprising" ports, for example), and hopefully future Internet transport protocols can be demuxed at the server in a way that is opaque to the network operator in the first place, so that problems like this don't arise. I'm happy to have the bigger-picture discussion about how to plan for the future, but i hope this particular draft can be evaluated on its own merits (or lack thereof), largely independent of that discussion. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkC69YACgkQFJitxsGS Mjflrg//arMB9InSOuH6TS4AxWXHAncq1BiOKHx4Up1ObFX/OcKKbMfG+CAHUA6p dL2ywaFKWcg76WP9gVqAr5ss68JuGmtKx3K3JRiyz/tHyFwxkBbVsXHIVg/XN8a+ peoYEU6X/PjZBD4/J4MaNGLaBEsv4wBADDba/38uZyzquC+xTG05CUw60FinO3mz IP8jMqdDjxhg2lKvCcomAfEIzFSZJZ+c54XLHUit2anUckKSTHzNzLSZNIDFWk1I sTVG8Fl++b0qYlq2fKL1j6xd0567zAl4PM4zVO4sYLATwH1TkYQ/TYroiMPTXxUz nVzF6Ru7dN7u9WkeBFFfCtdWy6HQ9CXiWkD+EoV0rz7k1UEgAU7kd3cyHvLnEzMl LKakCfk94KZrlqOFYCJpqsbTb30gIqSkJgfJtD1PxypNfEu7ru1Rweg4X/qM/V9b rkbA2j3CX7Qx8o+DROp3/7f8Y8/MykiFVf7DrO/Rsf+1uQWo9W/Fl4DlNJHY0guW Anp9glSkFL0CnuYrQ34irO2mKmqSs2WBLmJOjybu8t5o0z0l+wPKBXtejRoirpZp ehkxd/fDPX+taLvn3YSl7aWAbNMssU4xIVmxTr1rNKj9j0qvlREZjCO+xR8ukitN vuoVY+8aIRpQGN0UFgpu0qiRAfanep2kgjevV2Fwla859VJA9Qk= =ci7r -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 28 01:18: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 6EF2B129C04 for ; Fri, 28 Apr 2017 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 57J0XeO3YUvg for ; Fri, 28 Apr 2017 01:18:01 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B51B129454 for ; Fri, 28 Apr 2017 01:15:20 -0700 (PDT) Received: from [46.227.151.81] (port=53320 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1d413d-0005wJ-Og (Exim 4.72) for dns-privacy@ietf.org (return-path ); Fri, 28 Apr 2017 09:15:17 +0100 To: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> <222AE00F-6306-40DE-A97D-92FBB104389C@vpnc.org> <87k2655675.fsf@fifthhorseman.net> From: Ray Bellis Message-ID: Date: Fri, 28 Apr 2017 09:15:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87k2655675.fsf@fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:18:02 -0000 On 28/04/2017 08:42, Daniel Kahn Gillmor wrote: > But does the non-predictability requirement hold in stream-based DNS, > where the establishment of the stream itself provides at least as good > protection against spoofed responses? If it holds in cleartext > stream-based DNS, does it also hold for encrypted, streamed DNS, where > the channel itself provides significantly *better* protection against > spoofed responses. What if the stream is being unwrapped before it reaches the eventual destination, e.g. a hypothetical TLS endpoint that forwards the received queries over UDP ? Who's responsibility is it to make sure those forwarded queries can't be spoofed? It's a stretch, I know, but the point is to make us consider how removing security features might have unintended consequences upstream. Ray From nobody Fri Apr 28 02:38: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 E95181294FD for ; Fri, 28 Apr 2017 02:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 Yn7AbD_52sMT for ; Fri, 28 Apr 2017 02:38:46 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 36256129AC9 for ; Fri, 28 Apr 2017 02:36:10 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:56690) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1d42Jr-0001e8-lE (Exim 4.89) (return-path ); Fri, 28 Apr 2017 10:36:07 +0100 Date: Fri, 28 Apr 2017 10:36:07 +0100 From: Tony Finch To: Daniel Kahn Gillmor cc: dns-privacy@ietf.org In-Reply-To: <87bmrh7vz1.fsf@fifthhorseman.net> Message-ID: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <87bmrh7vz1.fsf@fifthhorseman.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 09:38:49 -0000 Daniel Kahn Gillmor wrote: > > (though not the result, since octet 5 will be zero for DNS). > > Is that guaranteed? Er, in fact, no. I forgot about the AD and CD flags, so I think in practice you are likely to see octet 5 values of 0x00 0x10 0x20 0x30 Probably on more solid ground to assume QDCOUNT == 1 :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Wight, Portland: Northwest 4 or 5, becoming variable 4. Smooth or slight. Showers. Good. From nobody Fri Apr 28 08:55:08 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 E9686129521 for ; Fri, 28 Apr 2017 08:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 1DMazGb7Hvdv for ; Fri, 28 Apr 2017 08:55:05 -0700 (PDT) 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 1B56B12EACD for ; Fri, 28 Apr 2017 08:51:42 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SFojGc025401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 08:50:47 -0700 (PDT) To: Daniel Kahn Gillmor , Hugo Maxwell Connery Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <87pofx57hm.fsf@fifthhorseman.net> From: Joe Touch Message-ID: <39da69d3-856b-df86-88ba-055ae235d1cf@isi.edu> Date: Fri, 28 Apr 2017 08:50:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <87pofx57hm.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:55:07 -0000 Hi, Daniel, On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote: > In particular, the approach i've described in the draft only works for > client-speaks-first, stream-based protocols. I don't think you can assert that it works except where you have checked, and only for the *current* definition of those protocols. Keep in mind that ports are assigned to current *and all future* versions of a protocol, so all bets are off the instant you stop looking. Which means, effectively, that you can never assert that this works on an existing port assignment UNTIL you coordinate with that port's assignee, and they confirm that their service will never conflict with your definition. That also implies that this service cannot be defined as valid for any service that isn't already assigned. That would effectively be squatting on the entire port space. Joe From nobody Fri Apr 28 09:02:34 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 DEB4E12EAB2 for ; Fri, 28 Apr 2017 09:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 zK5fMse1NfdU for ; Fri, 28 Apr 2017 09:02:31 -0700 (PDT) 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 A725012941C for ; Fri, 28 Apr 2017 08:58:28 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SFvegk026206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 08:57:42 -0700 (PDT) To: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> From: Joe Touch Message-ID: Date: Fri, 28 Apr 2017 08:57:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <87shkt588f.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:02:33 -0000 Hi, Daniel, On 4/27/2017 11:58 PM, Daniel Kahn Gillmor wrote: > ... > The draft isn't strictly about HTTPS, though that context is certainly a > prime motivating factor. > > It's about demultiplexing cleartext, streamed DNS from cleartext, > streamed HTTP. This just happens to mainly be useful in evading network > surveillance and censorship under cover of TLS :) > > That said, i definitely agree that the draft needs more input from the > HTTP community. In particular, if this approach gets deployed widely, > we'd want to ensure that future stream-based versions of HTTP are aware > of this demuxing algorithm and don't create a start-of-stream signature > that the algorithm might confuse with DNS. That's the key - you need to know that port 443 and 80 are defined by HTTP, not this document. If you want to define a service without any coordination, you certainly can propose to merge the current definitions of DNS and HTTP/HTTPS and see whether that qualifies for a port assignment. But you cannot redefine a port belonging to another party. ... >> Keep in mind that any bit pattern that you *think* differentiates DNS >> from HTTPS is not yours to define - it is the purview of HTTPS to define >> or delegate in any way they see fit. > I hope it's clear from the draft that it's not defining any > differentiating bit pattern. Rather, it's pointing out that the > existing specifications *already* define necessarily distinguishable bit > patterns. That's like saying that I can take your car because you're not currently in it. Ports 80 and 443 belong to HTTP/HTTPS. They *own* ***ALL*** current and future bit patterns on that port. The same is true for all other current assignments. And all unassigned or reserved ports (from the assignable ranges) are effectively owned by IANA until they are assigned. Under no condition is it appropriate for this or any other document to define the meaning of a bit pattern on any port **EXCEPT** those assigned to that service. > >> You can certainly ask IANA for a new port on which to run both HTTPS and >> DNS, but it is inappropriate to change port 443 without coordination. > This seems unlikely to achieve any useful goal It preserves the integrity of HTTP and HTTPS, and ensures that those protocols can use whatever bit pattern they want for future variants. > -- existing HTTPS isn't > going to move to a new port, which means traffic on that port would be > suspect to a would-be censor or a pervasive monitor, right? All traffic on the Internet is already subject to censorship and monitoring. I can't see how you can traverse someone else's link or router without that possibility, regardless of port. > Joe, as a thought experiment, as an IANA ports reviewer, if both the > HTTP and DNS communities were to decide that some version of draft seems > OK to them, what would you want the IANA Considerations section to look > like? IMO, either: a) a request for a new assignment (listed as TBD in this document until assigned; please do not squat on an unassigned port that might be assigned in the meantime) or b) if you want to redefine an existing service on a currently assigned port, a clear indication in the doc header, abstract, intro, content, and IANA sections that this doc updates HTTP or HTTP, or whatever service you want this to update. (which would require confirmation by IANA in contact with the current assignee). Joe From nobody Fri Apr 28 09:56:24 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 18FC012EAF4 for ; Fri, 28 Apr 2017 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HoUky5DSv0-2 for ; Fri, 28 Apr 2017 09:56:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2912EAF8 for ; Fri, 28 Apr 2017 09:52:53 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id 9FC0FF997; Fri, 28 Apr 2017 12:52:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 84F332003A; Fri, 28 Apr 2017 12:52:46 -0400 (EDT) From: Daniel Kahn Gillmor To: Joe Touch Cc: dns-privacy@ietf.org In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> Date: Fri, 28 Apr 2017 09:52:43 -0700 Message-ID: <87wpa44gpw.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:56:23 -0000 --=-=-= Content-Type: text/plain On Fri 2017-04-28 08:57:39 -0700, Joe Touch wrote: >> -- existing HTTPS isn't going to move to a new port, which means >> traffic on that port would be suspect to a would-be censor or a >> pervasive monitor, right? > > All traffic on the Internet is already subject to censorship and > monitoring. I can't see how you can traverse someone else's link or > router without that possibility, regardless of port. To clarify any miscommunication, i said *suspect* (in the sense of "suspicious"), not *subject*. One of the aims of the draft is to make the two protocols less distinguishable from one another to a network attacker who might prefer one over the other (and consider the other to be suspicious). A new port assignment fails to meet that goal. Of course users are subject to censorship and monitoring by networks that they rely on. This power imbalance between network operator and user is part of the way that digital transport works. We can try to even out this power imbalance by demonstrating mechanisms for the user to make their traffic indistinguishable from other traffic and opaque to the network operator -- that way the operator cannot target them for censorship or surveillance without incurring heavy collateral damage. The goal of this WG is to provide confidentiality to the DNS querier against a network attacker. If every mechanism that we produce can be identified by a network adversary who wants to violate that confidentiality, then the adversary can simply kill that traffic, causing the user to fall back to cleartext DNS or to leave the network entirely. This draft is trying to defend against that scenario, which is why i brought it here first. Your points are noted, thanks, and i'll branch the discussion and start talking with the HTTP folks soon. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkDc1sACgkQFJitxsGS MjdCMw/8CIvr38wVIm/2yuj30YOSWlk8R/2MooT3mc9nEqQ0wzzelZu7YYec+S5k zfODzXSTPj/KLplmu2L7Rdiz9FRfwzAWvkvdkCkwdoYWhWvuuAEikYMQreFsJW2D 6UbD6TKInXpPhiY1KMNh4W5jXtpsmn1lkkro30LhxXgoWxfvPu7F7QZzZajwzR02 ZNNhV+sjh5eZCtcK1O/cfkywzWFOtjcFtlkdrmenV5M4ODc8QFDODp05AZ3jJpfV GGCVHw9Ohv8AxBxSYFuMUk02B2lKxeIGH5pWpGtCILLCrppoOtlYqY5dIKY6ZT7o 4Gt+/nPzDSXILHRIf1xCtfIz93s/Y3jdQ3lA+l9qFlQi/LE0uvn8sdb40JHkxRFA CJs9fP1QK1K1KplWaRvatNu/kEhrMWc7X8OlMYLjP3EGr4BrmC4Fodr6yNrREssY Y3leM9OaC4OvqWeKgvRBpp7Sl6xxwhdnhrb3kRQDGwoT5DX00XVHB0rFzgr2YChK Cg5mM0wJvlO36sdduBJYjxp09vYXTsiXPk77yEy7A3ryHAq2B26tBV5jBXlOjfjW DR7+Zsr55FQGfgBZ+lnZLuBq5Jh4OPlwJsZ8nG5H5A7/l2Y7Mk0dce85+z9EkXmk t+IDqxMUJ8e5e8L1DoQ0RG++cis2e5UB6ia7OwpdOy0hOuL/JpE= =yMYI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 28 09:56:32 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 479AE129C4E for ; Fri, 28 Apr 2017 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 claWT99YsSfu for ; Fri, 28 Apr 2017 09:56:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 69BEC12EAF5 for ; Fri, 28 Apr 2017 09:52:53 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id ABF44F999; Fri, 28 Apr 2017 12:52:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C3C471FDED; Fri, 28 Apr 2017 12:19:14 -0400 (EDT) From: Daniel Kahn Gillmor To: Ray Bellis , dns-privacy@ietf.org In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <3012b70b-3989-1051-6d6d-e79c9b31ecf8@huitema.net> <222AE00F-6306-40DE-A97D-92FBB104389C@vpnc.org> <87k2655675.fsf@fifthhorseman.net> Date: Fri, 28 Apr 2017 09:19:14 -0700 Message-ID: <8760ho5wu5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:56:24 -0000 On Fri 2017-04-28 09:15:18 +0100, Ray Bellis wrote: > On 28/04/2017 08:42, Daniel Kahn Gillmor wrote: > >> But does the non-predictability requirement hold in stream-based DNS, >> where the establishment of the stream itself provides at least as good >> protection against spoofed responses? If it holds in cleartext >> stream-based DNS, does it also hold for encrypted, streamed DNS, where >> the channel itself provides significantly *better* protection against >> spoofed responses. > > What if the stream is being unwrapped before it reaches the eventual > destination, e.g. a hypothetical TLS endpoint that forwards the > received queries over UDP ? > > Who's responsibility is it to make sure those forwarded queries can't be > spoofed? hm, good point. If the UDP endpoint is spoofable/injectable (e.g. over an untrusted network) I'd say that the thing converting from a stream to a UDP stream is at fault -- it doesn't know what assumptions the client is making about the transport. > It's a stretch, I know, but the point is to make us consider how > removing security features might have unintended consequences upstream. yep, if we decide to explicitly discourage non-predictability for the client in this context (i don't think we need to), then the Security Considerations should mention for the server that it should *not* assume that the message IDs are unpredictable, and so shouldn't do things like forward the packets over a link that doesn't have the same protections. --dkg From nobody Fri Apr 28 10:05:20 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 C1BD11294F3 for ; Fri, 28 Apr 2017 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nRE22h0Mf_Bf for ; Fri, 28 Apr 2017 10:05:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4380D12EB0B for ; Fri, 28 Apr 2017 10:01:36 -0700 (PDT) Received: from fifthhorseman.net (unknown [8.10.146.10]) by che.mayfirst.org (Postfix) with ESMTPSA id 5A3D7F98C; Fri, 28 Apr 2017 12:52:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A01F41FF20; Fri, 28 Apr 2017 12:23:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Joe Touch , Hugo Maxwell Connery Cc: dns-privacy@ietf.org In-Reply-To: <39da69d3-856b-df86-88ba-055ae235d1cf@isi.edu> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <87pofx57hm.fsf@fifthhorseman.net> <39da69d3-856b-df86-88ba-055ae235d1cf@isi.edu> Date: Fri, 28 Apr 2017 09:23:24 -0700 Message-ID: <8737cs5wn7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:05:19 -0000 On Fri 2017-04-28 08:50:44 -0700, Joe Touch wrote: > On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote: >> In particular, the approach i've described in the draft only works for >> client-speaks-first, stream-based protocols. > > I don't think you can assert that it works except where you have > checked, and only for the *current* definition of those protocols. right, it only "works" in the sense that i've documented how existing versions are demultiplexable. In the text you quote above, i wasn't saying it works for *all* client-speaks-first, stream-based protocols, i was saying that it *can't* work for non-stream protcols, or for protocols where the server speaks first. > Keep in mind that ports are assigned to current *and all future* > versions of a protocol, so all bets are off the instant you stop > looking. Which means, effectively, that you can never assert that this > works on an existing port assignment UNTIL you coordinate with that > port's assignee, and they confirm that their service will never conflict > with your definition. i think we're in violent agreement here :) > That also implies that this service cannot be defined as valid for any > service that isn't already assigned. That would effectively be squatting > on the entire port space. I don't think i understand what you're saying here. The document is about how a server can distinguish between existing versions of DNS and existing versions of HTTP. it's not making any claims about any other service. are you suggesting that it is making such a claim? --dkg From nobody Fri Apr 28 10:10:31 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 53140129B06 for ; Fri, 28 Apr 2017 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 qa_3_RXN_ZKw for ; Fri, 28 Apr 2017 10:10:29 -0700 (PDT) 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 752F51292C5 for ; Fri, 28 Apr 2017 10:06:28 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SH6BNd006756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2017 10:06:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14E304) In-Reply-To: <8737cs5wn7.fsf@fifthhorseman.net> Date: Fri, 28 Apr 2017 10:06:11 -0700 Cc: Hugo Maxwell Connery , dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02A386C7-D8A5-4577-8220-425906469CF0@isi.edu> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <6CB05D82CE245B4083BBF3B97E2ED470344D56BE@ait-pex01mbx01.win.dtu.dk> <87pofx57hm.fsf@fifthhorseman.net> <39da69d3-856b-df86-88ba-055ae235d1cf@isi.edu> <8737cs5wn7.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:10:30 -0000 > On Apr 28, 2017, at 9:23 AM, Daniel Kahn Gillmor w= rote: >=20 >=20 >> That also implies that this service cannot be defined as valid for any >> service that isn't already assigned. That would effectively be squatting >> on the entire port space. >=20 > I don't think i understand what you're saying here. The document is > about how a server can distinguish between existing versions of DNS and > existing versions of HTTP. it's not making any claims about any other > service. are you suggesting that it is making such a claim? I'm saying that the statement that it works now is just that. It can't be a standard. It can't be a bcp. I don't see how it can be a WG do= c outside of HTTPbis. IMO it falls under the "hazard to the Internet" part where it might not even= qualify as a valid individual submission. Joe From nobody Fri Apr 28 10:13:56 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 598E112EB16 for ; Fri, 28 Apr 2017 10:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 W7JEJOVC6vJw for ; Fri, 28 Apr 2017 10:13:52 -0700 (PDT) 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 25ED5127735 for ; Fri, 28 Apr 2017 10:10:31 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SH9wje007524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2017 10:09:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14E304) In-Reply-To: <87wpa44gpw.fsf@fifthhorseman.net> Date: Fri, 28 Apr 2017 10:09:58 -0700 Cc: dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:13:55 -0000 > On Apr 28, 2017, at 9:52 AM, Daniel Kahn Gillmor w= rote: >=20 > On Fri 2017-04-28 08:57:39 -0700, Joe Touch wrote: >>> -- existing HTTPS isn't going to move to a new port, which means >>> traffic on that port would be suspect to a would-be censor or a >>> pervasive monitor, right? >>=20 >> All traffic on the Internet is already subject to censorship and >> monitoring. I can't see how you can traverse someone else's link or >> router without that possibility, regardless of port. >=20 > To clarify any miscommunication, i said *suspect* (in the sense of > "suspicious"), not *subject*. =20 Sorry - misread that. Yes, new ports and new services are often treated as s= uspect. That's partly true (they could be) but partly bad (forcing us to use= only what we already have). > One of the aims of the draft is to make > the two protocols less distinguishable from one another to a network > attacker who might prefer one over the other (and consider the other to > be suspicious). A new port assignment fails to meet that goal. But using any existing ports for new behaviors is simply not your right. ... > Your points are noted, thanks, and i'll branch the discussion and start > talking with the HTTP folks soon. Ok. I really don't care if they allow this, but they need to allow this. Joe From nobody Fri Apr 28 11:42:16 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 D42C8129496 for ; Fri, 28 Apr 2017 11:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 T6CMXw-rBmW8 for ; Fri, 28 Apr 2017 11:42:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62FF129426 for ; Fri, 28 Apr 2017 11:41:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2C93ABED7; Fri, 28 Apr 2017 19:41:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVC1J2qKxFwr; Fri, 28 Apr 2017 19:41:43 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 942EFBECC; Fri, 28 Apr 2017 19:41:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1493404903; bh=eex3K+SNeqid381PlzO1utaAfzVIkLPP8VPb1aw1zJI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fBMCm8wGlWaDgF2qzxQm03AG4UYrhHkDp2zYcWOoBQZN9rrwLjNbnMRixFA+6mIaR zme6p05sMMikBPz81NeOVuUX5c0KS3e7JZkXWM8LZ5fjZ5vUTLKnvzJiOydiUhS36L tR44+YnTA9OtThlpsqaECQmDWOT2w0DlyhRo0dYE= To: Joe Touch , Daniel Kahn Gillmor References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> Cc: dns-privacy@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> Date: Fri, 28 Apr 2017 19:41:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9285nnB9lOe8rFUovwVJbDVmp99wKENhj" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 18:42:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9285nnB9lOe8rFUovwVJbDVmp99wKENhj Content-Type: multipart/mixed; boundary="QGdx4v4bsNotWLQFMu9CRVqcInw8C7vaH"; protected-headers="v1" From: Stephen Farrell To: Joe Touch , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Message-ID: <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> In-Reply-To: <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> --QGdx4v4bsNotWLQFMu9CRVqcInw8C7vaH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bit of a nit and possibly moot but... On 28/04/17 18:09, Joe Touch wrote: > Ok. I really don't care if they allow this, but they need to allow thi= s. I think that puts far too much emphasis on WGs "owning" things. They don't. IMO IETF consensus wins (where it exists) over WGs and IANA DEs and most or all other things in the IETF context. That said, I do agree it'd be crazy to document this without having gotten and taken into account feedback from folks expert in http. Cheers, S. --QGdx4v4bsNotWLQFMu9CRVqcInw8C7vaH-- --9285nnB9lOe8rFUovwVJbDVmp99wKENhj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZA4zmAAoJEC88hzaAX42iaccIAJtz7/Gi3pbTLw0yQHJh/1/R 6QYA8knFbZVXXKNtwKss0V6Bk/qNtisOrcknbBooEGLUF009QL3kQWELZMY7FdYX e18s3ur77IYljrwunV32CWappCBlR379IpCqpioF95oG7/7RZkRohJB2UUEWzJ9n uGdZGLOYUICimieaX+0rkS/MzIsdtI7xaJwysVfZM+7A19xtFIUEUKd4FHXz6Aal bbhMWGTYnj2YR7C2+MwcsHEMkafAF75EoLYIM2gzyYyxaWW3XM44fxDxWUfj6jhi mYLnqhkD3GliUYczINYiWcg7JcQXldF0yn7cTvTaV42tigeP1VeQ6KKOqAw0k10= =Bcg0 -----END PGP SIGNATURE----- --9285nnB9lOe8rFUovwVJbDVmp99wKENhj-- From nobody Fri Apr 28 12:46:17 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 6F222129AF4 for ; Fri, 28 Apr 2017 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Iv5ChfJKIbJD for ; Fri, 28 Apr 2017 12:46:14 -0700 (PDT) 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 5556E129577 for ; Fri, 28 Apr 2017 12:45:05 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SJiKt1011453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 12:44:22 -0700 (PDT) To: Stephen Farrell , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> From: Joe Touch Message-ID: <7c1cfe0a-1d2c-d2f6-b7cc-6697f07fb467@isi.edu> Date: Fri, 28 Apr 2017 12:44:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 19:46:15 -0000 On 4/28/2017 11:41 AM, Stephen Farrell wrote: > Bit of a nit and possibly moot but... > > On 28/04/17 18:09, Joe Touch wrote: >> Ok. I really don't care if they allow this, but they need to allow this. > I think that puts far too much emphasis on WGs "owning" things. The assignee of the port "owns" it, not the WG. For IESG-owned ports, specified by standards-track RFCs, the ownership is the IESG. > They don't. IMO IETF consensus wins (where it exists) over WGs > and IANA DEs and most or all other things in the IETF context. I don't understand "IETF consensus wins...over WGs". In this case, you'd need to clearly state that this doc updates the HTTP spec, indicate that it redefines the services on ports 80 and 443, and get IETF consensus to move forward. I agree - it's not genuflecting in front of the HTTP WG, but I wouldn't be surprised if cross-area review solicited their opinion. The key, however, is that this proposal is really redefining HTTP ports 80 and 443 (if that's the direction you go), and you need to get consensus on that. It's not enough to simply say "we want to do it and it works as currently specd". Joe From nobody Fri Apr 28 12:58: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 C75991294CC for ; Fri, 28 Apr 2017 12:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 gMz-MZl5YnCQ for ; Fri, 28 Apr 2017 12:58:48 -0700 (PDT) Received: from spamfilter3.dtu.dk (spamfilter3.dtu.dk [192.38.82.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DAC129528 for ; Fri, 28 Apr 2017 12:57:51 -0700 (PDT) Received: from ait-pexedg01.win.dtu.dk (ait-pexedg01.win.dtu.dk [192.38.82.191]) by spamfilter3.dtu.dk with ESMTP id v3SJvkYV025887-v3SJvkYX025887 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 28 Apr 2017 21:57:46 +0200 Received: from ait-pex01mbx01.win.dtu.dk (192.38.82.181) by ait-pexedg01.win.dtu.dk (192.38.82.191) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Apr 2017 21:57:49 +0200 Received: from ait-pex02mbx05.win.dtu.dk (192.38.82.185) by ait-pex01mbx01.win.dtu.dk (192.38.82.181) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Apr 2017 21:57:46 +0200 Received: from 523x.env.dtu.dk (130.225.73.250) by ait-pex02mbx05.win.dtu.dk (192.38.82.185) with Microsoft SMTP Server id 14.3.319.2; Fri, 28 Apr 2017 21:57:46 +0200 Message-ID: <1493409465.4048.2.camel@env.dtu.dk> From: Hugo Connery To: Joe Touch , Daniel Kahn Gillmor CC: Date: Fri, 28 Apr 2017 21:57:45 +0200 In-Reply-To: <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [130.225.73.250] Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 19:58:51 -0000 Joe, [snip]. > > One of the aims of the draft is to make > > the two protocols less distinguishable from one another to a > > network > > attacker who might prefer one over the other (and consider the > > other to > > be suspicious).  A new port assignment fails to meet that goal. > > But using any existing ports for new behaviors is simply not your > right. > ... I could not more vehemently disagree. 1) DKG is publishing an idea to the community, not taking over anything. 2) I will run whatever software on my end-point using any port that I wish. End of story. Standards exist to encourage compliance, not demand it. /Hugo [snip]. > Joe > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy --       Hugo Connery, Head of IT, DTU Environment "There is no cloud, only other people's computers".  FSF From nobody Fri Apr 28 13:40:09 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 7C2F0129A9D for ; Fri, 28 Apr 2017 13:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 fNffrJpgSmyE for ; Fri, 28 Apr 2017 13:40:05 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAF1129B4F for ; Fri, 28 Apr 2017 13:37:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C05C236959; Fri, 28 Apr 2017 23:37:37 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4x5QGtxoa7gG; Fri, 28 Apr 2017 23:37:37 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 948D5287; Fri, 28 Apr 2017 23:37:37 +0300 (EEST) Date: Fri, 28 Apr 2017 23:37:35 +0300 From: Ilari Liusvaara To: Joe Touch Cc: dns-privacy@ietf.org Message-ID: <20170428203735.GA4194@LK-Perkele-V2.elisa-laajakaista.fi> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> <7c1cfe0a-1d2c-d2f6-b7cc-6697f07fb467@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7c1cfe0a-1d2c-d2f6-b7cc-6697f07fb467@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:40:07 -0000 On Fri, Apr 28, 2017 at 12:44:19PM -0700, Joe Touch wrote: > > The key, however, is that this proposal is really redefining HTTP ports > 80 and 443 (if that's the direction you go), and you need to get > consensus on that. It's not enough to simply say "we want to do it and > it works as currently specd". The properties this draft exploits for detection are completely fundamential to HTTP/1.x and HTTP/2. There is no way anything that breaks those properties can be deployed on mass scale without a new ALPN, which should be ample warning to the server that new things are going on. This isn't "unextendable because of middleboxes", it is "unextendable because the endpoints can't negotiate". -Ilari From nobody Fri Apr 28 15:27: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 62277129AB2 for ; Fri, 28 Apr 2017 15:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 EwpafYyHkN_7 for ; Fri, 28 Apr 2017 15:27:22 -0700 (PDT) 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 51B53129B43 for ; Fri, 28 Apr 2017 15:24:39 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SMO7Rw005834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 15:24:13 -0700 (PDT) To: Ilari Liusvaara Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> <7c1cfe0a-1d2c-d2f6-b7cc-6697f07fb467@isi.edu> <20170428203735.GA4194@LK-Perkele-V2.elisa-laajakaista.fi> From: Joe Touch Message-ID: <86bd2e22-6a03-6ba5-71fe-c93f7013b611@isi.edu> Date: Fri, 28 Apr 2017 15:24:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170428203735.GA4194@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------2B50CE677A10E6A25FFA351D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 22:27:23 -0000 This is a multi-part message in MIME format. --------------2B50CE677A10E6A25FFA351D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/28/2017 1:37 PM, Ilari Liusvaara wrote: >> The key, however, is that this proposal is really redefining HTTP ports >> 80 and 443 (if that's the direction you go), and you need to get >> consensus on that. It's not enough to simply say "we want to do it and >> it works as currently specd". > The properties this draft exploits for detection are completely > fundamential to HTTP/1.x and HTTP/2. There is no way anything that > breaks those properties can be deployed on mass scale without a new > ALPN, which should be ample warning to the server that new things > are going on. All I'm asking is that this doc makes it very clear that it intends to redefine the services on ports 80 and/or 443, if that's the way you go. I'll leave it to others to decide whether that's a good idea or not. Joe --------------2B50CE677A10E6A25FFA351D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 4/28/2017 1:37 PM, Ilari Liusvaara wrote:
The key, however, is that this proposal is really redefining HTTP ports
80 and 443 (if that's the direction you go), and you need to get
consensus on that. It's not enough to simply say "we want to do it and
it works as currently specd".

The properties this draft exploits for detection are completely
fundamential to HTTP/1.x and HTTP/2. There is no way anything that
breaks those properties can be deployed on mass scale without a new
ALPN, which should be ample warning to the server that new things
are going on.

All I'm asking is that this doc makes it very clear that it intends to redefine the services on ports 80 and/or 443, if that's the way you go.

I'll leave it to others to decide whether that's a good idea or not.

Joe
--------------2B50CE677A10E6A25FFA351D-- From nobody Fri Apr 28 15:33:21 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 3335F129B81 for ; Fri, 28 Apr 2017 15:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 L_B0wxZ53Rs0 for ; Fri, 28 Apr 2017 15:33:18 -0700 (PDT) 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 95BD9129BDA for ; Fri, 28 Apr 2017 15:30:21 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SMTiIP007320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Apr 2017 15:29:50 -0700 (PDT) To: Hugo Connery , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <1493409465.4048.2.camel@env.dtu.dk> From: Joe Touch Message-ID: Date: Fri, 28 Apr 2017 15:29:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <1493409465.4048.2.camel@env.dtu.dk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 22:33:20 -0000 Hugo, On 4/28/2017 12:57 PM, Hugo Connery wrote: > ... >> But using any existing ports for new behaviors is simply not your >> right. >> ... > I could not more vehemently disagree. > > 1) DKG is publishing an idea to the community, not taking over > anything. That idea encourages others to squat on an existing port. I doubt either the IESG or IANA would allow that to proceed as an RFC of any kind. > 2) I will run whatever software on my end-point using any port > that I wish. End of story. I agree fully with that story - any service can be run on any port. However, the integrity of the very nature of assigned ports requires is based on the expectation that endpoints run only the assigned service on the corresponding assigned port *except when other direct information indicates otherwise* (e.g., port override in a URL, mDNS entry, etc.) > Standards exist to encourage compliance, > not demand it. That undermines the very nature of a standard. If you want others to follow your laws, you have to respect theirs. Joe From nobody Fri Apr 28 16:25:22 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 B9B6B1293F3 for ; Fri, 28 Apr 2017 16:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 4RcwkY76osiF for ; Fri, 28 Apr 2017 16:25:18 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 759BB129486 for ; Fri, 28 Apr 2017 16:23:03 -0700 (PDT) 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 1E57D24AE0B; Fri, 28 Apr 2017 23:21:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C7A9216009D; Fri, 28 Apr 2017 23:21:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A89A816009E; Fri, 28 Apr 2017 23:21:42 +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 YjMZWQ3Kf55i; Fri, 28 Apr 2017 23:21:42 +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 538CA16009D; Fri, 28 Apr 2017 23:21:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B55756D5DDA2; Sat, 29 Apr 2017 09:21:39 +1000 (AEST) To: Joe Touch Cc: Hugo Connery , Daniel Kahn Gillmor , dns-privacy@ietf.org From: Mark Andrews References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <1493409465.4048.2.camel@env.dtu.dk> In-reply-to: Your message of "Fri, 28 Apr 2017 15:29:43 -0700." Date: Sat, 29 Apr 2017 09:21:39 +1000 Message-Id: <20170428232139.B55756D5DDA2@rock.dv.isc.org> Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 23:25:20 -0000 In message , Joe Touch writes: > Hugo, > > > On 4/28/2017 12:57 PM, Hugo Connery wrote: > > ... > >> But using any existing ports for new behaviors is simply not your > >> right. > >> ... > > I could not more vehemently disagree. > > > > 1) DKG is publishing an idea to the community, not taking over > > anything. > That idea encourages others to squat on an existing port. I doubt either > the IESG or IANA would allow that to proceed as an RFC of any kind. Actually it is proposing a extension to the existing port usage that co-exists. Whether it was said well or not is a different matter. Writing a draft is how we propose extensions. Squatting would be just doing it then begging forgiveness afterwards. > > 2) I will run whatever software on my end-point using any port > > that I wish. End of story. > I agree fully with that story - any service can be run on any port. > > However, the integrity of the very nature of assigned ports requires is > based on the expectation that endpoints run only the assigned service on > the corresponding assigned port *except when other direct information > indicates otherwise* (e.g., port override in a URL, mDNS entry, etc.) > > > Standards exist to encourage compliance, > > not demand it. > That undermines the very nature of a standard. > > If you want others to follow your laws, you have to respect theirs. > > Joe > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Apr 28 16:28:17 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 649A01294E4 for ; Fri, 28 Apr 2017 16:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 GOulJqiBr_Pn for ; Fri, 28 Apr 2017 16:28:14 -0700 (PDT) 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 C4F46129B67 for ; Fri, 28 Apr 2017 16:25:44 -0700 (PDT) Received: from [192.168.1.28] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3SNPEhw020270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2017 16:25:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (14E304) In-Reply-To: <20170428232139.B55756D5DDA2@rock.dv.isc.org> Date: Fri, 28 Apr 2017 16:25:13 -0700 Cc: Hugo Connery , Daniel Kahn Gillmor , dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <1493409465.4048.2.camel@env.dtu.dk> <20170428232139.B55756D5DDA2@rock.dv.isc.org> To: Mark Andrews X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 23:28:15 -0000 > On Apr 28, 2017, at 4:21 PM, Mark Andrews wrote: >=20 > Writing a draft is how we propose extensions. The IANA considerations at least need to make that clear. It would help to h= ave this update the HTTP RFCs and be explicit about that goal from the abstr= act onwards too.=20 Joe= From nobody Fri Apr 28 16:34:15 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 D0D12129B20 for ; Fri, 28 Apr 2017 16:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 xfO7zjIN1FWL for ; Fri, 28 Apr 2017 16:34:13 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 49FF0129439 for ; Fri, 28 Apr 2017 16:31:43 -0700 (PDT) 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.pao1.isc.org (Postfix) with ESMTPS id E8DD0349421; Fri, 28 Apr 2017 23:31:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C76CD16009F; Fri, 28 Apr 2017 23:31:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A87D716009E; Fri, 28 Apr 2017 23:31:40 +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 Ac8HdF-b4oBl; Fri, 28 Apr 2017 23:31:40 +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 4ECEB16009D; Fri, 28 Apr 2017 23:31:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D60FE6D5DEFE; Sat, 29 Apr 2017 09:31:37 +1000 (AEST) To: Joe Touch Cc: Hugo Connery , Daniel Kahn Gillmor , dns-privacy@ietf.org From: Mark Andrews References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <1493409465.4048.2.camel@env.dtu.dk> <20170428232139.B55756D5DDA2@rock.dv.isc.org> In-reply-to: Your message of "Fri, 28 Apr 2017 16:25:13 -0700." Date: Sat, 29 Apr 2017 09:31:37 +1000 Message-Id: <20170428233137.D60FE6D5DEFE@rock.dv.isc.org> Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 23:34:15 -0000 In message , Joe Touch writes: > > > > On Apr 28, 2017, at 4:21 PM, Mark Andrews wrote: > > > > Writing a draft is how we propose extensions. > > The IANA considerations at least need to make that clear. It would help > to have this update the HTTP RFCs and be explicit about that goal from > the abstract onwards too. It would need a Updates header for the HTTP RFCs. IANA would need to add this document as a additional reference for port 443. This stuff however is dotting the i's and crossing the t's. Mark > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Apr 28 17:47: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 ECC23129489 for ; Fri, 28 Apr 2017 17:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 fNlq6oGc1EL7 for ; Fri, 28 Apr 2017 17:47:09 -0700 (PDT) Received: from spamfilter3.dtu.dk (spamfilter3.dtu.dk [192.38.82.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD8C12950A for ; Fri, 28 Apr 2017 17:44:52 -0700 (PDT) Received: from ait-pexedg02.win.dtu.dk (ait-pexedg02.win.dtu.dk [192.38.82.192]) by spamfilter3.dtu.dk with ESMTP id v3T0ikgR016440-v3T0ikgT016440 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Sat, 29 Apr 2017 02:44:46 +0200 Received: from ait-pex01mbx01.win.dtu.dk (192.38.82.181) by ait-pexedg02.win.dtu.dk (192.38.82.192) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 29 Apr 2017 02:44:41 +0200 Received: from ait-pex01mbx03.win.dtu.dk (192.38.80.17) by ait-pex01mbx01.win.dtu.dk (192.38.82.181) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 29 Apr 2017 02:44:46 +0200 Received: from 523x.env.dtu.dk (130.225.73.250) by ait-pex01mbx03.win.dtu.dk (192.38.80.17) with Microsoft SMTP Server id 14.3.319.2; Sat, 29 Apr 2017 02:44:45 +0200 Message-ID: <1493426685.6071.2.camel@env.dtu.dk> From: Hugo Connery To: Joe Touch , Mark Andrews CC: Daniel Kahn Gillmor , Date: Sat, 29 Apr 2017 02:44:45 +0200 In-Reply-To: References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <1493409465.4048.2.camel@env.dtu.dk> <20170428232139.B55756D5DDA2@rock.dv.isc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [130.225.73.250] Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 00:47:12 -0000 On Fri, 2017-04-28 at 16:25 -0700, Joe Touch wrote: > > On Apr 28, 2017, at 4:21 PM, Mark Andrews wrote: > > > > Writing a draft is how we propose extensions. > > The IANA considerations at least need to make that clear. [snip]. +1 "Writing a draft ...".   The multi-decade effort to publish, update and revise the process  for participation in IANA affairs has failed? Its not "clear" yet? # [Insert responses here.] /Hugo Connery From nobody Fri Apr 28 18:24:00 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 CF302129450 for ; Fri, 28 Apr 2017 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 4C9KdrsqmGoq for ; Fri, 28 Apr 2017 18:23:57 -0700 (PDT) Received: from spamfilter4.dtu.dk (spamfilter4.dtu.dk [192.38.80.33]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2251292F5 for ; Fri, 28 Apr 2017 18:21:32 -0700 (PDT) Received: from ait-pexedg01.win.dtu.dk (ait-pexedg01.win.dtu.dk [192.38.82.191]) by spamfilter4.dtu.dk with ESMTP id v3T1LSiw031099-v3T1LSj0031099 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Sat, 29 Apr 2017 03:21:28 +0200 Received: from ait-pex02mbx06.win.dtu.dk (192.38.80.18) by ait-pexedg01.win.dtu.dk (192.38.82.191) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 29 Apr 2017 03:21:30 +0200 Received: from ait-pex01mbx03.win.dtu.dk (192.38.80.17) by ait-pex02mbx06.win.dtu.dk (192.38.80.18) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 29 Apr 2017 03:21:27 +0200 Received: from 523x.env.dtu.dk (130.225.73.250) by ait-pex01mbx03.win.dtu.dk (192.38.80.17) with Microsoft SMTP Server id 14.3.319.2; Sat, 29 Apr 2017 03:21:26 +0200 Message-ID: <1493428886.6071.6.camel@env.dtu.dk> From: Hugo Connery To: Ilari Liusvaara , Joe Touch CC: Date: Sat, 29 Apr 2017 03:21:26 +0200 In-Reply-To: <20170428203735.GA4194@LK-Perkele-V2.elisa-laajakaista.fi> References: <87inlt9us5.fsf@fifthhorseman.net> <87efwe7k9b.fsf@fifthhorseman.net> <8e648856-c656-7914-deda-b9a93bdd2f48@isi.edu> <87shkt588f.fsf@fifthhorseman.net> <87wpa44gpw.fsf@fifthhorseman.net> <6A0734D2-9145-4137-99F5-012AF6B6CE04@isi.edu> <27b670d0-aceb-b974-3aff-b29cacf044bd@cs.tcd.ie> <7c1cfe0a-1d2c-d2f6-b7cc-6697f07fb467@isi.edu> <20170428203735.GA4194@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [130.225.73.250] Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 01:23:59 -0000 On Fri, 2017-04-28 at 23:37 +0300, Ilari Liusvaara wrote: > On Fri, Apr 28, 2017 at 12:44:19PM -0700, Joe Touch wrote: > > > > The key, however, is that this proposal is really redefining HTTP > > ports > > 80 and 443 (if that's the direction you go), and you need to get > > consensus on that. It's not enough to simply say "we want to do it > > and > > it works as currently specd". > > The properties this draft exploits for detection are completely > fundamential to HTTP/1.x and HTTP/2. There is no way anything that > breaks those properties can be deployed on mass scale without a new > ALPN, which should be ample warning to the server that new things > are going on. > > This isn't "unextendable because of middleboxes", it is "unextendable > because the endpoints can't negotiate". > > > -Ilari If we accept DKG's proof, it works on what *is*.  "Cant negotiate"? There is no negotiation. The "server" demuxes on published, known, accepted, delineated protocol standards.   Cant fix future changes and cant fix non-end-points screwing with the stream. Am I missing something? /Hugo