RFC 7673

Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records

📅 published October 2015, from ietf

RFC 7673 🎀 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records

Okay bestie, this one is from the IETF (the Internet Engineering Task Force, the crew that writes the rulebook for how the internet works) 🌸 It's RFC 7673, published in October 2015, and it's a Standards Track document, so it's an official internet standard, not just vibes 💅 The authors are T. Finch from the University of Cambridge, M. Miller from Cisco Systems, Inc., and P. Saint-Andre from &yet 🫶 Its ISSN is 2070-1721. The header has no Obsoletes or Updates line, so it doesn't replace or update any earlier RFC ✨

Abstract

Okay so the big DANE spec (RFC 6698) explains how to use TLSA records, which are protected by DNSSEC (RFC 4033), to link a server's connection endpoint to its Transport Layer Security (TLS) certificate 🔐 This basically lets domain admins say which keys their TLS servers are allowed to use. Here's the tea though 🍵 Some application protocols use SRV records (RFC 2782) to point at their target server connection endpoints indirectly, and the RFC 6698 rules just can't be applied to them. So this document gives guidelines that help those protocols find and use TLSA records 💖

Status of This Memo

This is an Internet Standards Track document 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🙌 If you want more info on Internet Standards, check out Section 2 of RFC 5741.

Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7673 🦋

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅

Table of Contents

1. Introduction ....................................................3
2. Terminology .....................................................4
3. DNS Checks ......................................................4
   3.1. SRV Query ..................................................4
   3.2. Address Queries ............................................5
   3.3. TLSA Queries ...............................................6
   3.4. Impact on TLS Usage ........................................6
4. TLS Checks ......................................................7
   4.1. SRV Records Only ...........................................7
   4.2. TLSA Records ...............................................8
5. Guidance for Protocol Authors ...................................8
6. Guidance for Server Operators ...................................8
7. Guidance for Application Developers .............................9
8. Internationalization Considerations .............................9
9. Security Considerations ........................................10
   9.1. Mixed Security Status .....................................10
   9.2. Certificate Subject Name Matching .........................10
10. References ....................................................11
   10.1. Normative References .....................................11
   10.2. Informative References ...................................12
Appendix A. Examples ..............................................13
  A.1. IMAP .......................................................13
  A.2. XMPP .......................................................13
Appendix B. Rationale .............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................16

1. Introduction ✨

Okay so the base DANE spec [RFC6698] explains how to use TLSA resource records that are secured by DNSSEC [RFC4033] to tie a target server's connection endpoint to its Transport Layer Security (TLS) certificate. That means domain admins get to specify the keys used for their domain's TLS servers 🔑 Some application protocols find connection endpoints indirectly through SRV records [RFC2782], and because of that extra step, the rules in [RFC6698] can't be applied to them directly 🙃 (The rules for SMTP [RFC5321] are different since it uses MX resource records instead of SRV records, and those are covered in [RFC7672] 💌)

