draft-dlr-doh-deploy-00.txt

TBD                                                         J. Dickinson
Internet-Draft                         Sinodun Internet Technologies Ltd
Intended status: Informational                              J. Livingood
Expires: May 4, 2021                                             Comcast
                                                                 J. Reid
                                                                RTFM llp
                                                        October 31, 2020


             DNS over HTTPS (DoH) Deployment Considerations
                        draft-dlr-doh-deploy-00

Abstract

   Deployment of DNS over HTTPS (DoH) [RFC8484] introduces a major
   change to the way in which devices and applications are able to use
   the Domain Name System.  DoH traffic uses HTTP over a TLS session.
   DoH clients and servers can use HTTP primitives to request and supply
   DNS data instead of conventional DNS queries and responses using port
   53.  This presents a number of challenges, including new risks and
   security concerns.

   The objective of this document is to describe these challenges and
   provide advice on how to minimise their impact.

   It is also likely that DoH servers could be operated and controlled
   by website administrators and developers who are not familiar with
   the DNS.  They may need guidance on how to provide DoH services that
   are aligned with best DNS practices.  This document is intended to
   bridge the gap between the HTTP and DNS communities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 4, 2021.




Dickinson, et al.          Expires May 4, 2021                  [Page 1]

Internet-Draft            draft-dlr-doh-deploy              October 2020


Copyright Notice

   Copyright (c) 2020 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Contrasting DoH and Conventional DNS  . . . . . . . . . . . .   4
   4.  DoH Impact on Existing DNS Behaviour  . . . . . . . . . . . .   5
     4.1.  DNS servers using Access Control Lists  . . . . . . . . .   5
     4.2.  Split DNS . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Secure DNS (DNSSEC) . . . . . . . . . . . . . . . . . . .   6
     4.4.  DNS Headers, OP Codes and EDNS Options  . . . . . . . . .   6
     4.5.  Multicast DNS . . . . . . . . . . . . . . . . . . . . . .   6
   5.  DoH Impact on Browser Behaviour . . . . . . . . . . . . . . .   7
     5.1.  Browser Caches  . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  What else?  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  DoH server resolving incoming queries . . . . . . . . . .   7
     6.2.  DoH server forwarding to a traditional validating
           resolver: . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.3.  Combined DoH server and DNS resolver: . . . . . . . . . .   8
     6.4.  DoH server using private DNS RRs  . . . . . . . . . . . .   8
     6.5.  DoH server to HTTP server forwarding to a traditional
           validating resolver:  . . . . . . . . . . . . . . . . . .   9
     6.6.  DoH server to HTTP server using private dns RRs known
           only to the DoH server  . . . . . . . . . . . . . . . . .   9
   7.  Privacy Concerns  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .  12



Dickinson, et al.          Expires May 4, 2021                  [Page 2]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Traditional DNS traffic is not encrypted.  This poses an obvious
   privacy challenge for Internet users, because their access to named
   network resources could potentially be tracked through their DNS
   queries.  Measures like Query Minimisation [RFC7816] can reduce but
   not eliminate this exposure.  In principle, any network element in
   the path between the user and resolver could observe this unencrypted
   traffic.

   DoH partially eliminates this problem by using TLS to encrypt the
   queries and responses that are made.  These use HTTPS rather than the
   conventional DNS protocol.  Furthermore DoH traffic is intermingled
   with other HTTPS traffic, making it difficult for an eavesdropper to
   monitor DNS traffic or even be aware that it is taking place.  It
   should be noted however that a user's DNS queries could still be
   observed by the DoH server(s) which receive them.

   The conventional model for DNS transactions involves a stub resolver,
   recursive servers and authoritative DNS servers.  The stub resolver
   is usually part of the operating system software and is used by
   applications to make DNS queries and receive responses from recursive
   servers which are typically provided by an ISP or the local network
   administrator.  Recursive servers answer queries from stub resolvers
   by traversing a hierarchy of authoritative DNS servers, querying them
   for data about some domain name and ultimately returning that
   response to the stub resolver that initiated the orginal query.

   New models of DNS usage are created with DoH.  A DoH server typically
   occupies the role of the recursive resolving server in conventional
   DNS.  DoH clients send DNS queries to DoH servers over DoH instead of
   using a stub resolver to send plaintext DNS queries to a conventional
   recursive resolving server.  This DoH server will sometimes be
   operated and controlled by a third party - i.e. not whoever operates
   and controls the existing recursive resolver DNS servers in some
   network.  That in turn disrupts the long standing and well understood
   (if sometimes poorly documented) trust relationships in traditional
   DNS.

   HTTP servers would be able to offer DoH resolution service without
   the need for conventional DNS query-response transactions (e.g.
   Do53).  For instance, HTTP servers could just return application/dns-
   message elements for the URIs in some web page, saving the web client
   from issuing DoH (or plaintext DNS) queries to lookup the hostnames
   in those URIs.  On one hand there may be performance benefits to




