DNS+Direct+Project+Recommendation+Review

Direct Project DNS Recommendation For Review:
To ensure interoperability, a HISP and/or HIDP must publish Direct X.509 certificates as CERT resource records within the Domain Name System (DNS) as specified in [|section 5 of the Applicability Statement for Secure Health Transport]. DNS is a scalable, federated directory with a format standard for holding and accessing X.509 certificates. This does not preclude the formation of additional directory mechanisms in the future, but rather addresses the immediate need for certificate discovery in the context of HISP interoperability.

The initial consensus statement will be to accept the Direct Project Recommendation as a __possible__ standard for consideration and review the standard against the use case requirements defined for the Query for Digital Certificate for Direct Project Use Case. It should be noted that the assumption used for this use case is that all existing approaches including DNS are unproven in this area, as noted in the use case assumptions, and thus will require analysis.

DNS Recommendation Points to Explore:
The S&I Framework Provider Directory Initiative will look at the following questions in considering DNS and other standards as appropriate for the Query for Digital Certificate for Direct Project Use Case business and technical requirements:
 * **What scalable alternatives are there to DNS?**
 * The assumption defined in the Direct Project Rules of the Road Consensus Statement is that DNS is scalable in the context envisioned by the Direct model. Part of the standards assessment approach within the S&I Framework Provider Directory Initiative will be focused on looking at various criteria besides scalability to be considered in reviewing standards.
 * For example, Pilot Recommendations would measure how many specific DNS pilots exist that support the Query for Digital Certificate for Direct Project Use Case vs. how many pilot might exist for an LDAP, HPD, or X12 implementation strategy.
 * __**The Harmonization Support team recommends that for this use case, that analysis be focused primarily on DNS and also LDAP as a potential alternative for future Direct Project pilots. If the majority of the volunteers would not like to focus on LDAP and analysis of its applicability to the use case, then only DNS will be considered, and the Direct Project recommendations will be amended/enhanced by this group of volunteers as needed to support the use case.**__


 * **What are the weaknesses of the DNS approach?**
 * Multiple weaknesses appear in looking at the Query for Digital Certificate for Direct Project Use Case and comparing it to both future provider directory use cases and the Direct Project Rules of the Road recommendations.
 * **No advanced search functions exist in DNS -**the context of the Query for Digital Certificate for Direct Project Use Case assumes a known electronic address. However, if the address is unknown and a provider is forced to search for it using other demographic information, DNS is not an effective option for that purpose and this could become problematic. It is anticipated that future provider directory use cases will have more advanced search and query requirements
 * **Inability to provide different answers in response to different query sources -**A larger problem with DNS is that it is not designed to provide different answers to different query sources. This could become a problem in future provider directory use cases where different query responses may be needed depending on the source of the query.
 * **Allow public access for information contained within a certificate,despite not having knowledge on what it is yet**.
 * **The social risk of sharing information with those who may not want to have seen.**
 * **[|Encryption]is not yet widely adopted**
 * DNSSEC is highly recommended for prevention of spoofing (false replies or MITM) of DNS CERT client or Certificate Authority (CA) holding zones but is not widely implemented. (In the last 10 years approx 1% of top domains).
 * DNSSEC is not highly adopted because it has an amplifying effect on distributed denial of service ( DDOS) which would prevent exchange of medical records, which will require commercial grade DDOS mitigtion of systems are actually exposed to Internet. Phishing ([|homographic or like sounding or looking)] domain names are a common vector of Identity theft.
 * Ease of use of domain registration promotes "fast flux" of zombie bot nets used for DNS DDOS attacks, where attacking hosts cycle between multiple International locations making IP geo location of attacks difficult to ascertain due to multiple layers of proxies in command and control. U.S. Cyber-command reserves the right to retaliate as necessary during any cyberspace attack on CONUS, (including kinetic responses)., but[| the difficulty of locating attack vectors of cybercriminals], and nation state actors in the global DNS, creates problems in determining proper response in a global system.
 * Widening the scope to more DNS systems in which important key signing operations such as NSEC3 (which prevents trivial enumeration of names by querying for a non-existent names, i.e. a non existent babycatcher@direct.sunnysidefamilypractice.com returns all direct addresses) requires DNS expertise which is lacking in the community, and only recently supported by commercial providers.
 * DNS is a widely distributed, yet not well understood (except for some experts) system lacking a coordinated security response (CERT) and in which the majority of technical participants do not grasp critical configuration parameters, creating a great deal of "leakage" of local data held in name-servers out to the Internet. The root servers have an excellent, and resilient design, in which major DDOS attacks in 2007, and 2002, against root servers were ineffective due to Anycast. Significant weaknesses in the past have been hidden ([|Bellovin]) for many years, due to security concerns. Recursion has been a problem, and solutions in shortening dependencies on intervening name-servers (how many name-servers need to work properly to give a correct answer) were noted in Cornell research on trusted systems which indicated the exposed depth of dependencies between servers, which hastened adoption of DNSSEC on TLD.
 * Exploits for Certificates exist. Failure to enforce certificate constraints allowed for attacks via DNS and substitution of valid certificates in conjunction with layer 2 spoofing.
 * DNS is primarily mass consumer grade (designed for rapid mass market acceptance and ease of use versus security) rather than military/avionics grade approach (geared for security against known attack vectors). Given the inconvenient length and multiple parts of distinguished names, versus domain names, there is a trade off between convenience, semantic value and specificity and security creating risks between a two tiered system. [|Government can encourage better DNS security].
 * DNS is clearly suitable for consumer PHR and device interactions (such as where bathroom scales, glucose meters, health data devices communicate back to a health tracking application or where cardio devices are already programmed to interact with a practice's collection system for better range and flexibility.
 * __**The Harmonization Support team recommends that the harmonization approach for this specific use case focus on any additional implementation guidance or recommendations related to these documented weaknesses.**__


 * **Will the DNS solution be applicable as we move to other, more specific provider directory use cases?**
 * The Query for Digital Certificate for Direct Project Use Case covers a very narrow spectrum of the overall Provider Directory landscape. It is designed to only cover a narrow niche of possible provider directory data query requirements. It will be important to focus on the concern that a choice of DNS within this use case will lead to the deployment of something that will ultimately need to be torn down and replaced with something else should future provider directory use case requirements make demands of DNS that cannot be met.
 * How much of an effect can the Direct Project Use Case have on the realities of Global DNS which represent a complex system of actors, both good and bad? Will authority and accountability have to negotiated on a case to case basis, or can a global solution be achieved with by use global namespace versus a national namespace based on FIPS that mirrors current geopolitical organization, such as the .US DNS namespace? How would the DNS approach deal TLD fragmentation, (multiple TLD), would provider registration occur as it does now in multiple TLD to prevent Phishing?
 * One possible long-term caveat to this is that discussion continues on the creation of a top-level domain (TLD) for entities exchanging health information (e.g., .HEALTH) that would allow for the using of DNS to discover entities and their security credentials (in support of the current Direct model and other health information exchange models). The assumption of the S&I Framework Provider Directory Initiative is that while that TLD option would make usage of DNS much easier to implement, it is not foreseen as something that will be completed in the immediate future.
 * __**The Harmonization Support team recommends that the harmonization approach for this specific use case focus on writing specific language surrounding the applicability of DNS to a broader set of Provider Directory use cases that may potentially be applicable in the future.**__

**DNS Issues to Review:** Additional DNS issues to be considered as part of developing S&I Framework consensus around the Query for Digital Certificate for Direct Project Use Case:
 * To associate DNS CERT records with e-mail addresses, the Direct Address MUST be formatted as a domain name. This statement would imply that a Direct participant would only query for a certificate using a domain name, such as erpupo@siframework.org.
 * In the Query for Digital Certificate for Direct Project Use Case, the following is defined for an electronic endpoint address:
 * **Electronic Address:** A string which identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). or an X.500/LDAP certificate subject distinguished name via LDAP URL. Communication with an electronic address may require a digital certificate.


 * Is there any additional implementation guidance needed as part of this Direct Rules of the Road recommendation?**

Security considerations are in scope for Harmonization. Direct Project Communities are currently resolving issues according to defined uses. Using current draft language of Federal, Ecosystem and Citizen may help clarify different distribution and trust relationships in regards to security considerations. Roles of HISP/HIDP economic models should be clarified as "views" in the RM-ODP and balanced against other views.

__**The main focus of analysis of the Direct Project recommendation is to see if any additional guidance can be provided to the Direct Project surrounding existing recommendations. The Harmonization Support team recommends that we capture that guidance and feedback here and that it be part of the consensus statement the group agrees to in harmonization.**__