This document shows how to use DANE TLSA records with SRV records. Here's the quick version 🌸

  • We rely on DNSSEC to secure the SRV records that map the desired service, transport protocol, and service domain name to the matching target server connection endpoints. Those are the target server hostnames and port numbers returned in the SRV records for that service type 🔐
  • Sure, [RFC2782] lets a service domain name advertise a bunch of SRV records, and some of them might point at endpoints that don't support TLS. But this spec is all about helping a client securely discover the connection endpoints that do support TLS 💖
  • The TLSA records for each connection endpoint are found using the transport protocol, port number, and hostname of the target server, not the service domain name 🧚
  • When DNSSEC-validated TLSA records are published for a connection endpoint, clients always use TLS when connecting, even if that endpoint also supports cleartext communication 🔒
  • If there's at least one usable TLSA record for a connection endpoint, the endpoint's TLS certificate or public key needs to match at least one of those usable TLSA records 🎯
  • If there are no usable TLSA records for a connection endpoint, the target server hostname is used as one of the acceptable reference identifiers, as described in [RFC6125]. Other reference identifiers might show up through CNAME expansion of either the service domain name or the target server hostname, as detailed in [RFC7671] 🦋
  • If there are no usable TLSA records for any connection endpoint (so the client can't securely find an endpoint that supports TLS), the client's behavior is up to the application protocol or client implementation. This might mean falling back to non-DANE behavior using the public key infrastructure [RFC5280] 🫶

2. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [RFC2119]. These are the official requirement words, so they're doing a lot of work here 👑

This document uses the definitions for "secure", "insecure", "bogus", and "indeterminate" from Section 4.3 of [RFC4035]. It also uses the acronyms from [RFC7218] for the values of TLSA fields where that makes sense 🌈

Additionally, this document uses the following terms 🧚

connection endpoint: A tuple of a fully qualified DNS hostname, transport protocol, and port number that a client uses to set up a connection to the target server.

service domain name: The fully qualified DNS domain name that identifies an application service. This corresponds to the term "source domain" from [RFC6125] 🎀

This document uses the term "target server hostname" in place of the term "derived domain" from the so-called CertID specification [RFC6125] 💖

3. DNS Checks 🔍

3.1. SRV Query

So when the client makes an SRV query, a successful result will usually be a list of one or more SRV records. It could also be a chain of CNAME/DNAME aliases that leads to such a list 🔗

NOTE: Implementers need to be aware that unsuccessful results can occur because of various DNS-related errors. Guidance on avoiding downgrade attacks can be found in Section 2.1 of [RFC7672] 🙈

For this spec to apply, the entire chain of DNS RRset(s) that comes back MUST be "secure" according to DNSSEC validation (Section 5 of [RFC4035]). If the answer comes through a chain of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME RRsets MUST also be secure 🔐

If the SRV lookup fails because the RRset is "bogus" (or it fails for reasons other than no records existing), the client MUST abort its attempt to connect to the desired service 🚫 If the lookup result is "insecure" (or no SRV records exist), this protocol doesn't apply. The client SHOULD fall back to its non-DNSSEC, non-DANE (and possibly non-SRV) behavior 🌸

When the lookup returns a "secure" RRset (possibly through a chain of "secure" CNAME/DNAME records), the client now has an authentic list of target server connection endpoints, each with weight and priority values ✨ It does server ordering and selection using those weight and priority values, and it doesn't care whether DNSSEC or TLSA records are present or absent 🧠 It also keeps track of the DNSSEC validation status of the SRV response, for use when checking certificate names (see Section 4). After that, the client can move on to making address queries on the target server hostnames, as described in the next section 🦋

3.2. Address Queries

For each SRV target server connection endpoint, the client makes A and/or AAAA queries, does DNSSEC validation on the address (A or AAAA) response, and then continues based on the results 🌟

  • If a returned RRSet is "secure", the client MUST perform a TLSA query for that target server connection endpoint, as described in the next section. 💖
  • If no returned RRsets are "secure", the client MUST NOT perform a TLSA query for that target server connection endpoint. The TLSA query would most likely fail or produce spurious results 🙅‍♀️
  • If the address record lookup fails (a validation status of either "bogus" or "indeterminate"), the client MUST NOT connect to this connection endpoint. Instead, it uses the next most appropriate SRV target. This helps prevent downgrade attacks 🛡️

3.3. TLSA Queries

The client SHALL construct the TLSA query name as described in Section 3 of [RFC6698]. It's built from the fields in the SRV record: the port number from the SRV RDATA, the transport protocol from the SRV query name, and the TLSA base domain from the SRV target server hostname 🧩

For example, here's the SRV record for IMAP (see [RFC6186]) 📬

    _imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.

That leads to this TLSA query 🎀

    _9143._tcp.imap.example.net. IN TLSA ?

3.4. Impact on TLS Usage 💅

Okay so first the client SHALL determine whether the TLSA records it got back in the previous step are usable, using Section 4.1 of [RFC6698]. This is the part that decides what happens with TLS, and it's giving very important energy 🔥

  • If the TLSA response is "secure" and usable, then the client MUST use TLS when connecting to the target server. The TLSA records get used when validating the server's certificate, as described in Section 4. ✨
  • If the TLSA response is "bogus" or "indeterminate" (or the lookup fails for reasons other than having no records), then the client MUST NOT connect to the target server. It can still try other SRV targets though 🫶
  • If the TLSA response is "insecure" (or there are no TLSA records at all), then the client SHALL carry on as if the target server had no TLSA records. It MAY connect to the target server with or without TLS, depending on the policies of the application protocol or the client implementation 🦋

4. TLS Checks 🎀

When connecting to a server, the client MUST use TLS if the responses to the SRV and TLSA queries were "secure," as described above. The next two sections are the rules for this. Section 4.2 covers cases where there's at least one usable TLSA record, and Section 4.1 covers everything else. Both apply to those secure responses 💖

4.1. SRV Records Only 🌸

If the client got zero usable TLSA certificate associations, then it SHALL validate the server's TLS certificate using the normal PKIX rules [RFC5280], or protocol-specific rules (e.g., following [RFC6125]), without any extra input from the TLSA records. In this case the client uses the info in the server certificate, plus the DNSSEC validation status of the SRV query, for its authentication checks. It SHOULD use the Server Name Indication extension (TLS SNI) [RFC6066] or whatever functional equivalent the relevant application protocol has. (For example, in the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], that's the 'to' address of the initial stream header.) The preferred name SHALL be chosen as follows. The client SHALL verify the identity asserted by the server's certificate according to Section 6 of [RFC6125], using a list of reference identifiers built as follows. (Heads up, in RFC 6125 the terms "source domain" and "derived domain" mean the same things as "service domain name" and "target server hostname" in this document 🧚) The examples below assume a service domain name of im.example.com and a target server hostname of xmpp23.hosting.example.net.

  • SRV is insecure: The reference identifiers SHALL include the service domain name, and MUST NOT include the SRV target server hostname. So include im.example.com but NOT xmpp23.hosting.example.net. The service domain name is the preferred name for TLS SNI or its equivalent 🍓
  • SRV is secure: The reference identifiers SHALL include both the service domain name and the SRV target server hostname. So include both im.example.com and xmpp23.hosting.example.net. The service domain name is still the preferred name for TLS SNI or its equivalent. This keeps the code simpler and cuts down on the chance of interoperability problems 👑

In that second case, the client will accept either identity. That way it works with servers that support this spec and servers that don't ✨

4.2. TLSA Records 🦋

If the client got one or more usable TLSA certificate associations, then it SHALL process them as described in Section 2.1 of [RFC6698].

If the TLS server's certificate (or the public key of the server's certificate) matches a usable TLSA record with certificate usage DANE-EE, then the client MUST ignore validation checks from [RFC5280] and reference identifier checks from [RFC6125]. The info in a TLSA record like that supersedes the non-key info in the certificate. Iconic behavior 😭

5. Guidance for Protocol Authors 📝

This document is about using DANE with application protocols where target servers get discovered through SRV records. It tries to give generic guidance that covers all of those protocols, but additional documents for particular application protocols could cover related topics, like:

  • Fallback logic for when a client can't connect securely to a target server by following the procedures in this document.
  • How clients should act if (1) they don't support SRV lookups, or (2) they do support SRV lookups but run into service domain names that have no SRV records.
  • Whether the application protocol has a functional equivalent to TLS SNI that it prefers.
  • Using SRV records alongside other discovery technologies, like using both SRV records and NAPTR records [RFC3403] for transport selection in the Session Initiation Protocol (SIP).

For example, [XMPP-DNA] covers these topics for XMPP 💜

6. Guidance for Server Operators 🏰

To conform to this specification, the published SRV records and the address (A and AAAA) records that come after them MUST be secured with DNSSEC. There SHOULD also be at least one TLSA record published that authenticates the server's certificate 🔐

When you use TLSA records with certificate usage DANE-EE, the deployed certificate doesn't need an identifier for either the source domain or the target server hostname. Operators should know though that servers relying only on validation through DANE-EE TLSA records might stop clients that don't support this spec from connecting with TLS successfully 😬

For TLSA records with certificate usage types other than DANE-EE, the certificate(s) MUST contain an identifier that matches:

  • the service domain name (the "source domain" in [RFC6125] terms, which is the SRV query domain), and/or
  • the target server hostname (the "derived domain" in [RFC6125] terms, which is the SRV target hostname).

Servers that support multiple service domain names (so-called "multi-tenanted environments") can use TLS SNI [RFC6066] or its functional equivalent to decide which certificate to offer. Clients that don't support this spec will indicate a preference for the service domain name, while clients that do support it will indicate the target server hostname. Still, the server decides which certificate gets presented in the TLS handshake. For example, the presented certificate might only authenticate the target server hostname 🌈

7. Guidance for Application Developers 🧑‍💻

Developers of application clients that depend on DANE-SRV usually want to get ready for connecting to the intended service as fast as possible, so end users don't have to wait as long. To make that possible, a DNS library might do the address queries and TLSA queries in parallel. (Because a TLSA record can be ignored if the address record it depends on turns out not to be secure, running TLSA queries in parallel with address queries isn't harmful from a security perspective, and it can give some operational benefits ⭐)

8. Internationalization Considerations 🌍

If any of the DNS queries are for an internationalized domain name, then they need to use the A-label form [RFC5890] 🫧

9. Security Considerations 🔒

9.1. Mixed Security Status 🙈

We don't specify that all of the target server connection endpoints for a service domain name have to be consistent about whether they have TLSA records or not. This is so partial or incremental deployment doesn't break the service. Different levels of deployment are likely if a service domain name has a third-party fallback server, for example.

The SRV sorting rules are unchanged. In particular, they haven't been altered to put secure connection endpoints ahead of insecure ones. If a site wants to be secure, it needs to deploy this protocol completely. A partial deployment isn't secure, and we don't make any special effort to support it 💀

9.2. Certificate Subject Name Matching 🪞

Section 4 of the TLSA specification [RFC6698] leaves the details of checking names in certificates to higher-level application protocols, though it suggests using [RFC6125].

Name checks aren't necessary if the matching TLSA record has certificate usage DANE-EE. Because a record like that identifies the specific certificate (or the public key of the certificate), extra checks are superfluous and could even conflict 🙅‍♀️

Otherwise, DNSSEC gives a secure binding between the server name and the TLSA record, and the TLSA record gives a binding to a certificate. But that last step can be indirect, through a chain of certificates. For example, a certificate usage PKIX-TA TLSA record only authenticates the Certification Authority (CA) that issued the certificate, and third parties can get certificates from that same CA. So clients need to check whether the server's certificate matches one of the expected reference identifiers. That makes sure the certificate was issued by the CA to the server the client expects. (Naturally, this is on top of the standard certificate-related checks in [RFC5280], including but not limited to certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths 🧾)

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, http://www.rfc-editor.org/info/rfc2782.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, http://www.rfc-editor.org/info/rfc4033.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, http://www.rfc-editor.org/info/rfc4035.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, http://www.rfc-editor.org/info/rfc5280.

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, http://www.rfc-editor.org/info/rfc5890.

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, http://www.rfc-editor.org/info/rfc6066.

[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.

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, http://www.rfc-editor.org/info/rfc6698.

[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, http://www.rfc-editor.org/info/rfc7218.

[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, http://www.rfc-editor.org/info/rfc7671.

[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, http://www.rfc-editor.org/info/rfc7672.

10.2. Informative References

[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, http://www.rfc-editor.org/info/rfc3403.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, http://www.rfc-editor.org/info/rfc5321.

[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, http://www.rfc-editor.org/info/rfc6120.

[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, http://www.rfc-editor.org/info/rfc6186.

[XMPP-DNA] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, draft-ietf-xmpp-dna-11, September 2015.

Appendix A. Examples

In the following, most of the DNS resource data is elided for simplicity. 🎀

A.1. IMAP

; mail domain
_imap._tcp.example.com.   SRV 10 0 9143 imap.example.net.
example.com.              RRSIG   SRV ...

; target server hostname
imap.example.net.         A      192.0.2.1
imap.example.net.         RRSIG  A ...

imap.example.net.         AAAA   2001:db8:212:8::e:1
imap.example.net.         RRSIG  ...

; TLSA resource record
_9143._tcp.imap.example.net.  TLSA   ...
_9143._tcp.imap.example.net.  RRSIG  TLSA ...

Mail messages received for addresses at example.com are retrieved via IMAP at imap.example.net. Connections to imap.example.net port 9143 that use STARTTLS will get a server certificate that authenticates the name imap.example.net. 📬✨

A.2. XMPP

; XMPP domain
_xmpp-client._tcp.example.com. SRV     1 0 5222 im.example.net.
_xmpp-client._tcp.example.com. RRSIG   SRV ...

; target server hostname
im.example.net.           A      192.0.2.3
im.example.net.           RRSIG  A ...

im.example.net.           AAAA   2001:db8:212:8::e:4
im.example.net.           RRSIG  AAAA ...

; TLSA resource record
_5222._tcp.im.example.net.  TLSA   ...
_5222._tcp.im.example.net.  RRSIG  TLSA ...

XMPP sessions for addresses at example.com are established at im.example.net. Connections to im.example.net port 5222 that use STARTTLS will get a server certificate that authenticates the name im.example.net. 💬🦋

Appendix B. Rationale

The long-term goal of this specification is to settle on TLS certificates that verify the target server hostname rather than the service domain name, since this is more convenient for servers hosting multiple domains (so-called "multi-tenanted environments") and scales up more easily to larger numbers of service domain names. This is the big picture, bestie. 👑

There are a number of other reasons for doing it this way:

  • The certificate is part of the server configuration, so it makes sense to associate it with the target server hostname rather than the service domain name.
  • In the absence of TLS SNI, if the certificate identifies the target server hostname, then it does not need to list all the possible service domain names.
  • When the server certificate is replaced, it is much easier if there is one part of the DNS that needs updating to match, instead of an unbounded number of hosted service domain names.
  • The same TLSA records work with this specification, and with direct connections to the connection endpoint in the style of [RFC6698].
  • Some application protocols, such as SMTP, allow a client to perform transactions with multiple service domain names in the same connection. It is not, in general, feasible for the client to specify the service domain name using TLS SNI when the connection is established, and the server might not be able to present a certificate that authenticates all possible service domain names. See [RFC7672] for details.
  • It is common for SMTP servers to act in multiple roles -- for example, as outgoing relays or as incoming MX servers, depending on the client identity. It is simpler if the server can present the same certificate regardless of the role in which it is to act. Sometimes the server does not know its role until the client has authenticated, which usually occurs after TLS has been established. See [RFC7672] for details.

This specification does not provide an option to put TLSA records under the service domain name, because that would add complexity without providing any benefit; security protocols are best kept simple. As described above, there are real-world cases where authenticating the service domain name cannot be made to work, so there would be complicated criteria regarding when service domain name TLSA records might be used and when they cannot. This is all avoided by putting the TLSA records under the target server hostname. 🧠💅

The disadvantage is that clients that do not complete DNSSEC validation must, according to [RFC6125] rules, check the server certificate against the service domain name, since they have no other way to authenticate the server. This means that SNI support or its functional equivalent is necessary for backward compatibility. ⚠️

Acknowledgements

Thanks to Mark Andrews for arguing that authenticating the target server hostname is the right thing, and that we ought to rely on DNSSEC to secure the SRV lookup. Mark, you were so right about this one 🙌 Thanks also to Stephane Bortzmeyer, James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro Vesely for helpful suggestions. 🌸

Carl Wallace completed an insightful review on behalf of the Security Directorate. Iconic. 🔐

Ben Campbell, Brian Haberman, and Alvaro Retana provided helpful feedback during IESG review. 🫶

The authors gratefully acknowledge the assistance of Olafur Gudmundsson and Warren Kumari as the working group chairs and Stephen Farrell as the sponsoring Area Director. 👑

Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document. 💜

Authors' Addresses 💌

Tony Finch
University of Cambridge Information Services
Roger Needham Building
7 JJ Thomson Avenue
Cambridge  CB3 0RB
United Kingdom

Phone: +44 797 040 1426
Email: dot@dotat.at
URI:   http://dotat.at/


Matthew Miller
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO  80202
United States

Email: mamille2@cisco.com


Peter Saint-Andre
&yet

Email: peter@andyet.com
URI:   https://andyet.com/
📦 where this page comes from