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" <[email protected]> Date: Monday, August 23, 2021 at 2:07 PM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]> on behalf of "AlBanna, Zaid" <[email protected]> Date: Monday, August 23, 2021 at 10:33 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
