| < draft-ietf-opsawg-mud-iot-dns-considerations-03.txt | draft-ietf-opsawg-mud-iot-dns-considerations-04.txt > | |||
|---|---|---|---|---|
| OPSAWG Working Group M. Richardson | OPSAWG Working Group M. Richardson | |||
| Internet-Draft Sandelman Software Works | Internet-Draft Sandelman Software Works | |||
| Intended status: Best Current Practice W. Pan | Intended status: Best Current Practice W. Pan | |||
| Expires: 22 July 2022 Huawei Technologies | Expires: 28 September 2022 Huawei Technologies | |||
| 18 January 2022 | 27 March 2022 | |||
| Operational Considerations for use of DNS in IoT devices | Operational Considerations for use of DNS in IoT devices | |||
| draft-ietf-opsawg-mud-iot-dns-considerations-03 | draft-ietf-opsawg-mud-iot-dns-considerations-04 | |||
| Abstract | Abstract | |||
| This document details concerns about how Internet of Things devices | This document details concerns about how Internet of Things devices | |||
| use IP addresses and DNS names. The issue becomes acute as network | use IP addresses and DNS names. The issue becomes acute as network | |||
| operators begin deploying RFC8520 Manufacturer Usage Description | operators begin deploying RFC8520 Manufacturer Usage Description | |||
| (MUD) definitions to control device access. | (MUD) definitions to control device access. | |||
| This document makes recommendations on when and how to use DNS names | This document makes recommendations on when and how to use DNS names | |||
| in MUD files. | in MUD files. | |||
| About This Document | ||||
| This note is to be removed before publishing as an RFC. | ||||
| Status information for this document may be found at | ||||
| https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | ||||
| considerations/. | ||||
| Discussion of this document takes place on the opsawg Working Group | ||||
| mailing list (mailto:opsawg@ietf.org), which is archived at | ||||
| https://mailarchive.ietf.org/arch/browse/opsawg/. | ||||
| Source for this draft and an issue tracker can be found at | ||||
| https://github.com/mcr/iot-mud-dns-considerations. | ||||
| 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. | |||
| 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 22 July 2022. | This Internet-Draft will expire on 28 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 | 3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 | 4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 | |||
| 4.1. Use of IP address literals in-protocol . . . . . . . . . 6 | 4.1. Use of IP address literals in-protocol . . . . . . . . . 7 | |||
| 4.2. Use of non-deterministic DNS names in-protocol . . . . . 8 | 4.2. Use of non-deterministic DNS names in-protocol . . . . . 8 | |||
| 4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 8 | 4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 8 | |||
| 5. DNS privacy and outsourcing versus MUD controllers . . . . . 8 | 5. DNS privacy and outsourcing versus MUD controllers . . . . . 9 | |||
| 6. Recommendations to IoT device manufacturer on MUD and DNS | 6. Recommendations to IoT device manufacturer on MUD and DNS | |||
| usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 9 | 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | |||
| 6.2. Use primary DNS names controlled by the manufacturer . . 10 | 6.2. Use primary DNS names controlled by the manufacturer . . 10 | |||
| 6.3. Use Content-Distribution Network with stable names . . . 10 | 6.3. Use Content-Distribution Network with stable names . . . 10 | |||
| 6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10 | 6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10 | |||
| 6.5. Prefer DNS servers learnt from DHCP/Route | 6.5. Prefer DNS servers learnt from DHCP/Route | |||
| Advertisements . . . . . . . . . . . . . . . . . . . . . 10 | Advertisements . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 14 | 9.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 18 ¶ | |||
| purpose device makes use of Internet resources. Access Control Lists | purpose device makes use of Internet resources. Access Control Lists | |||
| (ACLs) can be defined in an RFC8520 Manufacturer Usage Description | (ACLs) can be defined in an RFC8520 Manufacturer Usage Description | |||
| (MUD) file that permit a device to access Internet resources by DNS | (MUD) file that permit a device to access Internet resources by DNS | |||
| name. | name. | |||
| Use of a DNS name rather than IP address in the ACL has many | Use of a DNS name rather than IP address in the ACL has many | |||
| advantages: not only does the layer of indirection permit the mapping | advantages: not only does the layer of indirection permit the mapping | |||
| of name to IP address to be changed over time, it also generalizes | of name to IP address to be changed over time, it also generalizes | |||
| automatically to IPv4 and IPv6 addresses, as well as permitting | automatically to IPv4 and IPv6 addresses, as well as permitting | |||
| loading balancing of traffic by many different common ways, including | loading balancing of traffic by many different common ways, including | |||
| geography. | multi-CDN deployments wherein load balancing can account for | |||
| geography and load. | ||||
| At the MUD policy enforcement point - the firewall - there is a | At the MUD policy enforcement point -- the firewall -- there is a | |||
| problem. The firewall has only access to the layer-3 headers of the | problem. The firewall has only access to the layer-3 headers of the | |||
| packet. This includes the source and destination IP address, and if | packet. This includes the source and destination IP address, and if | |||
| not encrypted by IPsec, the destination UDP or TCP port number | not encrypted by IPsec, the destination UDP or TCP port number | |||
| present in the transport header. The DNS name is not present! | present in the transport header. The DNS name is not present! | |||
| It has been suggested that one answer to this problem is to provide a | It has been suggested that one answer to this problem is to provide a | |||
| forced intermediate for the TLS connections. This could in theory be | forced intermediate for the TLS connections. This could in theory be | |||
| done for TLS 1.2 connections. The MUD policy enforcement point could | done for TLS 1.2 connections. The MUD policy enforcement point could | |||
| observe the Server Name Identifier (SNI) [RFC6066]. Some Enterprises | observe the Server Name Identifier (SNI) [RFC6066]. Some Enterprises | |||
| do this already. But, as this involves active termination of the TCP | do this already. But, as this involves active termination of the TCP | |||
| skipping to change at page 4, line 37 ¶ | skipping to change at page 4, line 46 ¶ | |||
| 2. it reveals usage patterns of the devices, | 2. it reveals usage patterns of the devices, | |||
| 3. the mapping are often incomplete, | 3. the mapping are often incomplete, | |||
| 4. even if the mapping is present, due to virtual hosting, it may | 4. even if the mapping is present, due to virtual hosting, it may | |||
| not map back to the name used in the ACL. | not map back to the name used in the ACL. | |||
| This is not a successful strategy, its use is NOT RECOMMENDED. | This is not a successful strategy, its use is NOT RECOMMENDED. | |||
| XXX -- explain in detail how this can fail. | XXX --- explain in detail how this can fail. | |||
| XXX -- explain N:1 vs 1:1 for virtual hosting. | XXX --- explain N:1 vs 1:1 for virtual hosting. | |||
| The simplest successful strategy for translating names is for a MUD | The simplest successful strategy for translating names is for a MUD | |||
| controller to take is to do a DNS lookup on the name (a forward | controller to take is to do a DNS lookup on the name (a forward | |||
| lookup), and then use the resulting IP addresses to populate the | lookup), and then use the resulting IP addresses to populate the | |||
| physical ACLs. | physical ACLs. | |||
| There are still a number of failures possible. | There are still a number of failures possible. | |||
| The most important one is in the mapping of the names to IP addresses | The most important one is in the mapping of the names to IP addresses | |||
| may be non-deterministic. [RFC1794] describes the very common | may be non-deterministic. [RFC1794] describes the very common | |||
| skipping to change at page 5, line 36 ¶ | skipping to change at page 5, line 43 ¶ | |||
| However, in a geographical DNS load balancing system, different | However, in a geographical DNS load balancing system, different | |||
| answers are given based upon the locality of the system asking. | answers are given based upon the locality of the system asking. | |||
| There may also be further layers of round-robin indirection. | There may also be further layers of round-robin indirection. | |||
| Aside from the list of records being incomplete, the list may have | Aside from the list of records being incomplete, the list may have | |||
| changed between the time that the MUD controller did the lookup and | changed between the time that the MUD controller did the lookup and | |||
| the time that the IoT device does the lookup, and this change can | the time that the IoT device does the lookup, and this change can | |||
| result in a failure for the ACL to match. | result in a failure for the ACL to match. | |||
| In order to compensate for this, the MUD controller SHOULD regularly | In order to compensate for this, the MUD controller SHOULD regularly | |||
| do DNS lookups. These lookups need to be rate limited in order to | do DNS lookups in order to get never have stale data. These lookups | |||
| avoid load. It may be necessary to avoid recursive DNS servers in | need to be rate limited in order to avoid load. It may be necessary | |||
| order to avoid receiving cached data. Properly designed recursive | to avoid local recursive DNS servers. The MUD controller SHOULD | |||
| servers should cache data for many minutes to days, while the | incorporate its own recursive caching DNS server. Properly designed | |||
| underlying DNS data can change at a higher frequency, providing | recursive servers should cache data for many minutes to days, while | |||
| the underlying DNS data can change at a higher frequency, providing | ||||
| different answers to different queries! | different answers to different queries! | |||
| A MUD controller that is aware of which recursive DNS server that the | A MUD controller that is aware of which recursive DNS server that the | |||
| IoT device will use can instead query that server on a periodic | IoT device will use can instead query that server on a periodic | |||
| basis. Doing so provides three advantages: | basis. Doing so provides three advantages: | |||
| 1. any geographic load balancing will base the decision on the | 1. any geographic load balancing will base the decision on the | |||
| geolocation of the recursive DNS server, and the recursive name | geolocation of the recursive DNS server, and the recursive name | |||
| server will provide the same answer to the MUD controller as to | server will provide the same answer to the MUD controller as to | |||
| the IoT device. | the IoT device. | |||
| 2. the resulting name to IP address mapping in the recursive name | 2. the resulting name to IP address mapping in the recursive name | |||
| skipping to change at page 8, line 21 ¶ | skipping to change at page 8, line 31 ¶ | |||
| A second pattern is for a control protocol to connect to a known HTTP | A second pattern is for a control protocol to connect to a known HTTP | |||
| end point. This is easily described in MUD. Within that control | end point. This is easily described in MUD. Within that control | |||
| protocol references are made to additional content at other URLs. | protocol references are made to additional content at other URLs. | |||
| The values of those URLs do not fit any easily described pattern and | The values of those URLs do not fit any easily described pattern and | |||
| may point at arbitrary names. | may point at arbitrary names. | |||
| Those names are often within some third-party Content-Distribution- | Those names are often within some third-party Content-Distribution- | |||
| Network (CDN) system, or may be arbitrary names in a cloud-provider | Network (CDN) system, or may be arbitrary names in a cloud-provider | |||
| storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). | storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). | |||
| Since it is not possible to predict a name for where the content will | Such names may be unpredictably chosen by the content provider, and | |||
| be, it is not possible to include that into the MUD file. | not the content owner, and so impossible to insert into a MUD file. | |||
| This applies to the firmware update situation as well. | Even if the content provider chosen names are deterministic they may | |||
| change at a rate much faster than MUD files can be updated. | ||||
| This in particular may apply to the location where firmware updates | ||||
| may be retrieved. | ||||
| 4.3. Use of a too inclusive DNS name | 4.3. Use of a too inclusive DNS name | |||
| Some CDNs make all customer content at a single URL (such as | Some CDNs make all customer content at a single URL (such as | |||
| s3.amazonaws.com). This seems to be ideal from a MUD point of view: | s3.amazonaws.com). This seems to be ideal from a MUD point of view: | |||
| a completely predictable URL. The problem is that a compromised | a completely predictable URL. | |||
| device could then connect to any S3 bucket, potentially attacking | ||||
| other buckets. | The problem is that a compromised device could then connect to the | |||
| contents of any bucket, potentially attacking the data from other | ||||
| customers. | ||||
| Exactly what the risk is depends upon what the other customers are | ||||
| doing: it could be limited to simply causing a distributed denial of | ||||
| service attack resulting to high costs to those customers, or such an | ||||
| attack could potentially include writing content. | ||||
| Amazon has recognized the problems associated with this practice, and | Amazon has recognized the problems associated with this practice, and | |||
| aims to change it to a virtual hosting model, as per | aims to change it to a virtual hosting model, as per | |||
| [awss3virtualhosting]. | [awss3virtualhosting]. | |||
| The MUD ACLs provide only for permitting end points (hostnames and | The MUD ACLs provide only for permitting end points (hostnames and | |||
| ports), but do not filter URLs (nor could filtering be enforced | ports), but do not filter URLs (nor could filtering be enforced | |||
| within HTTPS). | within HTTPS). | |||
| 5. DNS privacy and outsourcing versus MUD controllers | 5. DNS privacy and outsourcing versus MUD controllers | |||
| [RFC7858] and [RFC8094] provide for DNS over TLS (DoT) and DNS over | [RFC7858] and [RFC8094] provide for DNS over TLS (DoT) and DNS over | |||
| HTTPS (DoH). [I-D.ietf-dnsop-terminology-ter] details the terms. | HTTPS (DoH). [I-D.ietf-dnsop-terminology-ter] details the terms. | |||
| But, even with traditional DNS over Port-53 (Do53), it is possible to | But, even with traditional DNS over Port-53 (Do53), it is possible to | |||
| outsource DNS queries to other public services, such as those | outsource DNS queries to other public services, such as those | |||
| operated by Google, CloudFlare, Verisign, etc. | operated by Google, CloudFlare, Verisign, etc. | |||
| There are significant privacy issues with having IoT devices sending | For some users and classes of device, revealing the DNS queries to | |||
| their DNS queries to an outside entity. Doing it over a secure | those outside entities may consititute a privacy concern. For other | |||
| transport (DoT/DoH) is clearly better than doing so on port 53. The | users the use of an insecure local resolver may constitute a privacy | |||
| providers of the secure resolver service will, however, still see the | concern. | |||
| IoT device queries. | ||||
| A described above in Section 3 the MUD controller needs to have | A described above in Section 3 the MUD controller needs to have | |||
| access to the same resolver(s) as the IoT device. Use of the QuadX | access to the same resolver(s) as the IoT device. | |||
| resolvers (such as Google's 8.8.8.8) at first seems to present less | ||||
| of a problem than use of some other less well known resolver. While | ||||
| any system may use QuadX, in most cases those services are massively | ||||
| replicated via anycast: there is no guarantee that a MUD controller | ||||
| will speak to the same instance, or get the same geographic anycast | ||||
| result. | ||||
| XXX - THIS NEEDS WAY MORE EXPLANATION. | ||||
| 6. Recommendations to IoT device manufacturer on MUD and DNS usage | 6. Recommendations to IoT device manufacturer on MUD and DNS usage | |||
| Inclusion of a MUD file with IoT devices is operationally quite | Inclusion of a MUD file with IoT devices is operationally quite | |||
| simple. It requires only a few small changes to the DHCP client code | simple. It requires only a few small changes to the DHCP client code | |||
| to express the MUD URL. It can even be done without code changes via | to express the MUD URL. It can even be done without code changes via | |||
| the use of a QR code affixed to the packaging (see | the use of a QR code affixed to the packaging (see | |||
| [I-D.richardson-mud-qrcode]. | [I-D.richardson-mud-qrcode]. | |||
| The difficult part is determining what to put into the MUD file | The difficult part is determining what to put into the MUD file | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at page 10, line 42 ¶ | |||
| more reliable answer. | more reliable answer. | |||
| 6.4. Do not use geofenced names | 6.4. Do not use geofenced names | |||
| Due the problems with different answers from different DNS servers, | Due the problems with different answers from different DNS servers, | |||
| described above, a strong recommendation is to avoid using such | described above, a strong recommendation is to avoid using such | |||
| things. | things. | |||
| 6.5. Prefer DNS servers learnt from DHCP/Route Advertisements | 6.5. Prefer DNS servers learnt from DHCP/Route Advertisements | |||
| XXX - it has been suggested that this will not help, thus previous | ||||
| recommendation. | ||||
| IoT Devices should prefer doing DNS to the network provided DNS | IoT Devices should prefer doing DNS to the network provided DNS | |||
| servers. Whether this is restricted to Classic DNS (Do53) or also | servers. Whether this is restricted to Classic DNS (Do53) or also | |||
| includes using DoT/DoH is a local decision, but a locally provided | includes using DoT/DoH is a local decision, but a locally provided | |||
| DoT server SHOULD be used, as recommended by | DoT server SHOULD be used, as recommended by | |||
| [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. | [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. | |||
| The ADD WG is currently only focusing on insecure discovery | The ADD WG is currently only focusing on insecure discovery | |||
| mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery | mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery | |||
| mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network | mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network | |||
| provided DoH/DoT resolver is possible using the mechanisms discussed | provided DoH/DoT resolver is possible using the mechanisms discussed | |||
| in [I-D.reddy-add-enterprise] section-4. | in [I-D.reddy-add-enterprise] section-4. | |||
| Use of public QuadX resolver instead of the provided DNS resolver, | Use of public QuadX resolver instead of the provided DNS resolver, | |||
| whether Do53, DoT or DoH is discouraged. Should the network provide | whether Do53, DoT or DoH is discouraged. Should the network provide | |||
| such a resolver for use, then there is no reason not to use it, as | such a resolver for use, then there is no reason not to use it, as | |||
| the network operator has clearly thought about this. | the network operator has clearly thought about this. | |||
| Some manufacturers would like to have a fallback to using a public | Some manufacturers would like to have a fallback to using a public | |||
| resolver to mitigate against local misconfiguration. There are a | resolver to mitigate against local misconfiguration. There are a | |||
| number of reasons to avoid this, or at least do this very carefully. | number of reasons to avoid this, or at least do this very carefully. | |||
| The recommendation here is to do this only when the provided | ||||
| resolvers provide no answers to any queries at all, and do so | It is recommended that use of non-local resolvers is only done when | |||
| repeatedly. The use of the operator provided resolvers SHOULD be | the locally provided resolvers provide no answers to any queries at | |||
| retried on a periodic basis, and once they answer, there should be no | all, and do so repeatedly. The use of the operator provided | |||
| further attempts to contact public resolvers. | resolvers SHOULD be retried on a periodic basis, and once they | |||
| answer, there should be no further attempts to contact public | ||||
| resolvers. | ||||
| Finally, the list of public resolvers that might be contacted MUST be | Finally, the list of public resolvers that might be contacted MUST be | |||
| listed in the MUD file as destinations that are to be permitted! | listed in the MUD file as destinations that are to be permitted! | |||
| This should include the port numbers (53, 853 for DoT, 443 for DoH) | This should include the port numbers (53, 853 for DoT, 443 for DoH) | |||
| that will be used as well. | that will be used as well. | |||
| 7. Privacy Considerations | 7. Privacy Considerations | |||
| The use of non-local DNS servers exposes the list of names resolved | The use of non-local DNS servers exposes the list of names resolved | |||
| to a third parties, including passive eavesdroppers. | to a third parties, including passive eavesdroppers. | |||
| skipping to change at page 15, line 8 ¶ | skipping to change at page 15, line 8 ¶ | |||
| Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. | Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. | |||
| Jensen, "DHCP and Router Advertisement Options for | Jensen, "DHCP and Router Advertisement Options for | |||
| Encrypted DNS Discovery", Work in Progress, Internet- | Encrypted DNS Discovery", Work in Progress, Internet- | |||
| Draft, draft-btw-add-home-12, 22 January 2021, | Draft, draft-btw-add-home-12, 22 January 2021, | |||
| <https://www.ietf.org/archive/id/draft-btw-add-home- | <https://www.ietf.org/archive/id/draft-btw-add-home- | |||
| 12.txt>. | 12.txt>. | |||
| [I-D.pauly-dprive-oblivious-doh] | [I-D.pauly-dprive-oblivious-doh] | |||
| Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. | Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. | |||
| Wood, "Oblivious DNS Over HTTPS", Work in Progress, | Wood, "Oblivious DNS Over HTTPS", Work in Progress, | |||
| Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5 | Internet-Draft, draft-pauly-dprive-oblivious-doh-11, 17 | |||
| January 2022, <https://www.ietf.org/archive/id/draft- | February 2022, <https://www.ietf.org/archive/id/draft- | |||
| pauly-dprive-oblivious-doh-09.txt>. | pauly-dprive-oblivious-doh-11.txt>. | |||
| [I-D.reddy-add-enterprise] | [I-D.reddy-add-enterprise] | |||
| Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS | Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS | |||
| Server Deployment Considerations for Enterprise Networks", | Server Deployment Considerations for Enterprise Networks", | |||
| Work in Progress, Internet-Draft, draft-reddy-add- | Work in Progress, Internet-Draft, draft-reddy-add- | |||
| enterprise-00, 23 June 2020, | enterprise-00, 23 June 2020, | |||
| <https://www.ietf.org/archive/id/draft-reddy-add- | <https://www.ietf.org/archive/id/draft-reddy-add- | |||
| enterprise-00.txt>. | enterprise-00.txt>. | |||
| [I-D.richardson-mud-qrcode] | [I-D.richardson-mud-qrcode] | |||
| Richardson, M., Latour, J., and H. H. Gharakheili, "On | Richardson, M., Latour, J., and H. H. Gharakheili, "On | |||
| loading MUD URLs from QR codes", Work in Progress, | loading MUD URLs from QR codes", Work in Progress, | |||
| Internet-Draft, draft-richardson-mud-qrcode-03, 11 January | Internet-Draft, draft-richardson-mud-qrcode-07, 21 March | |||
| 2022, <https://www.ietf.org/archive/id/draft-richardson- | 2022, <https://www.ietf.org/archive/id/draft-richardson- | |||
| mud-qrcode-03.txt>. | mud-qrcode-07.txt>. | |||
| [mudmaker] "Mud Maker", 2019, <https://mudmaker.org>. | [mudmaker] "Mud Maker", 2019, <https://mudmaker.org>. | |||
| [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | |||
| Extensions: Extension Definitions", RFC 6066, | Extensions: Extension Definitions", RFC 6066, | |||
| DOI 10.17487/RFC6066, January 2011, | DOI 10.17487/RFC6066, January 2011, | |||
| <https://www.rfc-editor.org/info/rfc6066>. | <https://www.rfc-editor.org/info/rfc6066>. | |||
| Appendix A. Appendices | Appendix A. Appendices | |||
| End of changes. 24 change blocks. | ||||
| 51 lines changed or deleted | 68 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||