Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-pp-recursive-authoritative-opportunistic-03.txt

Paul Hoffman <paul.hoffman@icann.org> Mon, 07 December 2020 14:48 UTC

Return-Path: <paul.hoffman@icann.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 455E33A13ED for <dns-privacy@ietfa.amsl.com>; Mon, 7 Dec 2020 06:48:22 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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 IMSdumQsElG4 for <dns-privacy@ietfa.amsl.com>; Mon, 7 Dec 2020 06:48:20 -0800 (PST)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 8330E3A0E02 for <dns-privacy@ietf.org>; Mon, 7 Dec 2020 06:48:20 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0B7EmIRW010771 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dns-privacy@ietf.org>; Mon, 7 Dec 2020 14:48:18 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Mon, 7 Dec 2020 06:48:17 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Mon, 7 Dec 2020 06:48:17 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Fwd: New Version Notification for draft-pp-recursive-authoritative-opportunistic-03.txt
Thread-Index: AQHWw3UOfhXnn+Ni50CTX2mAPCUY36nsTy8A
Date: Mon, 07 Dec 2020 14:48:17 +0000
Message-ID: <AB0E44E5-2EAA-429E-B9CA-57B76D92B6D0@icann.org>
References: <160634062539.8716.8463088393130392274@ietfa.amsl.com> <4FEF9216-E0C0-4893-9A57-39C0EB42F6AD@icann.org>
In-Reply-To: <4FEF9216-E0C0-4893-9A57-39C0EB42F6AD@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_2AEA5B8B-2D8C-4F81-AD02-1AE47C32333B"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_11:2020-12-04, 2020-12-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/_qIwG2KOuiijRKPj9Y8J2PqmQ4Q>
Subject: Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-pp-recursive-authoritative-opportunistic-03.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Dec 2020 14:48:22 -0000

Greetings again. I've gotten some good off-list comments, but no discussion on-list. I'm wonderign if the limitation of only using port-checking is too limiting for people's interests, given that looking for a TLSA record will likely be faster than port-checking. Regardless, I'd like to hear people's thoughts on the draft, and I'd really like to see a draft from the people who want to have the WG work on fully authenticated encryption.

--Paul Hoffman


On Nov 25, 2020, at 1:50 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> Greetings again. Based on the request of the WG during last week's meeting, I have updated my draft to flesh out some of the ideas we discussed. As noted in the abstract and in the body of the draft, this version only proposes using port-checking for discovery, even though that is not likely to be the final proposal.
> 
> For those of you interested in the use case described in the document, please review and discuss how this might be improved.
> 
> For those of you not interested in the use case described in the document, there was a few pleas during the WG meeting for fleshed-out drafts on fully authenticated encryption for DNS.
> 
> --Paul Hoffman
> 
> 
> A new version of I-D, draft-pp-recursive-authoritative-opportunistic-03.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-pp-recursive-authoritative-opportunistic
> Revision:	03
> Title:		Recursive to Authoritative DNS with Opportunistic Encryption
> Document date:	2020-11-25
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/archive/id/draft-pp-recursive-authoritative-opportunistic-03.txt 
> Status:         https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/ 
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pp-recursive-authoritative-opportunistic
> Htmlized:       https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-03 
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pp-recursive-authoritative-opportunistic-03 
> 
> Abstract:
>  This document describes a use case and a method for a DNS recursive
>  resolver to use opportunistic encryption (that is, encryption with
>  optional authentication) when communicating with authoritative
>  servers.  The motivating use case for this method is that more
>  encryption on the Internet is better, and opportunistic encryption is
>  better than no encryption at all.  The method here is optional for
>  both the recursive resolver and the authoritative server.  Nothing in
>  this method prevents use cases and methods that require authenticated
>  encryption.
> 
>  IMPORTANT NOTE: This version of the document describes discovery
>  whether an authoritative server supports encryption using port-
>  checking.  This restriction is based on the request of the DPRIVE WG
>  during its meeting at IETF 109.  It is quite likely that the final
>  protocol will include a better set of methods for such discovery.
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy