Re: [dns-privacy] Recursive to Authoritative DNS with Unauthenticated Encryption (draft-ietf-dprive-unauth-to-authoritative-03) - feedback

["AlBanna, Zaid" <[e-mail]>]

Apologies for the confusion. This is supposed to be to Paul H. and not to Paul W.

Thanks
Zaid

From: dns-privacy <[e-mail]> on behalf of "AlBanna, Zaid" <zalbanna=[e-mail]>
Date: Monday, August 23, 2021 at 10:33 AM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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