One of the biggest controversies surrounding the IANA stewardship transition revolves around the fate of the IANA trademark and domain name (IANA.ORG). Both of these assets are currently owned by ICANN. But the IANA stewardship transition has raised questions about who or what should be their proper home.
In each operational community developing a transition proposal, the IANA trademark and domain were either major sources of controversy (protocols and names) or centerpieces of the actual proposal (numbers). The task of coordinating the different approaches to those assets has been the most significant compatibility problem – perhaps the only real compatibility problem – faced by the IANA Stewardship Coordination Group so far.
Why does this matter? There are people who say it doesn’t, but they are wrong. As we will explain, the fate of those assets is fundamental to the proper execution of the transition, and if it is not handled right, the whole transition could founder.
ICANN was given the trademark and domain by the University of Southern California’s Information Sciences Institute when it was first created. According to ICANN’s first proposal to the Commerce Department, in negotiating the transfer of the trademark for IANA from USC to ICANN:
ICANN and USC-ISI concluded that this optional acquisition was appropriate because, although transfer of title to the intellectual property is not necessary to secure ICANN’s right to use the intellectual property to perform the IANA function, it is more appropriate that ICANN, as the new contractor, take responsibility for any effort or costs associated with maintenance or enforcement of the intellectual property.
At the time, ICANN was perceived as the home for the IANA and the direct successor of Jon Postel’s ISI. Postel himself was slated to be the CTO of ICANN before he died, and he conceived of ICANN as an umbrella organization that would be the institutional meeting point of the names, numbers and protocol communities.
ICANN has changed, and so has the whole environment around IANA since then. By internalizing the domain name policy making function, ICANN has become dominated by domain name policy and money. The concept of IANA as a severable, contractual relationship, first introduced by a suspicious IETF in 2000, did not exist in 1998 – or insofar as it did, the principal in the contract was the US government, not three operational communities.
The contracted model
Today, the IETF views the IANA functions as a vital but essentially clerical task that they outsource to ICANN. Although the choice as to who is the IANA functions provider was pretty much made for them by the US Government, the regional numbers registries also aspire to have, like the IETF, a severable contractual relationship with ICANN to provide IANA functions. Both communities insist on the right to change their IANA functions provider if it doesn’t perform to their specifications.
Thus for the numbers and protocol communities, it’s clear that the IANA functions provider (which happens to be ICANN now and is likely to be PTI in the future) should not own the trademark or the IANA.ORG domain name. Ownership of these assets by a specific contractor erects a major barrier to their ability to change providers at will. Aside from the higher switching costs, it is simply bad business practice to let IPR that is core to any entity’s mission reside in the hands of a mere contractor. For example, if Citibank chooses to outsource some of its banking functions to a third party, its managers would not dream of giving the contractor ownership of the Citibank trademark or the citi.com domain name.
That is why the numbers community proposed, as part of its transition plan, to divest ICANN of the IANA trademark and domain name.
With regards to the IANA trademark and the IANA.ORG domain, it is the expectation of the Internet Number Community that both are associated with the IANA Numbering Services and not with a particular IANA Numbering Services Operator. … It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non-discriminatory manner for the benefit of the entire community. From the Internet Number Community’s perspective, the IETF Trust would be an acceptable candidate for this role.”
For a variety of reasons, none of which were very intelligent, the IETF’s IANAPLAN Working Group stopped short of asking for the transfer of the assets away from ICANN. Instead, it merely called upon ICANN to acknowledge that the protocol parameter registries are in the public domain and to acknowledge that, if IETF chooses to change IANA functions provider, it will work with the new provider to minimize any disruption caused by its ownership of the domain or trademark. In fact, the status of the IANA-related intellectual property was a divisive and controversial issue during the IANAPLAN deliberations, as many participants pushed for divestiture. But the division was healed retroactively when the numbers community released its plan. Asked by the ICG to clarify whether its proposal was consistent with that of the numbers community, the IANAPLAN WG indicated that it had no objection to such a divestiture, nor to the IETF Trust serving as the repository for the assets. In effect, the proposal of the numbers community had validated the views of the dissenters in the IANAPLAN WG, and everyone was more or less on the same page.
Names and the IANA-centric model
What about names, then? With its recently-approved CWG proposal, the domain name community is also striving towards a more arms-length, contractual relationship between ICANN and its IANA department. They have chosen to make the provider of the names-related IANA functions into a separate legal entity that has a contract with ICANN, even though this entity, the Post-Transition IANA (PTI), is a controlled affiliate of ICANN. Severability of this contract is possible here too, at least in theory, because the CWG proposed to institute a periodic review of the IANA functions. One possible outcome of the reviews is a decision to change the IANA functions provider for names.
But the CWG proposal has an odd wrinkle in it. It contains a very drafty term sheet that could be the precursor to the ICANN-PTI Contract. That term sheet contains the following language:
ICANN will grant PTI an exclusive, royalty-free, fully-paid, worldwide license to use the IANA trademark and all related trademarks in connection with PTI’s activities under the ICANN-PTI Contract.
So in effect the proposed term sheet not only assumes that ownership of the IANA trademark remains with ICANN, it also proposes to grant to PTI an exclusive license to use it. That suggestion is totally incompatible with the proposal of the numbers community. Moreover, it was never discussed or approved by the CWG-names as a whole. Faced with protests from the numbers community, indications of discomfort from the protocols community and opposition within the names CWG, the chairs of the CWG-names have distanced themselves from the trademark language, stating:
…the TM related language in the Final Proposal is preceded by other text and contained in square brackets such that the Final Proposal effectively does not make a specific proposal with regard to the trademark.
But the author of the disputed term sheet – Greg Shatan, a trademark attorney and chair of the Intellectual Property Constituency in the GNSO – continued to argue for his position. He also targeted for criticism the idea that the IETF Trust would be an appropriate home for the trademarks and domain. The next section outlines the arguments for and against ICANN controlling the trademarks.
The Case for PTI or ICANN controlling the Trademarks
In a message sent to the CWG list, Shatan laid out his argument for why he wants ICANN or PTI to hold the trademark. “The owner of a trademark should be the ultimate source of the goods and services offered under that trademark. In the most straightforward case, the trademark owner offers those goods and services themselves or through a subsidiary. The trademark owner can license the mark to third parties to offer goods and services under the mark; but, consistent with their status as the ultimate source, the trademark owner is required by law to exercise continuing quality controls over the goods and services offered by the licensee and the use of the trademark by the licensee. A trademark owner cannot merely “hold the asset” as the numbers team proposed. Ownership of a trademark fundamentally involves being the “source or origin” of the goods and services and fulfilling the “quality control” oversight role, among other things.” Shatan goes on to say
I don’t see how the IETF Trust makes legal sense as the owner of the IANA Trademarks. The IETF Trust is not and does not intend to be the ultimate source and origin of IANA services. Unlike copyrights and patents, trademarks can’t be owned by administrators; they need to be owned by the source of the services. Further, the IETF Trust is clearly not granting ICANN the right to provide the IANA Services, so it is even more inappropriate for the IETF Trust to be the owner of the mark associated with those services.
Shatan’s view is thus based on a straightforward application of basic concepts in trademark law. (The problem is that he doesn’t quite understand what IANA actually is, confusing the IANA functions operator with the IANA itself; more about that below). Shatan also issued some rather interesting critiques of the IETF Trust as the proper home for the trademarks.
In a trademark license, the IETF Trust, as licensor, would have the power to terminate the license according to its terms (e.g., for material breach of the agreement, misuse of the trademark, etc.) or to decide not to renew the license, in which case ICANN would no longer have the right to use the IANA trademark in the provision of services. It would be inappropriate for the IETF Trust to have this power, without accountability to and oversight by the names and numbers communities. A mechanism would need to [be] built for that.
So he is not only suggesting that IETF should not hold the assets; he is suggesting that if they did, the IETF Trust would need to be subject to “accountability and oversight” from the names and numbers communities.
The case against ICANN or PTI holding the trademarks
The fundamental flaw in Shatan’s argument is that he is confusing the entity that is contracted to maintain the IANA registries with the “source and origin” of the IANA function. This is an easy mistake for a trademark lawyer not familiar with the internet standards environment to make, but it is still a mistake. The debate over the IANA trademarks must be grounded in an understanding of what the IANA functions are and where they come from. The acronym IANA has been referenced in IETF standards documents thousands of times, including this 1994 RFC describing the IANA. The references begin many years before ICANN existed. The best formal definition of the IANA functions comes from a 1998 RFC (2434):
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned … To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
In other words, the role of the IANA is to coordinate assignments within names spaces defined by the IETF standards. Thus the ‘source and origin’ of the IANA functions is the IETF standards.
As noted above, to the numbers and protocols communities, the IANA Functions operator (IFO) is merely a contractor, someone to do the clerical and administrative work of coordinating registry values based on the decisions made by independent policy making bodies (the IETF, ICANN, and the five RIRs). The contractor should not be the owner of the mark, because the contractor is not the real source or origin of IANA functions. It is the agent, not the principal. Put differently, ICANN is not “the IANA,” it just happens to be the IANA functions provider for all three communities at the moment.
Tying the trademark to one IANA functions operator – and one that is located in only one of the three operational communities – would create all kinds of coordination problems. Consider the scenario in which one of the three operational communities (let’s say, the IETF) decides to stop using ICANN or PTI for the IANA functions and chooses some other provider. Under Shatan’s scenario, the IETF would have to find another domain for its protocol registries (which could have bad operational consequences) and would also have to stop calling its new provider “the IANA” or even an “IANA functions provider” unless it got permission to use the term and domain from ICANN. But it would seem odd to need the permission of a service provider one just abandoned for bad performance or some other reason. Suppose two of the three operational communities abandon ICANN’s PTI. Then two of the three communities would not be able to use the IANA domain and trademark. This could threaten the coordination of the central registries that keep the Internet globally compatible.
Clearly, this scenario makes no sense. Any new IANA functions operator selected by the names, numbers or protocols communities are still providing IANA functions; the source and origin of the registries has not changed; the source or origin of the policy decisions about what values go into the registry has not changed. The affected community should not have to rebrand its entire system and move it to a new domain simply because they switched IFOs. The simple fact is that all three operational communities have built into their proposals the principle of separability. If we want the IANA functions provider to be subject to the discipline of potential competition – which is the most effective form of accountability – we cannot give a single IFO control of the IANA trademarks.
Where to go now
Clearly, we need to find a “home” for the IANA trademarks and domains that allows the term to continue to be used by the IETF itself (which invented the term and has it deeply embedded in its standards documents and processes), and by any or all IANA functions operator(s) that have been legitimately designated by the relevant operational communities.
Is the IETF Trust the right home? It is certainly a more appropriate one than ICANN. The IETF, not the names-centric ICANN, is the true source and origin of all IANA functions, and it would be truly odd for the IETF to have to obtain permission from anyone else to use the mark or the domain. If people are really concerned that the IETF Trust could arbitrarily terminate licenses to use the trademark or domain, it doesn’t seem that difficult to write into the terms and conditions governing the transfer of the trademark some commitments that the IETF Trust will license the mark to whoever a community deems to be their preferred IFO.
 RFC 2434 has been superseded by RFC 5226, but the definition remains the same.
 RFC 5226 uses the following definitions: “In this document, we call the set of possible values for such a field a “namespace”; its actual value may be a text string, a number, or another kind of value. The binding or association of a specific value with a particular purpose within a namespace is called an assigned number (or assigned value, or sometimes a “code point”, “protocol constant”, or “protocol parameter”). Each assignment of a value in a namespace is called a registration.”
The TLD Operator Webinar today announced that Ingrid Baele (Head of Operations, Philips) and Ken Nishida (Manager, Internet & Domain Strategies, Hitachi) are the latest speakers to be confirmed for next week's Webinar.
The addition of presenters from .hitachi and .philips bolsters the impressive lineup of speakers that already includes industry leaders such as Donuts, .berlin, .sucks, .sydney, .club and .monash.
Over 250 individuals have already registered for the webinar, representing 40 percent of the new TLD market.
Two webinars have been scheduled within 10 hours of each other to accommodate the global community, with appeal being generated around the ability to ask questions and learn from peers within the TLD community.
"This is a crucial time in the Internet's history and as new TLD applicants, we all have a responsibility to work together to get this program into mainstream culture," says Moderator and ARI Registry Services' Head of Global Consulting, Tony Kirsch.
Registrations for the 30 June webinar close soon.
Tuesday June 30 | 7am Los Angeles | 10am New York | 3pm London | 4pm CET | 6pm Dubai
Tuesday June 30 | 5pm Los Angeles | 8pm New York
Wednesday July 1 | 8am Singapore | 9am Tokyo | 10
Visit www.tldoperator.help to register and find more information.
Follow CircleID on Twitter
More under: Top-Level Domains
Until the launch of the New gTLD Program, TLD launches were relatively straightforward. They generally consisted of a Sunrise Period, a Landrush Phase, and then General Availability. We would see the occasional Grandfather Phase or "Founders" program, but all in all, launches were pretty standard and straightforward.
Things started to change with the launch of the new gTLD program. Not only did the volume of launches increase, causing brand owners to make tough decisions about what and where to register, we were introduced to new launch phases, including Early Access Programs (EAP) and controversial pricing models. When the .SUCKS registry announced its pricing model earlier this year, most brand owners were upset and felt like they were being penalized by having to pay more to protect their brands.
While the .SUCKS pricing model has been quite controversial, we're starting to see other registries follow suit. One particular registry recently announced their "Brand Protection Premium Domains" and it's anticipated that most trademarks, brand names and company names will be on their Premium Domains list. Brand holders with brands/trademarks on this list that do not reserve their domain during the Sunrise Phase will have to pay more than double to register their domain during General Availability.
Another registry recently announced a similar program. Their "Protected Names" program, designed to further protect well-known entities, will consist of reserved high profile brands and names in music, sport, TV, film, celebrities, clubs, publishing and other sectors which may have fan bases. Brand holders with brands/trademarks on the Protected Names list that do not reserve their domain during the Sunrise Phase will have to pay additional fees to register their domain during General Availability.
How will brand owners react to these types of launches and inflated registration fees? Will we see even more registries implement this type of pricing model? Brand owners will have to continue making tough decisions about what, where, and when to register. For some brand owners, it may be more cost effective to register during the Sunrise period, where available. For others, they may want to wait to see if any infringement occurs and take action when necessary.
Stay tuned, I have a feeling this will continue to get very interesting.
Written by Alison Simpson
Follow CircleID on Twitter
I previously provided a brief overview of how Verisign iDefense characterizes threat actors and their motivations through adversarial analysis. Not only do security professionals need to be aware of the kinds of actors they are up against, but they should also be aware of the tactical data fundamentals associated with cyber-attacks most commonly referred to as indicators of compromise (IOCs). Understanding the different types of tactical IOCs can allow for quick detection of a breach, as well as prevention of a future breach. For purposes of this overview, iDefense breaks IOCs into three distinct categories: email, network and host-based.
Advanced threat actors often use free email services to send socially engineered emails to targeted organizations and individuals due to ease of use and relative anonymity. Email IOCs can be revealed in a few ways:
- Sender's email address and email subject: Actors create emails from addresses that appear to belong to recognizable individuals or prominent public figures, or highlight current events and other calls to action to create intriguing email subject lines with the goal of getting victims to open socially engineered emails.
- Attachments and links: Malicious attachments and links are used in spear-phishing emails and campaigns. These are often reused, so it would be beneficial to track and monitor these specific files and links.
- X-forwarding IP address: This is an email header field that identifies the originating IP address of a client connecting to a Web server through a HTTP proxy or load balancer. Compromised servers are often used when sending socially engineered emails, and infrastructure can be reused when launching an attack. So, while a X-forwarding IP address will not provide the email's originating IP address, it does provide the address through which the email was proxied, which allows for additional insight into the attack infrastructure used against the organization.
- X-originating IP address: This is an email header that identifies the originating IP address of a client connecting to a mail server. Depending on the mail servers being used, this field does not always appear in email headers; however, similar to X-forwarding IP addresses, monitoring these IP addresses when available can provide additional insight into attackers.
Network IOCs are revealed through:
- URLs: Used for command and control (C2) and link-based malware delivery. URLs can be strong IOCs as they are usually unique paths created by threat actors for their attacks.
- Domain names: Used for C2, malware delivery through malicious links in socially engineered email attacks and as data exfiltration sites. Organizations can monitor and block known bad domains to disrupt threat actors.
- IP addresses: Used for assisting organizations in detecting attacks from known compromised servers, botnets and systems conducting distributed denial of service (DDoS) attacks. However, this IOC has a short shelf life as threat actors move from one compromised server to another, and with the development of cloud-based hosting services, it is no longer just compromised servers that are being used, but legitimate IP space belonging to large corporations.
- User-agent strings: Used to identify a computer's operating system, browser type and other computer-specific information to allow Web pages and data to render correctly on the client.
These IOCs can be found through analysis of the infected computer within an organization's enterprise. Host-based IOCs are revealed through:
- Filenames and file hashes: These include names of malicious executables and decoy documents, as well as the file hashes of the malware being investigated and the associated decoy documents.
- Registry keys: These are keys added by malicious code and specific keys modified within a computer's registry settings to allow for persistence. This is a common technique that malware authors use when creating Trojans.
- Dynamic link libraries (DLLs): Actors often replace Windows system files that Windows loads during its startup process. This replacement action ensures that its payload executes each time Windows carries out its startup procedures.
- Mutual exclusion (mutex): This is a program object that can be used to limit access to a resource, and is often used by malware authors to ensure a host is infected by only one instance of the malware in question.
Organizations need to be wary of the increasing number of IOCs and implement a system to measure and evaluate the quality of indicators accordingly. Having contextual information to accompany indicators is critical for a machine or a human to make better decisions around resource allocation and determine a proper course of action. .
Creating a dynamic database comprised of all the elements, or data fundamentals, that make up the cyber threat landscape, and having them visually displayed in an interconnected contextual manner is a great way to enable people and machines to make better security and business decisions.
Stay tuned for upcoming blog posts in which I will expand upon this concept and how the Verisign iDefense IntelGraph platform can help practitioners improve their security posture and allocate resources more effectively.
Learn more about proactive threat intelligence from Verisign iDefense Security Intelligence Services by visiting VerisignInc.com/iDefense.
Written by Josh Ray, Senior Intelligence Director at Verisign
Follow CircleID on Twitter
The next Registration Operations Workshop will take place at the start of IETF 93 on Sunday, July 19th, 2015. The focus of this workshop is on the Registration Data Access Protocol, the successor of Whois. RDAP is a combined protocol for IP addresses and names registration data. Therefore, we are expecting both domain names and RIR communities to attend the workshop.
The RDAP profile for ICANN accredited registries and registrars was also discussed this week during ICANN 53. Therefore, it is of great interest for the name community to get awareness of this protocol.
We are seeking for papers related to RDAP to be presented at the workshop. We are also planning a panel of implementors to discuss their experience. Some possible topics:
- Implementation experience
- Deployment strategies with whois
- Test and conformance
- Authentication and authorization
- Service Discovery
- Protocol Overview
- Test Suite
- Implementation Panel
- Federated Authentication
Papers shall be submitted on the ROW web site or by email to firstname.lastname@example.org. Deadline is June 30th.
The workshop will be held July 19th 2015, from 12:30 p.m. to 4:30 p.m. at the Hilton Prague. Space is limited so please register early on the ROW web site. We'll do our best to accommodate late registrations and walk-ups, but with limited space we may need to limit participation to those who register in advance.
Written by Marc Blanchet, Internet Network Engineer and Consultant
Follow CircleID on Twitter
We, domain name and Trademark professionals, think end-users know about domain names. The truth is that few of them have ever heard of what a domain name is and worth; very few have heard about new descriptive domain names so I asked a Club manager my questions.
A sport club
A week ago, I went to the Nameshield's birthday. The Nameshield's Group was celebrating its 20th birthday and the Paris Gotha was there: luxury Trademarks, International Corporations and other smaller companies. Representatives of a famous French sports club were there and I bumped into them to ask my question: "any plan to change to a .club domain name?”
What a question!
Of course, the question had been considered. A sports club could consider changing to the domain name extension of the sport it is part of but you would be surprised to know that, for example, a football club is often involved in more than just football so a ".sport" domain name may not be appropriate, in all cases.
This is where it is becoming interesting...
Changing to a new domain name means more work and more insecurity as there is some risk: why change something that works?
It started with the same good old talk about Search Engine Optimization ("SEO"), losing positioning on the first page of Google results… If I clearly understood that reasoning on the part of a small club, I think it is a non sense for a club that already has some notoriety because notoriety is considered in Google search engine's algorithm. Regarding losing all links pointing to your old ".com" domain name, any good SEO agency has a solution to solve that problem. Changing to a new domain name implies some preparation.
Then some other reasons started appearing:
1) If it is not time consuming for a small club, it can really be for a major club. Changing to a new domain name implies to:
a) Inform and explain internally the reason for the change;
b) RE-inform and RE-explain internally the reason of the change;
c) Prepare the email change (...):
- Instaure a double email use so it remains possible to use both emails: the former one and the new one. This is critical;
- Prepare templates so email users can explain the reason for this change to...their entire address book;
- Add a mention in the signature, to the attention of email readers and remind them to update their address book.
d) Do the technical changes on the servers and on each PC and laptops concerned, unless the email application in use is in Software As A Service mode (i..e Google Apps).
2) It has a cost: major Clubs hire a lot of people and communicate. Changing to a new domain name means updating all these people with new visiting cards and upgrading existing marketing and other communication documentation with its new public name.
Changing to a new descriptive domain name is a major improvement; it is an opportunity to reach out to an existing audience showing innovation and precision. If the technical risk is limited, there is a risk to confuse the audience on a short period of time during the transition.
Innovation is important and if I am confident that the risk for a Club changing from an old fashion domain name to a new ".club" is worth it, I believe that what matters too is to think about the future: "change or die" (!) New domain names are developing little by little and the increasing registration volume of .club domains clearly shows that they are being adopted. If one Club does not plan to use it now, it is possible it is going to changes its mind within a few years when these have become mere standards.
Written by Jean Guillon, New generic Top-Level Domain specialist
Follow CircleID on Twitter
Where has DNSSEC been successful? What are some current statistics about DNSSEC deployment? What are examples of innovations that are happening with DNSSEC and DANE?
All of these questions will be discussed at the DNSSEC Workshop at ICANN 53 in Buenos Aires happening on Wednesday, June 24, 2015, from 09:00 – 15:15 Argentina time (UTC-3). You can watch and listen to the session live at:
All the slides that will be presented are currently available for download. The session will be recorded and the recording will be available from that same URL sometime after the meeting.
Here's a quick look at the agenda for the day's session:
1. Introduction and DNSSEC statistics – I will begin the day introducing the session and providing some of the latest statistics and information about DNSSEC deployment, both in terms of validation and signing.
2. DNSSEC Activities in the Latin American Region – We'll have a series of speakers providing updates on DNSSEC deployment in the LAC region. Speakers include:
- Luciano Minuchin, NIC.AR – NIC Argentina (also panel moderator)
- Luis Diego Espinoza, Consultant, Costa Rica – DNSSEC Activities in LAC
- Carlos Martinez, LACNIC – DNSSEC in the Reverse Tree at LACNIC
- Gonzalo Romero, .CO – DNSSEC in the .CO: ccTLD Experiences and Challenges
- Rubens Kuhl, .BR – .BR DNSSEC Update ICANN 53
- Hugo Salgado, NIC.CL – DNSSEC in .CL: ICANN 53 Update
3. Update on DNSSEC KSK Root Key Rollover – Ed Lewis of ICANN will give an update on the work around planning the rollover of the root key of DNSSEC.
4. DNSSEC Automation – After a short break we'll have a panel moderated by Russ Mundy about how to better improve the automation of DNSSEC activities. Panelists include:
- Eberhard Lisse, .NA – DNSSEC with SmartcardHSM
- Robert Martin-Legène, Packet Clearing House – Packet Clearing House (PCH) DNSSEC Signing Service
- Joe Waldron, Verisign – Verisign DNSSEC Signing Service
After this session we'll break for lunch as well as the "Great DNS Quiz". The lunch is sponsored by:
5. Demonstrations and Presentations: DANE and Applications – After lunch, I'll be moderating a panel where we'll be demonstrating some of the innovative things people are doing with DNSSEC and the DANE protocol. Panelists include:
- Jaap Akkerhuis, NLNetLabs – One Year of DANE (Some) Lessons Learned
- Wes Hardaker – Opportunistic SMTP Security
- Jacques Latour – DNS Operator Role in Domain Management
- Glen Wiley, Eric Osterweil and Danny McPherson – DNSSEC/DANE: Tools to Encourage Adoption
6. Deploying New DNSSEC Algorithms – I'll then provide the last major presentation discussing the different aspects of deploying new cryptographic algorithms for use in DNSSEC. A specific case for this is the ECDSA algorithm, but the topics I'll cover will be applicable for all new algorithms.
7. DNSSEC - How Can I Help? – Finally, we'll wrap up with Russ Mundy and myself talking about the steps people can take when they leave the workshop to help in accelerating the deployment of DNSSEC.
If you are interested in DNSSEC and DANE, these workshops are excellent ways to keep up-to-date with the latest changes and developments in the world of DNSSEC. I'd encourage any of you to join in and listen. (Questions can also be submitted by remote participants.)
P.S. If you would like to get started with DNSSEC or DANE, please visit the Internet Society Deploy360 "Start Here" page to find resources to begin!
Written by Dan York, Author and Speaker on Internet technologies
Follow CircleID on Twitter