Re: [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback
"AlBanna, Zaid" <zalbanna@verisign.com> Mon, 30 August 2021 14:38 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 E41343A14AB for <dns-privacy@ietfa.amsl.com>; Mon, 30 Aug 2021 07:38:22 -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=unavailable 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 ykh9fh4CUEqh for <dns-privacy@ietfa.amsl.com>; Mon, 30 Aug 2021 07:38:15 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.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 E27A23A14EA for <dprive@ietf.org>; Mon, 30 Aug 2021 07:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=44211; q=dns/txt; s=VRSN; t=1630334295; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=HJwRJjvurtYsTDESlvklwHL8ewWPnX+FQOsW8ZJnDUw=; b=nSZnmYXTMsl4F+Y+1lCyZW171XHrdkKMd04UjVn1q4xKrMYsIgdBWsGP KVMw3AA42hqcpLz8aJezg6QCHjfvWd1ThhoroDKhZiyAc9Ae+Ea6wFQya KvCmMdaTFAmhBJHSLIVwHmZ5ZRMns+usA3KAh8EcyA2JCP7URopzYRtq/ dMuWWtegtOeoviSvsOdqtQxO/Hm8QiXfk2fxaHio+vIUlBS4PLdpObquN 1G3Q4NdiedqPy02i9ir9rPRvjc8Xl3b7Zo9hpu0Ae5wkh0nqhdSh6Zm6U q3BHsXLIzAG+LK1SrkVk3BbTD2sVvl09wYT8GurdYWW0r0hst4hzJPUq4 Q==;
IronPort-SDR: YO9pg7bYQpFAWUpCEgfM+kbhUQ1OMtcDvzJBsDDPAoqnJSsbZcDuSvHbhVTCQmy+jzDTHv8/WY Hr/yxnZAxMeSDrwi9CVYc6gYCUT9bEopcRTdQCBl3rT+Z4bw12YkJjEp636TGl3bI8EdAht55y gF/50GtM3QoYEFKVQpjfSEn0D5SI8gZUNlLUAU7uUis0vqfXuPvXKPUXVKIqsUu2cB3Wndkv6F xhX9apUC9C8dpI/upb6IuaqOliE96TUJLa5ogyJgv1+zyrs/J5NpUp9EOO9z11RDT9iQvFG7Ui MNQ=
IronPort-HdrOrdr: A9a23:P51PDqPBin8/68BcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-IronPort-AV: E=Sophos; i="5.84,363,1620691200"; d="scan'208,217"; a="10524023"
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, 30 Aug 2021 10:38:12 -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, 30 Aug 2021 10:38:12 -0400
From: "AlBanna, Zaid" <zalbanna@verisign.com>
To: "peter.van.dijk@powerdns.com" <peter.van.dijk@powerdns.com>, "paul.hoffman@icann.org" <paul.hoffman@icann.org>
CC: "dprive@ietf.org" <dprive@ietf.org>, "zalbanna=40verisign.com@dmarc.ietf.org" <zalbanna=40verisign.com@dmarc.ietf.org>
Thread-Topic: [EXTERNAL] [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback
Thread-Index: AQHXmEm9inmT7g/K/USF4/tj9G2AB6uMKL0A
Date: Mon, 30 Aug 2021 14:38:12 +0000
Message-ID: <35DAB562-0CA7-4322-9349-9D377BD157D5@verisign.com>
References: <3B406A9A-F702-4EC5-A8AB-74A023BEE0E6@verisign.com>
In-Reply-To: <3B406A9A-F702-4EC5-A8AB-74A023BEE0E6@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_35DAB5620CA7432293499D377BD157D5verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/7jaLkwAnCyqUP5eKySPY8T0zpDs>
Subject: Re: [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, 30 Aug 2021 14:38:35 -0000
Dear Peter and Paul, I hope you are well. Just following up on the comments I shared on draft-ietf-dprive-unauth-to-authoritative-03. Please share your thoughts. Regards, Zaid From: "AlBanna, Zaid" <zalbanna@verisign.com> Date: Monday, August 23, 2021 at 2:07 PM To: "peter.van.dijk@powerdns.com" <peter.van.dijk@powerdns.com>, "paul.hoffman@icann.org" <paul.hoffman@icann.org> Cc: "dprive@ietf.org" <dprive@ietf.org>, "paul@nohats.ca" <paul@nohats.ca>, "zalbanna=40verisign.com@dmarc.ietf.org" <zalbanna=40verisign.com@dmarc.ietf.org> Subject: Re: [EXTERNAL] [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback Apologies for the confusion. This is supposed to be to Paul H. and not to Paul W. Thanks Zaid From: dns-privacy <dns-privacy-bounces@ietf.org> on behalf of "AlBanna, Zaid" <zalbanna=40verisign.com@dmarc.ietf.org> Date: Monday, August 23, 2021 at 10:33 AM 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> Subject: [EXTERNAL] [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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