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
