[dns-privacy] Additional drafts for protecting DNS traffic

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 10 April 2017 18:04 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 <dns-privacy@ietfa.amsl.com>; 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 <dns-privacy@ietfa.amsl.com>; 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 <dns-privacy@ietf.org>; 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 <dns-privacy@ietf.org>; 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 <paul.hoffman@vpnc.org>
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: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZqxhP5PgaFvAuIdx0XZiVL_Q_EQ>
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: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=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.