draft-ietf-dprive-phase2-requirements-00.txt | draft-ietf-dprive-phase2-requirements-01.txt | |||
---|---|---|---|---|
DPRIVE J. Livingood | DPRIVE J. Livingood | |||
Internet-Draft Comcast | Internet-Draft Comcast | |||
Intended status: Informational A. Mayrhofer | Intended status: Informational A. Mayrhofer | |||
Expires: June 16, 2020 nic.at GmbH | Expires: December 18, 2020 nic.at GmbH | |||
B. Overeinder | B. Overeinder | |||
NLnet Labs | NLnet Labs | |||
December 14, 2019 | June 16, 2020 | |||
DNS Privacy Requirements for Exchanges between Recursive Resolvers and | DNS Privacy Requirements for Exchanges between Recursive Resolvers and | |||
Authoritative Servers | Authoritative Servers | |||
draft-ietf-dprive-phase2-requirements-00 | draft-ietf-dprive-phase2-requirements-01 | |||
Abstract | Abstract | |||
This document provides requirements for adding confidentiality to DNS | This document provides requirements for adding confidentiality to DNS | |||
exchanges between recursive resolvers and authoritative servers. | exchanges between recursive resolvers and authoritative servers. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 16, 2020. | This Internet-Draft will expire on December 18, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 6, line 24 ¶ | skipping to change at page 6, line 24 ¶ | |||
9.1. The User Perspective and Use Cases | 9.1. The User Perspective and Use Cases | |||
The privacy and confidentiality of Users (that is, users as in | The privacy and confidentiality of Users (that is, users as in | |||
clients of recursive resolvers, which in turn forward/resolve the | clients of recursive resolvers, which in turn forward/resolve the | |||
user's DNS requests by contacting authoritative servers) can be | user's DNS requests by contacting authoritative servers) can be | |||
improved in several ways. We call this "minimisation of exposure", | improved in several ways. We call this "minimisation of exposure", | |||
and there are currently three ways to reduce that exposure: | and there are currently three ways to reduce that exposure: | |||
o Qname minimisation [RFC7816], reducing the amount of information | o Qname minimisation [RFC7816], reducing the amount of information | |||
which is absolutely necessary to resolve a query | to what is absolutely necessary to resolve a query | |||
o Aggressive NSEC/local auth cache [RFC8198], reducing the amount of | o Aggressive NSEC/local auth cache [RFC8198], reducing the amount of | |||
outgoing queries in the first place | outgoing queries in the first place | |||
o Encryption, removing exposure of information while in transit | o Encryption, removing exposure of information while in transit | |||
As recursors typically forwards queries received from the user to | As recursors typically forwards queries received from the user to | |||
authoritative servers. This creates a transitive trust between the | authoritative servers. This creates a transitive trust between the | |||
user and the recursor, as well as the authoritative server, since | user and the recursor, as well as the authoritative server, since | |||
information created by the user is exposed to the authoritative | information created by the user is exposed to the authoritative | |||
server. However, the user has never a chance to identify which data | server. However, the user never has a chance to identify what data | |||
was exposed to which authoritative party (via which path). | was exposed to which authoritative party (via which path). | |||
Also, Users would want to be informed about the status of the | Also, Users would want to be informed about the status of the | |||
connections which were made on their behalf, which adds a fourth | connections which were made on their behalf, which adds a fourth | |||
point | point | |||
Encryption/privacy status signaling | Encryption/privacy status signaling | |||
*TODO*: Actual requirements - what do users "want"? Start below: | *TODO*: Actual requirements - what do users "want"? Start below: | |||
End of changes. 7 change blocks. | ||||
7 lines changed or deleted | 7 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |