draft-ietf-dprive-dnsodtls-03.txt   draft-ietf-dprive-dnsodtls-04.txt 
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track P. Patil Intended status: Standards Track P. Patil
Expires: May 27, 2016 Cisco Expires: July 24, 2016 Cisco
November 24, 2015 January 21, 2016
DNS over DTLS (DNSoD) DNS over DTLS (DNSoD)
draft-ietf-dprive-dnsodtls-03 draft-ietf-dprive-dnsodtls-04
Abstract Abstract
DNS queries and responses are visible to network elements on the path DNS queries and responses are visible to network elements on the path
between the DNS client and its server. These queries and responses between the DNS client and its server. These queries and responses
can contain privacy-sensitive information which is valuable to can contain privacy-sensitive information which is valuable to
protect. An active attacker can send bogus responses causing protect. An active attacker can send bogus responses causing
misdirection of the subsequent connection. misdirection of the subsequent connection.
To counter passive listening and active attacks, this document To counter passive listening and active attacks, this document
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 27, 2016. This Internet-Draft will expire on July 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 28 skipping to change at page 2, line 28
1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3 1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS session initiation, Polling and Discovery . . . . . . . 3 3. DTLS session initiation, Polling and Discovery . . . . . . . 3
4. Performance Considerations . . . . . . . . . . . . . . . . . 4 4. Performance Considerations . . . . . . . . . . . . . . . . . 4
5. Established sessions . . . . . . . . . . . . . . . . . . . . 5 5. Established sessions . . . . . . . . . . . . . . . . . . . . 5
6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7 7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8 9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS
queries and responses are normally exchanged unencrypted and are thus queries and responses are normally exchanged unencrypted and are thus
vulnerable to eavesdropping. Such eavesdropping can result in an vulnerable to eavesdropping. Such eavesdropping can result in an
undesired entity learning domains that a host wishes to access, thus undesired entity learning domains that a host wishes to access, thus
resulting in privacy leakage. DNS privacy problem is further resulting in privacy leakage. DNS privacy problem is further
discussed in [I-D.bortzmeyer-dnsop-dns-privacy]. discussed in [RFC7626].
Active attackers have long been successful at injecting bogus Active attackers have long been successful at injecting bogus
responses, causing cache poisoning and causing misdirection of the responses, causing cache poisoning and causing misdirection of the
subsequent connection (if attacking A or AAAA records). A popular subsequent connection (if attacking A or AAAA records). A popular
mitigation against that attack is to use ephemeral and random source mitigation against that attack is to use ephemeral and random source
ports for DNS queries [RFC5452]. ports for DNS queries [RFC5452].
This document defines DNS over DTLS (DNSoD, pronounced "dee-enn-sod") This document defines DNS over DTLS (DNSoD, pronounced "dee-enn-sod")
which provides confidential DNS communication for stub resolvers, which provides confidential DNS communication between stub resolvers
recursive resolvers, iterative resolvers and authoritative servers. and recursive resolvers, stub resolvers and forwarders, forwarders
and recursive resolvers.
The motivations for proposing DNSoD are that The motivations for proposing DNSoD are that
o TCP suffers from network head-of-line blocking, where the loss of o TCP suffers from network head-of-line blocking, where the loss of
a packet causes all other TCP segments to not be delivered to the a packet causes all other TCP segments to not be delivered to the
application until the lost packet is re-transmitted. DNSoD, application until the lost packet is re-transmitted. DNSoD,
because it uses UDP, does not suffer from network head-of-line because it uses UDP, does not suffer from network head-of-line
blocking. blocking.
o DTLS session resumption consumes 1 round trip whereas TLS session o DTLS session resumption consumes 1 round trip whereas TLS session
skipping to change at page 3, line 40 skipping to change at page 3, line 40
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. DTLS session initiation, Polling and Discovery 3. DTLS session initiation, Polling and Discovery
Many modern operating systems already detect if a web proxy is
interfering with Internet communications, using proprietary
mechanisms that are out of scope of this document. After that
mechanism has run (and detected Internet connectivity is working),
the DNSoD procedure described in this document should commence. This
timing avoids delays in joining the network (and displaying an icon
indicating successful Internet connection), at the risk that those
initial DNS queries will be sent without protection afforded by
DNSoD.
DNSoD MUST run over standard UDP port 853 as defined in Section 8. A DNSoD MUST run over standard UDP port 853 as defined in Section 8. A
DNS server that supports DNSoD MUST listen for and accept DTLS DNS server that supports DNSoD MUST listen for and accept DTLS
packets on a designated port 853. packets on a designated port 853.
The host should determine if the DNS server supports DNSoD by sending The host should determine if the DNS server supports DNSoD by sending
a DTLS ClientHello message. A DNS server that does not support DNSoD a DTLS ClientHello message. A DNS server that does not support DNSoD
will not respond to ClientHello messages sent by the client. The will not respond to ClientHello messages sent by the client. The
client MUST use timer values defined in Section 4.2.4.1 of [RFC6347] client MUST use timer values defined in Section 4.2.4.1 of [RFC6347]
for retransmission of ClientHello message and if no response is for retransmission of ClientHello message and if no response is
received from the DNS server. After 15 seconds, it MUST cease received from the DNS server. After 15 seconds, it MUST cease
skipping to change at page 4, line 41 skipping to change at page 4, line 31
DNSoD client need not wait for an outstanding reply before sending DNSoD client need not wait for an outstanding reply before sending
the next query. The existing Query ID allows multiple requests and the next query. The existing Query ID allows multiple requests and
responses to be interleaved in whatever order they can be fulfilled responses to be interleaved in whatever order they can be fulfilled
by the DNS server. This means DNSoD reduces the consumption of UDP by the DNS server. This means DNSoD reduces the consumption of UDP
port numbers, and because DTLS protects the communication between a port numbers, and because DTLS protects the communication between a
DNS client and its server, the resolver SHOULD NOT use random DNS client and its server, the resolver SHOULD NOT use random
ephemeral source ports (Section 9.2 of [RFC5452]) because such source ephemeral source ports (Section 9.2 of [RFC5452]) because such source
port use would incur additional, unnecessary DTLS load on the DNSoD port use would incur additional, unnecessary DTLS load on the DNSoD
server. When sending multiple queries over a single DTLS session, server. When sending multiple queries over a single DTLS session,
clients MUST take care to avoid Message ID collisions. In other clients MUST take care to avoid Message ID collisions. In other
words, they MUST not re-use the DNS Message ID of an in-flight query. words, they MUST NOT re-use the DNS Message ID of an in-flight query.
It is highly advantageous to avoid server-side DTLS state and reduce It is highly advantageous to avoid server-side DTLS state and reduce
the number of new DTLS sessions on the server which can be done with the number of new DTLS sessions on the server which can be done with
[RFC5077]. This also eliminates a round-trip for subsequent DNSoD [RFC5077]. This also eliminates a round-trip for subsequent DNSoD
queries, because with [RFC5077] the DTLS session does not need to be queries, because with [RFC5077] the DTLS session does not need to be
re-established. re-established.
Compared to normal DNS, DTLS adds at least 13 octets of header, plus Compared to normal DNS, DTLS adds at least 13 octets of header, plus
cipher and authentication overhead to every query and every response. cipher and authentication overhead to every query and every response.
This reduces the size of the DNS payload that can be carried. DNS This reduces the size of the DNS payload that can be carried. DNS
client and server MUST support the EDNS0 option defined in [RFC6891] client and server MUST support the EDNS0 option defined in [RFC6891]
so that the DNS client can indicate to the DNS server the maximum DNS so that the DNS client can indicate to the DNS server the maximum DNS
response size it can handle without IP fragmentation. If the DNS response size it can handle without IP fragmentation. If the DNS
sever's response exceeds the EDNS0 value, the DNS server sets the TC server's response exceeds the EDNS0 value, the DNS server sets the TC
(truncated) bit. On receiving a response with the TC bit set, the (truncated) bit. On receiving a response with the TC bit set, the
client establishes a DNS-over-TLS connection to the same server, and client establishes a DNS-over-TLS connection to the same server, and
sends a new DNS request for the same resource record sends a new DNS request for the same resource record
DNSoD puts an additional computational load on servers. The largest DNSoD puts an additional computational load on servers. The largest
gain for privacy is to protect the communication between the DNS gain for privacy is to protect the communication between the DNS
client (the end user's machine) and its caching resolver. client (the end user's machine) and its caching resolver.
Implementing DNSoD on root servers is outside the scope of this Implementing DNSoD on root servers is outside the scope of this
document. document.
skipping to change at page 8, line 28 skipping to change at page 8, line 28
confidentiality protection and guidance given in [RFC7525] must be confidentiality protection and guidance given in [RFC7525] must be
followed to avoid attacks on DTLS. Once a DNSoD client has followed to avoid attacks on DTLS. Once a DNSoD client has
established a security association with a particular DNS server, and established a security association with a particular DNS server, and
outstanding normal DNS queries with that server (if any) have been outstanding normal DNS queries with that server (if any) have been
received, the DNSoD client MUST ignore any subsequent normal DNS received, the DNSoD client MUST ignore any subsequent normal DNS
responses from that server, as all subsequent responses should be responses from that server, as all subsequent responses should be
encrypted. This behavior mitigates all possible attacks described in encrypted. This behavior mitigates all possible attacks described in
Measures for Making DNS More Resilient against Forged Answers Measures for Making DNS More Resilient against Forged Answers
[RFC5452]. [RFC5452].
The DNS Fragment extension does not impact security of DTLS session
establishment or application data exchange. DNS Fragment provides
fragmentation and reassembly of the encrypted DNS payload.
A malicious client might attempt to perform a high number of DTLS A malicious client might attempt to perform a high number of DTLS
handshakes with a server. As the clients are not uniquely identified handshakes with a server. As the clients are not uniquely identified
by the protocol and can be obfuscated with IPv4 address sharing and by the protocol and can be obfuscated with IPv4 address sharing and
with IPv6 temporary addresses, a server needs to mitigate the impact with IPv6 temporary addresses, a server needs to mitigate the impact
of such an attack. Such mitigation might involve rate limiting of such an attack. Such mitigation might involve rate limiting
handshakes from a certain subnet or more advanced DoS/DDoS techniques handshakes from a certain subnet or more advanced DoS/DDoS techniques
beyond the scope of this paper. beyond the scope of this paper.
9.1. Authenticating a DNS Privacy Server 9.1. Authenticating a DNS Privacy Server
DNS privacy requires encrypting the query (and response) from passive DNS privacy requires encrypting the query (and response) from passive
attacks. Such encryption typically provides integrity protection as attacks. Such encryption typically provides integrity protection as
a side-effect, which means on-path attackers cannot simply inject a side-effect, which means on-path attackers cannot simply inject
bogus DNS responses. However, to provide stronger protection from bogus DNS responses. However, to provide stronger protection from
active attackers pretending to be the server, the server itself needs active attackers pretending to be the server, the server itself needs
to be authenticated. to be authenticated. To authenticate the server providing DNS
privacy, DNS client can use the authenication mechanisms discussed in
To authenticate the server providing DNS privacy, the DNS client [I-D.dgr-dprive-dtls-and-tls-profiles].
needs to be configured with the names or IP addresses of those DNS
privacy servers. The server certificate MUST contain DNS-ID
(subjectAltName) as described in Section 4.1 of [RFC6125]. DNS names
and IP addresses can be contained in the subjectAltName entries. The
client MUST use the rules and guidelines given in section 6 of
[RFC6125] to validate the DNS server identity.
This could be implemented by adding the certificate name to the /etc/
resolv.conf file, such as below:
nameserver 8.8.8.8
certificate google-public-dns.google.com
nameserver 208.67.220.220
certificate resolver.opendns.com
For DNS privacy servers that don't have a certificate trust chain
(e.g., because they are on a home network or a corporate network),
the configured list of DNS privacy servers can contain the Subject
Public Key Info (SPKI) fingerprint of the DNS privacy server (i.e., a
simple whitelist of name and SPKI fingerprint). The public key is
used for the same reasons HTTP pinning [RFC7469] uses the public key.
Raw public key-based authentication mechanism defined in [RFC7250]
can be also used to authenticate the DNS server.
This could be implemented by adding the SPKI fingerprint to the /etc/
resolv.conf file, such as below (line split for Internet Draft
formatting):
nameserver 192.168.1.1
sha256 : "d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="
The only algorithm considered at this time is "sha256", i.e., the
hash algorithm SHA256 [RFC6234]; additional algorithms may be allowed
for use in this context in the future. The quoted-string is a
sequence of base 64 digits: the base64-encoded SPKI Fingerprint
[RFC4648].
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Hedrick for his review comments on TCP and to Josh Thanks to Phil Hedrick for his review comments on TCP and to Josh
Littlefield for pointing out DNSoD load on busy servers (most notably Littlefield for pointing out DNSoD load on busy servers (most notably
root servers). The authors would like to thank Simon Josefsson, root servers). The authors would like to thank Simon Josefsson,
Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara and Sara Dickinson Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson and
for discussions and comments on the design of DNSoD. Christian Huitema for discussions and comments on the design of
DNSoD.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
skipping to change at page 10, line 24 skipping to change at page 9, line 29
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>. January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008,
<http://www.rfc-editor.org/info/rfc5288>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009, DOI 10.17487/RFC5452, January 2009,
<http://www.rfc-editor.org/info/rfc5452>. <http://www.rfc-editor.org/info/rfc5452>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 11, line 48 skipping to change at page 10, line 20
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>. 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
11.2. Informative References 11.2. Informative References
[I-D.bortzmeyer-dnsop-dns-privacy] [I-D.dgr-dprive-dtls-and-tls-profiles]
Bortzmeyer, S., "DNS privacy considerations", draft- Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
bortzmeyer-dnsop-dns-privacy-02 (work in progress), April and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
2014. draft-dgr-dprive-dtls-and-tls-profiles-00 (work in
progress), December 2015.
[I-D.ietf-dprive-dns-over-tls] [I-D.ietf-dprive-dns-over-tls]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "DNS over TLS: Initiation and Performance and P. Hoffman, "DNS over TLS: Initiation and Performance
Considerations", draft-ietf-dprive-dns-over-tls-01 (work Considerations", draft-ietf-dprive-dns-over-tls-04 (work
in progress), October 2015. in progress), January 2016.
[I-D.ietf-tls-cached-info] [I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls- (TLS) Cached Information Extension", draft-ietf-tls-
cached-info-20 (work in progress), October 2015. cached-info-21 (work in progress), December 2015.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
2004, <http://www.rfc-editor.org/info/rfc3749>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<http://www.rfc-editor.org/info/rfc6928>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
 End of changes. 24 change blocks. 
129 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/