Dickinson, et al.          Expires May 4, 2021                  [Page 3]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   doing so in some cases, balanced against some risk arising from
   tighter coupling between layers and applications.

2.  Terminology

   DoH Server: A server supporting the DNS over HTTPS is called a "DoH
   server" to differentiate it from a "DNS server" (one that only
   provides DNS service over one or more of the other transport
   protocols standardised for DNS).  Similarly, a client that supports
   the DNS over HTTPS is called a "DoH client".

   A detailed glossary of DNS terms can be found in RFC 8499 [RFC8499].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Contrasting DoH and Conventional DNS

   With conventional DNS today, using UDP or TCP port 53 (DNS over port
   53 - Do53), most users are assigned the IP addresses of several
   recursive resolvers via Dynamic Host Configuration Protocol (DHCP) or
   similar network bootstrapping mechanism.  These are usually the IP
   addresses of recursive resolvers that are administered by the network
   operator.

   When DoH is used, client and server DNS traffic is encrypted using a
   TLS channel, typically via port 443.  DoH clients may have little
   need for conventional DNS apart from an initial bootstrap query to
   find the IP addresses of a suitable DoH server.  The bulk of their
   DNS resolver traffic could bypass the current network's DNS resolver
   infrastructure because that traffic will make use of the resolver
   service provided by the DoH server.

   At present there is no standard for DoH server discovery, which is
   being worked on in the Adaptive DNS Discovery (ADD) working group.
   Browser vendors, who have been first to use DoH, have so far adopted
   ad-hoc solutions until suitable standard(s) are available.  One
   potential approach is to embed the names or URIs for public DoH
   resolvers in the browser's configuration.  Another is to try DoH
   opportunistically: if there is a DoH service at the IP address(es)
   found in the device's stub resolver configuration, the browser uses
   that.








Dickinson, et al.          Expires May 4, 2021                  [Page 4]

Internet-Draft            draft-dlr-doh-deploy              October 2020


4.  DoH Impact on Existing DNS Behaviour

4.1.  DNS servers using Access Control Lists

   When a DoH server performs the role of a recursive resolving DNS
   server, it queries other DNS or DoH servers to resolve the queries
   received from DoH clients.  In some settings, a DOH server will
   forward these queries to a recursive resolver or some proxy.  In
   either scenario, these outbound queries will use a source IP address
   of the DoH server, not that of the originating DoH client.  This may
   sometimes cause operational or security problems, for instance when
   the DoH server queries another DoH or DNS server that uses access
   control lists based on source IP address.  In this case, the ACL
   applies to the source address of the DoH server (or an intermediary)
   and not the original DoH client.  That can mean the DoH client
   eventually gets a different response than if it had made the query
   itself.  In particular, this may be a problem for IXFR or AXFR
   queries because authoritative DNS servers commonly use ACLs to
   restrict these queries.

   This problem becomes more acute for dynamic updates [RFC2137].  If an
   ACL based on source IP address is used to accept or reject these
   requests, it will be the address of the DoH server rather than the
   DoH client which determines the outcome.  However Transaction
   Signatures (TSIG) [RFC2845] and GSS-TSIG [RFC3645] are commonly used
   for authenticating dynamic update requests.  It is therefore
   essential that DoH servers do not interfere with any TSIG resource
   records in queries or responses.  DoH servers MUST ensure TSIG
   resource records included in any requests received from DoH clients
   are included whenever the DoH server has to contact another DoH or
   DNS server to satisfy that request.  Similarly, DoH servers MUST
   return to DoH clients any TSIG resource records that are received
   from DNS or DoH servers.

