[dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback
"AlBanna, Zaid" <zalbanna@verisign.com> Mon, 23 August 2021 14:33 UTC
Return-Path: <zalbanna@verisign.com>
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 DDF293A00D8 for <dns-privacy@ietfa.amsl.com>; Mon, 23 Aug 2021 07:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 CNrtji2irIYW for <dns-privacy@ietfa.amsl.com>; Mon, 23 Aug 2021 07:32:56 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 E8A0C3A00D6 for <dprive@ietf.org>; Mon, 23 Aug 2021 07:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=43011; q=dns/txt; s=VRSN; t=1629729177; h=from:to:cc:subject:date:message-id:mime-version; bh=oQ7CYYpAfgQOyHn71D/SZqwR7cMIDmL+kmnv9ShNJQo=; b=HLNxE5XrgfVCFAMPRsabDUQTMKan7zfYkG8E/ukfoFJpvt6o7W8g3GbQ qygy87gNqxVMzJQeNzyX+81yXqHkBJdVEbeXCaVd8JfOi9q2eQ7fhnpfk 4K2VKTo82s65t6N2V26ncWFd2+6Og2MGeEd26WL4xG2/kiZy2ry9dxQdx GCnrAFmFHpYPPsBbBechZ3XTyE0i9TQfb3IJI0LyzAE3aINpS3RAyfxHt B8hfkgRZ4u2ymLjq2T/LVQeJ2AJ0jssmxq2Dil/mwpjxvgatFySTTculi 8l/74XoI3UuloGYS0JbZvhBoiRA9X+wxPBVVgRykTXyCgrrb37IX3rwUt A==;
IronPort-SDR: 9sedXoMSiPmIdgwtCfvhQfeD7YsNGeGE6yH7Ol7YV7b42cfdmYV8v4y1p3BWmUpKFNscjFvEo2 1w3jbrmfrjbKRicpIf9UW7xxorne4e0mAXM7UEGNA98eDQ7B2hiLjIKXVvXgWqPinLEWo7Cnol ilPlgHf/Zi0qkb//rd3L9GCI0MrHDh7Sb1lNd4lRfLsnbD5FBHZBOYQtZXNluq4h82ziCAX3Jm eio6Uydv//4jNJ7MQC/Fpf+rbwjV9YkmMlLZ1t8955F9fVA31eCc+LbqoT+XPGnqruLeiilawD KWc=
IronPort-HdrOrdr: A9a23:vXQrjar16NfnC5hvn+bkzGwaV5r2eYIsimQD101hICG9Ffbo8v xG/c5rtyMc5wxwZJhNo7690cq7Lk80nKQdibX5Vo3SPzUO1lHIEKhSqaXvxDH6EzDz+6p3xc 5bH5RWOZnVAUJhhcj3pCu1A78bquWvweSNif3Fx3lgCTt2bbpthj0VNi+AHlZoSBJ9CZ01KZ qZ6qN8zAadRQ==
X-IronPort-AV: E=Sophos;i="5.84,344,1620691200"; d="scan'208,217";a="9523810"
Received: from ILG1WNEX01.vcorp.ad.vrsn.com (10.246.152.25) by ILG1WNEX01.vcorp.ad.vrsn.com (10.246.152.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 23 Aug 2021 10:32:54 -0400
Received: from ILG1WNEX01.vcorp.ad.vrsn.com ([fe80::8c53:d345:af76:52e8]) by ILG1WNEX01.vcorp.ad.vrsn.com ([fe80::8c53:d345:af76:52e8%5]) with mapi id 15.01.2308.008; Mon, 23 Aug 2021 10:32:54 -0400
From: "AlBanna, Zaid" <zalbanna@verisign.com>
To: "paul@nohats.ca" <paul@nohats.ca>, "peter.van.dijk@powerdns.com" <peter.van.dijk@powerdns.com>
CC: "paul.hoffman@icann.org" <paul.hoffman@icann.org>, "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback
Thread-Index: AQHXmCvC7ZSv4nRpuUmUcmAeTcyMVg==
Date: Mon, 23 Aug 2021 14:32:53 +0000
Message-ID: <DB9744F6-4E2F-4E15-881D-5DA0C27489E1@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_DB9744F64E2F4E15881D5DA0C27489E1verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/9Uf12x21rFGGCSbo_QNCvAayGT8>
Subject: [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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, 23 Aug 2021 14:33:01 -0000
Dear Peter and Paul, I hope you are well. Please find below comments on draft-ietf-dprive-unauth-to-authoritative-03. Please share your thoughts. Regards, Zaid 1.1. Use Case for Unauthenticated Encryption Justification: The addition here is based on the understanding I took away from the last discussion at IETF-DPRIVE. It emphasizes the benefits gained by implementing this draft. Existing Text: The use case in this document for unauthenticated encryption is recursive resolver operators who are happy to use encryption with authoritative servers if doing so doesn't significantly slow down getting answers, and authoritative server operators that are happy to use encryption with recursive resolvers if it doesn't cost much. In this use case, resolvers do not want to return an error for requests that were sent over an encrypted channel if they would have been able to give a correct answer using unencrypted transport. Resolvers and authoritative..... Suggested Text: The use case in this document for unauthenticated encryption is recursive resolver operators who are happy to use encryption with authoritative servers if doing so doesn't significantly slow down getting answers, and authoritative server operators that are happy to use encryption with recursive resolvers if it doesn't cost much. In this use case, resolvers do not want to return an error for requests that were sent over an encrypted channel if they would have been able to give a correct answer using unencrypted transport. Ultimately this effort aims to achieve two goals. The first is to protect queries from failing in case authenticated encryption is not available. The second is to enable recursive resolver operators to encrypt without server authentication. Resolvers and authoritative..... 1.2. Summary of Protocol Justification: There are various types of authentication between servers and clients. The word server was added to the last bullet to specify what authentication type is being referenced. Existing Text: … o The resolver does not fail to set up encryption if the authentication in the TLS session fails. Suggested Text: … o The resolver does not fail to set up encryption if [SAH] Delete “the” server authentication in the TLS session fails. 3. Processing Discovery Responses Justification: Added references based on recommendations in existing drafts to provide readers context to the problem and current available solutions guidelines. Existing Text: After a resolver has DNS SCVB records in its cache (possibly due ... A resolver SHOULD keep a DNS with encryption session to a particular server open if it expects to send additional queries to that server in a short period of time. [DNS-OVER-TCP] says "both clients and servers SHOULD support connection reuse" for TCP connections, and that advice could apply as well for DNS with encryption, especially as DNS with encryption has far greater overhead for re-establishing a connection. If the server closes the DNS with encryption session, the resolver can possibly re-establish a DNS with encryption session using encrypted session resumption. For any DNS with encryption protocols, TLS version 1.3 [TLS-13] or ... Suggested Text: After a resolver has DNS SCVB records in its cache (possibly due ... A resolver SHOULD keep a DNS with encryption session to a particular server open if it expects to send additional queries to that server. [DNS-OVER-TCP] says "both clients and servers SHOULD support connection reuse" for TCP connections, and that advice could apply as well for DNS with encryption, especially as DNS with encryption has far greater overhead for re-establishing a connection. If the server closes the DNS with encryption session, the resolver can possibly re-establish a DNS with encryption session using encrypted session resumption. Encryption sessions max timeout, min timeout and duration should take into consideration the recommendations stated in RFC5482, RFC7828, RFC7230, and RFC2616. For any DNS with encryption protocols, TLS version 1.3 [TLS-13] or ... 6. Security Considerations Justification: In an effort to introduce solutions that cover various scenarios it is important to share with readers known and specific vulnerabilities that could affect the proposed solution and the services that will be built on it. RFC 8446, and specifically section C of that RFC, illustrates points that are relevant here, and that readers and implementors of this draft could benefit from. Existing Text: The method described in this document explicitly allows a resolver to perform DNS communications over traditional unencrypted, unauthenticated DNS on port 53, if it cannot find an authoritative server that advertises that it supports encryption. The method described in this document explicitly allows a resolver using encryption to choose to allow unauthenticated encryption. In either of these cases, the resulting communication will be susceptible to obvious and well-understood attacks from an attacker in the path of the communications. Suggested Text: The method described in this document explicitly allows a resolver to perform DNS communications over traditional unencrypted, unauthenticated DNS on port 53, if it cannot find an authoritative server that advertises that supports encryption. The method described in this document explicitly allows a resolver using encryption to choose to allow unauthenticated encryption. In either of these cases, the resulting communication will be susceptible to obvious and well-understood attacks from an attacker in the path of the communications. As stated in RFC 8446 which specifically warns against anonymous connections as such connections only provide protection against passive eavesdropping while failing to protect against active man-in-the-middle attacks. Section C.5 of RFC 8446 explicitly states applications MUST NOT use TLS, with unverifiable server authentication, without an explicit configuration or a specific application profile. This I-D is intended to be such an application profile. --------------------------------- >8
- [dns-privacy] Recursive to Authoritative DNS with… AlBanna, Zaid
- Re: [dns-privacy] Recursive to Authoritative DNS … AlBanna, Zaid
- Re: [dns-privacy] Recursive to Authoritative DNS … AlBanna, Zaid
- Re: [dns-privacy] [Ext] Recursive to Authoritativ… Paul Hoffman