draft-ietf-dnsop-rfc2845bis-05.txt   draft-ietf-dnsop-rfc2845bis-06.txt 
Internet Engineering Task Force F. Dupont Internet Engineering Task Force F. Dupont
Internet-Draft S. Morris Internet-Draft S. Morris
Obsoletes: 2845, 4635 (if approved) ISC Obsoletes: 2845, 4635 (if approved) ISC
Intended status: Standards Track P. Vixie Intended status: Standards Track P. Vixie
Expires: January 8, 2020 Farsight Expires: May 4, 2020 Farsight
D. Eastlake 3rd D. Eastlake 3rd
Huawei Futurewei
O. Gudmundsson O. Gudmundsson
CloudFlare CloudFlare
B. Wellington B. Wellington
Akamai Akamai
July 7, 2019 November 1, 2019
Secret Key Transaction Authentication for DNS (TSIG) Secret Key Transaction Authentication for DNS (TSIG)
draft-ietf-dnsop-rfc2845bis-05 draft-ietf-dnsop-rfc2845bis-06
Abstract Abstract
This document describes a protocol for transaction level This document describes a protocol for transaction level
authentication using shared secrets and one way hashing. It can be authentication using shared secrets and one way hashing. It can be
used to authenticate dynamic updates as coming from an approved used to authenticate dynamic updates as coming from an approved
client, or to authenticate responses as coming from an approved name client, or to authenticate responses as coming from an approved name
server. server.
No recommendation is made here for distributing the shared secrets: No recommendation is made here for distributing the shared secrets:
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 8, 2020. This Internet-Draft will expire on May 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 42 skipping to change at page 2, line 42
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Document History . . . . . . . . . . . . . . . . . . . . 4 1.3. Document History . . . . . . . . . . . . . . . . . . . . 4
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 5 3. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 5
4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5 4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5
4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 5 4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 6
4.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 8 4.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Request MAC . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Request MAC . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 9
4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 8 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 9
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 9 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 10
5.2. Server Processing of Request . . . . . . . . . . . . . . 10 5.2. Server Processing of Request . . . . . . . . . . . . . . 10
5.2.1. Key Check and Error Handling . . . . . . . . . . . . 10 5.2.1. Key Check and Error Handling . . . . . . . . . . . . 11
5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11 5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11
5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12 5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12
5.2.4. Truncation Check and Error Handling . . . . . . . . . 12 5.2.4. Truncation Check and Error Handling . . . . . . . . . 12
5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 12 5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 13
5.3.1. TSIG on Zone Transfer Over a TCP Connection . . . . . 13 5.3.1. TSIG on Zone Transfer Over a TCP Connection . . . . . 13
5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14 5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14
5.4. Client Processing of Answer . . . . . . . . . . . . . . . 14 5.4. Client Processing of Answer . . . . . . . . . . . . . . . 14
5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 14 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 15
5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15 5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15
5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15 5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15
5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 15 5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 15
5.5. Special Considerations for Forwarding Servers . . . . . . 15 5.5. Special Considerations for Forwarding Servers . . . . . . 16
6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16
7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 16 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 17
8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17 8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 19 10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 19
10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 19 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
Appendix B. Change History (to be removed before publication) . 23 Appendix B. Change History (to be removed before publication) . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
1.1. Background 1.1. Background
The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated
hierarchical distributed database system that provides information hierarchical distributed database system that provides information
fundamental to Internet operations, such as name to address fundamental to Internet operations, such as name to address
translation and mail handling information. translation and mail handling information.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
this case the data covered would be the whole zone transfer including this case the data covered would be the whole zone transfer including
any glue records sent. The protocol described by DNSSEC ([RFC4033], any glue records sent. The protocol described by DNSSEC ([RFC4033],
[RFC4034], [RFC4035]) does not protect glue records and unsigned [RFC4034], [RFC4035]) does not protect glue records and unsigned
records unless SIG(0) (transaction signature) is used. records unless SIG(0) (transaction signature) is used.
The authentication mechanism proposed in this document uses shared The authentication mechanism proposed in this document uses shared
secret keys to establish a trust relationship between two entities. secret keys to establish a trust relationship between two entities.
Such keys must be protected in a manner similar to private keys, lest Such keys must be protected in a manner similar to private keys, lest
a third party masquerade as one of the intended parties (by forging a third party masquerade as one of the intended parties (by forging
the MAC). There is an urgent need to provide simple and efficient the MAC). There was a need to provide simple and efficient
authentication between clients and local servers and this proposal authentication between clients and local servers and this proposal
addresses that need. The proposal is unsuitable for general server addresses that need. The proposal is unsuitable for general server
to server authentication for servers which speak with many other to server authentication for servers which speak with many other
servers, since key management would become unwieldy with the number servers, since key management would become unwieldy with the number
of shared keys going up quadratically. But it is suitable for many of shared keys going up quadratically. But it is suitable for many
resolvers on hosts that only talk to a few recursive servers. resolvers on hosts that only talk to a few recursive servers.
1.2. Protocol Overview 1.2. Protocol Overview
Secret Key Transaction Authentication makes use of signatures on Secret Key Transaction Authentication makes use of signatures on
skipping to change at page 4, line 35 skipping to change at page 4, line 35
The way that this agreement is reached is outside the scope of the The way that this agreement is reached is outside the scope of the
document. document.
A DNS message exchange involves the sending of a query and the A DNS message exchange involves the sending of a query and the
receipt of one of more DNS messages in response. For the query, the receipt of one of more DNS messages in response. For the query, the
MAC is calculated based on the hash of the contents and the agreed MAC is calculated based on the hash of the contents and the agreed
TSIG key. The MAC for the response is similar, but also includes the TSIG key. The MAC for the response is similar, but also includes the
MAC of the query as part of the calculation. Where a response MAC of the query as part of the calculation. Where a response
comprises multiple packets, the calculation of the MAC associated comprises multiple packets, the calculation of the MAC associated
with the second and subsequent packets includes in its inputs the MAC with the second and subsequent packets includes in its inputs the MAC
for the the preceding packet. In this way it is possible to detect for the preceding packet. In this way it is possible to detect any
any interruption in the packet sequence. interruption in the packet sequence.
The MAC is contained in a TSIG resource record included in the The MAC is contained in a TSIG resource record included in the
Additional Section of the DNS message. Additional Section of the DNS message.
1.3. Document History 1.3. Document History
TSIG was originally specified by [RFC2845]. In 2017, two nameservers TSIG was originally specified by [RFC2845]. In 2017, two nameservers
strictly following that document (and the related [RFC4635]) were strictly following that document (and the related [RFC4635]) were
discovered to have security problems related to this feature. The discovered to have security problems related to this feature. The
implementations were fixed but, to avoid similar problems in the implementations were fixed but, to avoid similar problems in the
future, the two documents were updated and merged, producing this future, the two documents were updated and merged, producing this
revised specification for TSIG. revised specification for TSIG.
While TSIG implemented according to this RFC provides for enhanced
security, there are no changes in interoperability. TSIG is on the
wire still the same mechanism described in [RFC2845]; only the
checking semantics have been changed. See Section 10.1 for further
details.
2. Key Words 2. Key Words
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Assigned Numbers 3. Assigned Numbers
skipping to change at page 6, line 12 skipping to change at page 6, line 18
multi-octet integers in the record are sent in network byte order multi-octet integers in the record are sent in network byte order
(see [RFC1035] 2.3.2). (see [RFC1035] 2.3.2).
NAME The name of the key used in domain name syntax. The name NAME The name of the key used in domain name syntax. The name
should reflect the names of the hosts and uniquely identify the should reflect the names of the hosts and uniquely identify the
key among a set of keys these two hosts may share at any given key among a set of keys these two hosts may share at any given
time. If hosts A.site.example and B.example.net share a key, time. If hosts A.site.example and B.example.net share a key,
possibilities for the key name include <id>.A.site.example, possibilities for the key name include <id>.A.site.example,
<id>.B.example.net, and <id>.A.site.example.B.example.net. It <id>.B.example.net, and <id>.A.site.example.B.example.net. It
should be possible for more than one key to be in simultaneous should be possible for more than one key to be in simultaneous
use among a set of interacting hosts. The name only needs to use among a set of interacting hosts.
be meaningful to the communicating hosts but a meaningful
mnemonic name as suggested above is strongly recommended.
The name may be used as a local index to the key involved and The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually need only be just shared between two hosts, its name actually need only be
meaningful to them but it is recommended that the key name be meaningful to them but it is recommended that the key name be
mnemonic and incorporates the names of participating agents or mnemonic and incorporates the names of participating agents or
resources. resources as suggested above.
TYPE This MUST be TSIG (250: Transaction SIGnature) TYPE This MUST be TSIG (250: Transaction SIGnature)
CLASS This MUST be ANY CLASS This MUST be ANY
TTL This MUST be 0 TTL This MUST be 0
RdLen (variable) RdLen (variable)
RDATA The RDATA for a TSIG RR consists of a number of fields, RDATA The RDATA for a TSIG RR consists of a number of fields,
skipping to change at page 8, line 7 skipping to change at page 8, line 23
of the "Other Data" field in octets. of the "Other Data" field in octets.
* Other Data - this unsigned 48-bit integer field will be * Other Data - this unsigned 48-bit integer field will be
empty unless the content of the Error field is BADTIME, in empty unless the content of the Error field is BADTIME, in
which case it will contain the server's current time as the which case it will contain the server's current time as the
number of seconds since 00:00 on 1970-01-01 UTC, ignoring number of seconds since 00:00 on 1970-01-01 UTC, ignoring
leap seconds (see Section 5.2.3). leap seconds (see Section 5.2.3).
4.3. MAC Computation 4.3. MAC Computation
When generating or verifying the contents of a TSIG record, the the When generating or verifying the contents of a TSIG record, the data
data listed in the rest of this section are passed, in the order listed in the rest of this section are passed, in the order listed
listed below, as input to MAC computation. The data are passed in below, as input to MAC computation. The data are passed in network
network byte order or wire format, as appropriate, and are fed into byte order or wire format, as appropriate, and are fed into the
the hashing function as a continuous octet sequence with no hashing function as a continuous octet sequence with no interfield
interfield separator or padding. separator or padding.
4.3.1. Request MAC 4.3.1. Request MAC
Only included in the computation of a MAC for a response message (or Only included in the computation of a MAC for a response message (or
the first message in a multi-message response), the validated request the first message in a multi-message response), the validated request
MAC MUST be included in the MAC computation. If the request MAC MAC MUST be included in the MAC computation. If the request MAC
failed to validate, an unsigned error message MUST be returned failed to validate, an unsigned error message MUST be returned
instead. (Section 5.3.2). instead. (Section 5.3.2).
The request's MAC, comprising the following fields, is digested in The request's MAC, comprising the following fields, is digested in
skipping to change at page 10, line 29 skipping to change at page 10, line 52
record in the additional section. Multiple TSIG records are not record in the additional section. Multiple TSIG records are not
allowed. If multiple TSIG records are detected or a TSIG record is allowed. If multiple TSIG records are detected or a TSIG record is
present in any other position, the DNS message is dropped and a present in any other position, the DNS message is dropped and a
response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a
message with exactly one correctly placed TSIG RR, the TSIG RR is message with exactly one correctly placed TSIG RR, the TSIG RR is
copied to a safe location, removed from the DNS Message, and copied to a safe location, removed from the DNS Message, and
decremented out of the DNS message header's ARCOUNT. decremented out of the DNS message header's ARCOUNT.
If the TSIG RR cannot be understood, the server MUST regard the If the TSIG RR cannot be understood, the server MUST regard the
message as corrupt and return a FORMERR to the server. Otherwise the message as corrupt and return a FORMERR to the server. Otherwise the
the server is REQUIRED to return a TSIG RR in the response. server is REQUIRED to return a TSIG RR in the response.
To validate the received TSIG RR, the server MUST perform the To validate the received TSIG RR, the server MUST perform the
following checks in the following order: following checks in the following order:
1. Check KEY 1. Check KEY
2. Check MAC 2. Check MAC
3. Check TIME values 3. Check TIME values
4. Check Truncation policy 4. Check Truncation policy
5.2.1. Key Check and Error Handling 5.2.1. Key Check and Error Handling
skipping to change at page 13, line 44 skipping to change at page 14, line 12
Prior MAC (running) Prior MAC (running)
DNS Messages (any unsigned messages since the last TSIG) DNS Messages (any unsigned messages since the last TSIG)
TSIG Timers (current message) TSIG Timers (current message)
The "Prior MAC" is the MAC from the TSIG attached to the last message The "Prior MAC" is the MAC from the TSIG attached to the last message
containing a TSIG. "DNS Messages" comprises the concatenation (in containing a TSIG. "DNS Messages" comprises the concatenation (in
message order) of all messages after the last message that included a message order) of all messages after the last message that included a
TSIG and includes the current message. "TSIG timers" comprises the TSIG and includes the current message. "TSIG timers" comprises the
"Time Signed" and "Fudge" fields (in that order) pertaining to the "Time Signed" and "Fudge" fields (in that order) pertaining to the
message for which the TSIG is being created: this means that the message for which the TSIG is being created: this means that the
successive TSIG records in the stream will have monotonically successive TSIG records in the stream will have non-decreasing "Time
increasing "Time Signed" fields. Note that only the timers are Signed" fields. Note that only the timers are included in the second
included in the second and subsequent messages, not all the TSIG and subsequent messages, not all the TSIG variables.
variables.
This allows the client to rapidly detect when the session has been This allows the client to rapidly detect when the session has been
altered; at which point it can close the connection and retry. If a altered; at which point it can close the connection and retry. If a
client TSIG verification fails, the client MUST close the connection. client TSIG verification fails, the client MUST close the connection.
If the client does not receive TSIG records frequently enough (as If the client does not receive TSIG records frequently enough (as
specified above) it SHOULD assume the connection has been hijacked specified above) it SHOULD assume the connection has been hijacked
and it SHOULD close the connection. The client SHOULD treat this the and it SHOULD close the connection. The client SHOULD treat this the
same way as they would any other interrupted transfer (although the same way as they would any other interrupted transfer (although the
exact behavior is not specified here). exact behavior is not specified here).
5.3.2. Generation of TSIG on Error Returns 5.3.2. Generation of TSIG on Error Returns
When a server detects an error relating to the key or MAC in the When a server detects an error relating to the key or MAC in the
incoming request, the server SHOULD send back an unsigned error incoming request, the server SHOULD send back an unsigned error
skipping to change at page 23, line 19 skipping to change at page 23, line 34
have questions like correct spelling... have questions like correct spelling...
Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund
Sivaraman and Ralph Dolmans participated in the discussions that Sivaraman and Ralph Dolmans participated in the discussions that
prompted this document. Mukund Sivaraman and Martin Hoffman made prompted this document. Mukund Sivaraman and Martin Hoffman made
extremely helpful suggestions concerning the structure and wording of extremely helpful suggestions concerning the structure and wording of
the updated document. the updated document.
Appendix B. Change History (to be removed before publication) Appendix B. Change History (to be removed before publication)
RFC EDITOR: Please remove this appendix before publication.
draft-dupont-dnsop-rfc2845bis-00 draft-dupont-dnsop-rfc2845bis-00
[RFC4635] was merged. [RFC4635] was merged.
Authors of original documents were moved to Acknowledgments Authors of original documents were moved to Acknowledgments
(Appendix A). (Appendix A).
Section 2 was updated to [RFC8174] style. Section 2 was updated to [RFC8174] style.
Spit references into normative and informative references and Spit references into normative and informative references and
skipping to change at page 25, line 47 skipping to change at page 26, line 17
draft-ietf-dnsop-rfc2845bis-05 draft-ietf-dnsop-rfc2845bis-05
Make implementation of HMAC-MD5 optional. Make implementation of HMAC-MD5 optional.
Require that the Fudge field in BADTIME response be equal to the Require that the Fudge field in BADTIME response be equal to the
Fudge field received from the client. Fudge field received from the client.
Added comment concerning the handling of BADTIME messages due to Added comment concerning the handling of BADTIME messages due to
out of order packet reception. out of order packet reception.
draft-ietf-dnsop-rfc2845bis-06
Wording changes and minor corrections after feedback.
Authors' Addresses Authors' Addresses
Francis Dupont Francis Dupont
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States of America United States of America
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
Stephen Morris Stephen Morris
Internet Software Consortium Internet Software Consortium
skipping to change at page 26, line 18 skipping to change at page 26, line 37
United States of America United States of America
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
Stephen Morris Stephen Morris
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States of America United States of America
Email: stephen@isc.org Email: sa.morris8@gmail.com
Paul Vixie Paul Vixie
Farsight Security Inc Farsight Security Inc
177 Bovet Road, Suite 180 177 Bovet Road, Suite 180
San Mateo, CA 94402 San Mateo, CA 94402
United States of America United States of America
Email: paul@redbarn.org Email: paul@redbarn.org
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Huawei Technologies Futurewei Technologies
155 Beaver Street 155 Beaver Street
Milford, MA 01753 Milford, MA 01753
United States of America United States of America
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Olafur Gudmundsson Olafur Gudmundsson
CloudFlare CloudFlare
San Francisco, CA 94107 San Francisco, CA 94107
United States of America United States of America
 End of changes. 31 change blocks. 
41 lines changed or deleted 49 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/