4.2.  Split DNS

   Split DNS configurations [RFC8499] are widely used, particularly in
   enterprise networks.  These have an internal name space which is not
   visible to the public Internet.  Resolving DNS servers in such
   networks are usually configured to only provide answers for this name
   internal space to requests from clients on the enterprise network.

   Applications and devices making DoH requests on networks which use
   split DNS will not be able to access these internal names unless
   their requests are sent to a suitably configured DoH server.  This
   probably means that networks using split DNS SHOULD provide DoH
   servers which are able to provide answers for their internal name
   space.  It therefore follows that networks using split DNS SHOULD



Dickinson, et al.          Expires May 4, 2021                  [Page 5]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   ensure that DoH clients query local DoH servers which have been
   configured for that network's internal name space.

   Use of third-party DoH servers is not recommended in networks which
   have split DNS.  These servers are unlikely to know about the
   configuration of the local network and will therefore be unable to
   resolve or otherwise properly handle requests for the internal name
   space.  When third-party DoH servers are used in these networks, it
   also presents security and privacy risks.  Requests from DoH clients
   for internal names will leak, disclosing this potentially sensitive
   information to an external DNS server or proxy which is operated and
   controlled by a third party.

4.3.  Secure DNS (DNSSEC)

   RFC 8484 explains that interactions between a DoH server and client
   benefit from the transport security provided by HTTPS and that DoH
   does not provide message integrity.  Although a DoH client can be
   sure it received exactly the data sent by a DoH server, it does not
   know if that server is telling the truth.  That can only be
   determined by DNSSEC validation, assuming that the DNS data are
   properly signed.  Therefore a security-conscious DoH client SHOULD
   support DNSSEC and perform DNSSEC validation by itself.  DoH clients
   MAY trust a DoH server to validate signed responses on their behalf
   but MUST take full account of the consequences of doing so.

4.4.  DNS Headers, OP Codes and EDNS Options

   DoH servers MUST check the headers and opcodes on inbound DoH
   requests and act accordingly.  In particular, DoH servers MUST NOT
   assume that those requests are queries unless both the QR bit and
   Opcode header are set to zero.  Relevant header and EDNS bits (DO,
   CD, etc) on incoming queries MUST be reflected in the outgoing DNS or
   DoH queries needed to resolve the original request.  Similarly, the
   header and EDNS bits returned in responses MUST be reflected in the
   responses transmitted to a DoH client by the DoH server.

   To do: add clarifications on behaviour around EDNS goop - buffer
   sizes, padding, ECN, keepalive, extended error code, DNS cookies, etc

4.5.  Multicast DNS

   Need to say something about this and .local?  Should DoH services
   need to know or care about it?







Dickinson, et al.          Expires May 4, 2021                  [Page 6]

Internet-Draft            draft-dlr-doh-deploy              October 2020


5.  DoH Impact on Browser Behaviour

5.1.  Browser Caches

   A web browser maintains a cache of recent DNS data.  Responses from
   DoH servers will affect the contents of that cache.  This presents a
   security risk because DoH servers could arbitrarily manipulate the
   content of a browser's cache in a way that would not be possible with
   conventional DNS.  DoH servers may be able to populate a browser's
   cache without the browser making DNS (or DoH) queries by sending
   arbitrary application/dns-message elements in the HTML needed to
   render a web page.

   DoH servers SHOULD NOT send DoH data (i.e. application/dns-message
   elements) unrelated to the request made by a DoH Client.  Similarly,
   a web server SHOULD NOT send DoH data that does not correspond to any
   of the URIs in the HTML which is returned. i.e. If all the URIs on
   some web page are for foo.example.com, the web server SHOULD NOT send
   application/dns-message elements for bar.example.com or example.net.
   DoH clients SHOULD ignore such unrelated DoH data sent by a DoH or
   web server.  DoH clients MUST NOT cache such data.

5.2.  What else?

   There have to be some server PUSH horrors here

   Say something about the evils of web cookies and related spyware
   (trackers, beacons, etc)?

6.  Use Cases

6.1.  DoH server resolving incoming queries

   A DoH server is unlikely to be able to answer all the incoming
   queries it receives.  This means it will need to interact with other
   DNS servers in order to resolve those queries.  There are two
   scenarios.  The DoH server could send these queries to a suitable
   proxy or forwarding server for resolution.  It could function as a
   validating recursive DNS server and resolve the queries for itself.

   There are potential privacy and security implications for both
   scenarios.  If the DoH server's outbound queries use Do53, the query
   name (or parts of the query name) will be transmitted in plaintext -
   possibly disclosing sensitive information.  The corresponding
   plaintext responses to those queries could also include sensitive
   information.  Operators of DoH will need to decide what transport(s)
   are used for outgoing queries and what policy applies and consider
   the technical and privacy trade-offs of those choices . This would



Dickinson, et al.          Expires May 4, 2021                  [Page 7]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   presumably be some combination of DoH, DoT and Do53.  A DoH server
   will probably need to have configuration controls to apply local
   policy for those outgoing queries: for instance, try DoH first then
   fall back to Do53 if DoH is not available.

   A DoH server cannot assume in the general case that it can use DoH
   (or DoT) to resolve queries.  Though this may be possible when the
   server sends its queries to a proxy or resolving DNS server that's
   under the same administrative control.  It therefore follows that a
   DoH server SHOULD support Do53 unless it is operating in an
   environment where the DoH server is configured with the answers for
   all possible queries that the local DoH clients will generate.

6.2.  DoH server forwarding to a traditional validating resolver:

   Recursive DNS operators will likely choose to deploy DoH support in a
   variety of ways, depending upon their internal technical requirements
   and platform capabilities.  One mode of deployment is to support DoH
   via a special HTTPS server (or network element such as a load
   balancer) that then forwards (proxies) the DNS query to a Do53
   resolver on the backend.  This would typically occur within a
   datacenter or trusted private network and represents a simple
   internal function separation between two different protocols.  It may
   also have the advantage of off-loading TLS-session management and
   encryption onto hardware and/or software optimized to performing
   those tasks.

6.3.  Combined DoH server and DNS resolver:

   In contrast to the deployment design above, an alternative is to run
   the DoH resolver on a server that is also running a recursive DNS
   resolver.  This combines the protocols offered for DNS resolution
   into a unified service - potentially also supporting other protocols
   such as DoT.  However, at least based on current CPU capabilities,
   the result seems likely to be that each server can handle fewer
   queries per second than a Do53 server, necessitating a greater number
   of servers to be deployed for a given peak query load.  On the other
   hand, server costs continue to decline and virtualization can in some
   cases mitigate those concerns.

6.4.  DoH server using private DNS RRs

   Some DoH environments could use "private" DNS Resource Records for
   internal purposes.  These private use resource records SHOULD NOT
   leak to the public Internet.

   Care is needed when choosing the type codes for these sorts of
   resource records.  The guidance in [RFC6895] RFC 6895 should be



Dickinson, et al.          Expires May 4, 2021                  [Page 8]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   followed.  If these private-use Resource Records are used in a closed
   setting that is isolated from the public Internet, type codes SHOULD
   be assigned from the Reserved from Private Use Range, ie 0xF00-0xFFFE
   (65280-65535).  However care should be taken when two or more of
   these private networks are connected to ensure there are no type code
   collisions: ie situations where network A and network B have both
   used type code 65000 (say) for discrete internal purposes.

   For DoH settings on the Internet, type codes for new resource record
   types MUST be registered with IANA.  This will ensure the type code
   assignment is unique and reduce the potential for type code
   collisions.  The Expert Review process described in Section 3.1.1 of
   RFC 6895 MUST be used for these assignments.

   Both these forms of type code assignment imply that DoH clients and
   servers support RFC 3597.

6.5.  DoH server to HTTP server forwarding to a traditional validating
      resolver:

   Covered by "DoH server resolving incoming queries" above?

6.6.  DoH server to HTTP server using private dns RRs known only to the
      DoH server

   Covered by "DoH server using private DNS RRs" above?

7.  Privacy Concerns

   If a resolver operator has functionally separated the DoH service and
   Do53 service and is using a logically separate DoH service to proxy
   DNS queries, then the network connection between the DoH service and
   Do53 server should be trusted.  If this is not the case, then it
   defeats the privacy objectives inherent in the rationale for DoH.
   [JL: this is also in requirements below - and maybe it belongs in one
   or the other and not both]

8.  Security Considerations

   This document contains no security concerns that have not already
   been addressed by RFC 8484.

9.  Recommendations

   If a resolver operator has functionally separated the DoH service and
   Do53 service and is using a logically separate DoH service to proxy
   DNS queries, then the network connection between the DoH service and




Dickinson, et al.          Expires May 4, 2021                  [Page 9]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   Do53 server should be trusted.  If this is not the case, then it
   defeats the privacy objectives inherent in the rationale for DoH.

   DoH servers on the public Internet MUST NOT create an alternate root
   or publish data for TLDs that have not been created through ICANN or
   IETF processes.  DoH servers on private networks MAY use alternate
   roots and/or ad-hoc TLDs provided these name spaces do not leak to
   the public Internet.

   The responses received over DoH MUST be available in the traditional
   DNS.

   A DoH server MAY make choices about which RRs to return if it knows
   more about the network or client locality, provided that does not
   compromise DNSSEC validation.

   The DoH server MAY push useful additional RRs to DoH Client if the
   server knows the client is likely to need those RRs soon.  Again,
   these RRs MUST be available in the traditional DNS.

   DoH servers and clients MUST handle unknown RRtypes correctly: ie
   support RFC 3597 [RFC3597].

   DoH servers MUST support DNSSEC validation.

   DoH clients SHOULD support DNSSEC validation.

   DoH servers and clients SHOULD support Transaction Signatures (TSIG).
   Although the message integrity checking offered by TSIG is redundant
   when DNS transactions are carried over a TLS channel, TSIG offers
   protection against replay attacks.  This may be useful for some types
   of DNS transactions.

   DoH servers MUST honour DNS error codes and extended error codes
   [draft-ietf-dnsop-extended-error-16].  These MUST be returned to DoH
   clients.  Use of HTTP error codes SHOULD complement these DNS error
   codes and MUST NOT replace them.  DNS error codes have specific
   meaning and these semantics may not always be readily conveyed in an
   HTTP error code.  It is also possible that DoH clients could strip
   any HTTP information before returning the DNS response to the
   application that had initiated the DoH query.

10.  IANA Considerations

   This memo includes no request to IANA.






Dickinson, et al.          Expires May 4, 2021                 [Page 10]

Internet-Draft            draft-dlr-doh-deploy              October 2020


11.  Acknowledgements

   Fill this in later

12.  References

12.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,
              <https://www.rfc-editor.org/info/rfc2119>.

12.2.  Informative References

   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
              Update", RFC 2137, DOI 10.17487/RFC2137, April 1997,
              <https://www.rfc-editor.org/info/rfc2137>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <https://www.rfc-editor.org/info/rfc2845>.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
              2003, <https://www.rfc-editor.org/info/rfc3597>.

   [RFC3645]  Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
              and R. Hall, "Generic Security Service Algorithm for
              Secret Key Transaction Authentication for DNS (GSS-TSIG)",
              RFC 3645, DOI 10.17487/RFC3645, October 2003,
              <https://www.rfc-editor.org/info/rfc3645>.

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <https://www.rfc-editor.org/info/rfc6895>.

   [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve
              Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
              <https://www.rfc-editor.org/info/rfc7816>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.






Dickinson, et al.          Expires May 4, 2021                 [Page 11]

Internet-Draft            draft-dlr-doh-deploy              October 2020


   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   John Dickinson
   Sinodun Internet Technologies Ltd
   Oxford Science Park
   Oxford  OX4 4GA
   UK

   Email: jad@sinodun.com


   Jason Livingood
   Comcast
   1800 Arch Street
   Philadelphia  PA 19118
   USA

   Email: jason_livingood@comcast.com


   Jim Reid
   RTFM llp
   St Andrews House
   382 Hillington Road, Glasgow  G51 4BL
   Scotland

   Email: jim@rfc1035.com
















Dickinson, et al.          Expires May 4, 2021                 [Page 12]