Categories
Domain Name System (DNS)

Africa DNS Forum: Taking Stock and Planning Ahead

The 5th Africa Domain Names System (DNS) Forum was successfully closed on 28 July after three days of insightful reflections on the Africa DNS Industry and the business opportunities it can provide. This forum follows on the success of previous fora that have taken place in Africa over the past few years – namely South Africa in 2013, Nigeria in 2014, Kenya in 2015, and Morocco in 2016. 
 
Organized by the Internet Corporation for Assigned Names and Numbers (ICANN), the Internet Society, and Africa Top Level Domains Organization (AfTLD) and hosted by the Tanzania Network Information Centre (TzNIC), this year’s event was held under the theme “Taking stock of the Africa DNS Industry and planning ahead.” The official opening of the event was officiated by the Deputy Minister of Works, Transport, and Communications of Tanzania, Acting Director General of Telecommunications Regulatory Authority (TCRA), Chairperson of TISPA, Chairperson of TzNIC, the Africa VP Stakeholder for Engagement from ICANN, and the Internet Society. The session received major media coverage followed by a media briefing round-table for all the organizing partners and one-to-one interviews in English and Swahili.
 
The Internet Society staff participated in a number of panel discussions over the course of the 3 days and provided live-streaming support for the entire event. The event was remotely followed by 2160 unique views on Livestream and 392 unique views on Facebook live.
 
ZACR who manage the. Za and. Africa Top Level Domain Names also contributed to the DNS Forum by delegating the domain name “dnsforum.africa” to the event which was used for the event website http://dnsforum.africa .
 
During the meeting, the Africa DNS Market Report was launched. The report highlights the strengths and weaknesses in the Domain Name Service (DNS) sector in Africa, develops recommendations on how to maximize opportunities available and address identified challenges, and explores options for monitoring the growth, development, and emerging needs of the DNS market in Africa. One of the main takeaways of the meeting was the need to create working groups to deal with emerging issues relating to DNS in Africa such as blockchain, payment gateways, DNS Observatory, and localization of the DNS Forums.

You can learn more about the Africa DNS Forum here.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security

Rough Guide to IETF 99: DNS Privacy and Security, including DNSSEC

There’s a good bit of DNS secrurity and privacy activity happening at IETF 99 next week in Prague, although not all of that is in working groups. Here is a view of what is going on.

IETF 99 Hackathon

Once again there will be a good-sized “DNS team” at the IETF 99 Hackathon over the weekend (15-16 July). The IETF 99 Hackathon wiki outlines the work (scroll down to see it). From a security point of view, major projects include:

  • Continuing work on how DNS implementations deal with the impending KSK rollover in October 2017.
  • RFC 5011 compliance testing (related to the KSK rollover)
  • Implementation of the new elliptic curve crypto algorithm, Ed25519, defined in RFC 8080.

There is also work on multiple other DNS records and tools, including a new packet capture format focused on DNS. Anyone is welcome to join us for part or all of that event.

DNS Privacy Tutorial

On Sunday, July 16, there will be a “DNSPRIV Tutorial” from 12:30-13:30 CEST (UTC+2). This will explain the work of the DPRIVE working group to add a layer of confidentiality to DNS queries. Much of this involves sending DNS queries over TLS.

It is possible (and I’ll update the post if it is) that this tutorial may be streamed out over the IETF YouTube channel and recorded. The www.ietf.org/live page doesn’t have it listed yet, but I would check there to see closer to the date.

DNS PRIVate Exchange (DPRIVE)

On the same theme, the DPRIVE working group meets Tuesday morning from 9:30-12:00 CEST.  The draft agenda shows their should be good discussion on several of the current working group drafts. I am also looking forward to the discussion about DNS over the QUIC protocol. The group will also discuss measuring the usage of DNS-over-TLS and talk about what comes next.

DNS Operations (DNSOP)

The DNS Operations (DNSOP) Working Group meets twice in Prague. First on Tuesday, July 18, from 15:50-17:50 CEST, and then on Thursday, July 20, from 18:10-19:10.

The agenda isn’t out yet, but two drafts related to DNSSEC that might be up for discussion include:

There are a range of the other documents related to DNS security or privacy – or that can have impacts on those topics. We’ll have to see what gets onto the agenda.

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

The DNS-SD working group will also have a brief discussion of DNS-SD Privacy drafts. Agendas aren’t posted yet, but the Using TLS in Applications (UTA) working group often has drafts of interest, as does the Security Area Open Meeting (SAAG). The thing about DNS is that it is so critical to every service that it often shows up in many different groups.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 99:

DPRIVE (DNS PRIVate Exchange) WG
Tuesday, 18 July 2017, 09:30-12:00 CEST (UTC+2), Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSOP (DNS Operations) WG
Tuesday, 18 July 2017, 15:50-17:50 CEST (UTC+2), Congress Hall II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Wednesday, 19 July 2017, 15:20 – 16:50 CEST (UTC+2), Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blogTwitterFacebookGoogle+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf99.

Categories
Building Trust Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security Open Internet Standards Technology

29th DNSSEC Root Signing Ceremony

On the 27th of April 2017, the 29th DNSSEC root-signing ceremony took place.

A good description of the ceremony is written by Ólafur Guðmundsson. Perhaps you want to skim that blog first, as I will refer to it a few times below. You may also want to refer to my previous blog posts about the 25th, and 27th ceremonies – this blog post is remarkably similar to those because all these ceremonies are remarkably uneventful.

As one of the 7 ‘key-holders’ at the east-coast facilities in Culpeper, Virginia (USA) I have two responsibilities:

1. Help open the safe deposit box that contains smart-cards that are needed to operate or perform maintenance on the hardware signing machine that contains the actual private root key. There are 7 of those safe deposit boxes (tier 7) inside a safe (tier 6), inside a highly secured cage (tier 5) that is in a secured room (tier 4) with dedicated access control gate (tier 3 and tier 2) that lives inside a secure and guarded facility (tier 1). At least 3 key-holders are needed to open at least 3 safe deposit boxes, to get at least 3 of those smart cards to access the HSM, that is kept in another safe. There are different sets of people needed to gain access at any tier. The odds that they collude are minimal.

2. Witness the whole process and attest publicly to what I’ve seen. This blog post serves as that attestation.

Attestations

Attestation one: I attest that Root Key Ceremony 29 took place according to the script with no exceptions whatsoever.

Attestation two: During Act 2 of the the ceremony the Operating System DVD was replaced and the old OS DVD copies (release release 20161014 ) were discarded, conform step 11 of the script. I took one of the DVDs and using the macports version of OpenSSL version 1.0.2k verified the SHA256 checksum of the disk. That checksum is exactly the same as the checksum recorded during ceremony 27 – Act 2 – Step 6 and the checksum over the image that has been published for ceremony 27, 28, and 29:

991f7be8cfbc3b4bdb6f5e5f84092486755a08a3c36712e37a26ccd808631692

There have been two disks used during the ceremonies; I only took one.

I make this attestation because having an independent SHA implementation calculate the checksum validates that the checksum on the OS DVD is functioning as expected.

The reason for the OS replacement is that 3-sets of keyset signatures needed to be changed during this ceremony – having to do with the pre-publication of the new key signing key, and possible roll-back scenarios, in addition minor improvements and fixes were made. I have not performed any audits or reviews of the code or the changes. The new OS DVD image is published here.

Root Key rollover

Let me use the opportunity to give a heads up about the root key rollover that is happening this year. If you are responsible for running a DNSSEC enabled recursive name server you must understand that you have to take action and when.

The root keys were generated during ceremony 1 in 2010 and will be replaced for the first time over the next year. The first step of that process happened in October: the generation of the new key. The hash over that key has been published on the IANA website in February. The SHA256 hash of that key as it would show in the DS record is: E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

You can already configure your recursive name server to validate using that key so that you are future-proof. Just realize it is not yet in production; you MUST NOT remove the anchor that you have currently configured as signatures with the new key will only be generated as of October 2017.

Better just verify if your nameserver is configured to support the RFC5011 rollover mechanism. If it doesn’t you have to still check whether the ‘good thing’ happens. If it doesn’t you have to pay particularly good care to configure a new trust anchor in Q4 of 2017 when the actual rollover takes place. See ICANN’s KSK rollover web resources for more information.

Categories
Building Trust Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security Open Internet Standards

27th DNS Root Key Ceremony

The 27th DNSSEC root-signing ceremony took place yesterday, on 27 October. This ceremony is special because a new root key has been generated and that will have operational impact for everybody running a secure recursive nameserver. More on that below.

good description of the ceremony is written by Ólafur Guðmundsson. Perhaps you want to skim that post first. You may also want to refer to my previous blog post about the 25thceremony.

As one of the 7 ‘key-holders’ at the east-coast facilities in Culpeper, Virginia, I have two responsibilities:

  1. Help open the safe deposit box that contains the smart cards needed to operate or perform maintenance on the hardware-signing machine that contains the actual private root key. There are seven of those safe deposit boxes (tier 7) inside a safe (tier 6), inside a highly secured cage (tier 5) that is in a secured room (tier 4) with dedicated access control gate (tier 3 and tier 2) that lives in a secure and guarded facility (tier 1). At least three key-holders are needed to open at least three safe deposit boxes, to get at least three of those smart cards to access the HSM, which is kept in another safe. There are different sets of people needed to gain access at any tier. The odds that they collude are minimal.
  2. Witness the whole process and attest publicly to what I’ve seen. This blog post serves as that attestation.

Root Key Rollover

The root keys were generated during ceremony 1 in 2010 and will be replaced for the first time over the next year. The first step of that process happened yesterday: the generation of the new key. It is important for anybody who operates a validating recursive nameserver to verify if their nameserver is configured to support the RFC5011 rollover mechanism. If it doesn’t, you have to pay particularly good care to configure a new trust anchor in Q4 of 2017 when the actual rollover takes place. See ICANN’s KSK rollover web resources for more information.

Alain Aina pressing the key to generate the new root key.

Attestations

Attestation one:

I attest that Root Key Ceremony 27 took place according to the script with only one exception: In step 17, we discovered that the USB keys that needed to be reformatted were not formatted in the first place; the commands in that step (and steps 18-23) were not followed to the letter (no unmount needed before the formatting took place, and a confirming mount and unmounts added after the formatting of the thumb drives).

Attestation two:

During Act 2, steps 6-11 of the ceremony, the Operating System DVD was replaced and the old OS DVD copies (release 20160503) where discarded, conform step 11 of the script. I took one of the DVDs and using the MacPorts version of OpenSSL version 1.0.2.H, I verified the SHA256 checksum of the disk. That checksum is exactly the same as the checksum recorded during ceremony 25 – Act 2 – Step 6:

6cabb3c146aa13fbc9a9d61488b2c6f8c7e9e723a89b8574b0288578a65cc0f5

There have been two disks used during the ceremonies; I only took one.

The reasons for the OS replacement were that: the signer needed to be able to deal with the change in the signature validity date on the keyset going to 21 days; the organization unit name in X509 certificates (only used in a CSR that doesn’t go anywhere) was changed from “ICANN/IANA” to “PTI”; there was some software added to perform PGP wordlist checks, and; some minor typos in the audit were fixed. I have not performed any audits or reviews of the code or the changes.

Attestation three:

The SHA256 over the new root key is:

E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

The private key still needs to be transferred to the west coast facilities before we can be certain that it will be used to sign the root next year. Only after IANA has published the key is it safe to configure this hash. There are very few circumstances under which the key we generated yesterday will not be used in production; each of those circumstances would be an important exception that would need to be announced and explained in the most transparent way.

Attestation four:

The ceremony involved 23 men and no women. That should change.

[Photos courtesy of Olaf Kolkman.]
Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Privacy

Rough Guide to IETF 96: DNSSEC, DANE and DNS Security

Once again, it looks like the most vigorous area of DNS security discussion at next week’s IETF 96 meeting in Berlin may be in the Using TLS in Applications (UTA) working group. As was the case earlier this year at IETF 95 in Buenos Aires, the UTA working group is exploring different options for securing email communication. DNSSEC and DANE both feature to different degrees in some of the proposals.

There will also be a great amount of DNS security activity at the IETF 96 Hackathon this weekend. ICANN will also be hosting a special session on Tuesday to talk about the DNSSEC Root Key Rollover.

Beyond that, though, IETF 96 will be a much quieter week than usual on the DNS front. Two of the main IETF working groups related to DNS security, DANE and DPRIVE, have been able to accomplish most of their work via email and therefore did not have a need to meet next week. Similarly, the CURDLE and TRANS working groups also decided not to meet. The ARCING BOF we mentioned last time is also not meeting this week.

IETF 96 Hackathon

On this coming weekend over 20 people will gather as the “DNS team” in the IETF 96 Hackathon working on various projects around DNSSEC, DANE, DNS Privacy, using DNS over TLS and much more. I wrote about this on the Deploy360 blog and you can also get more info in the IETF 96 Hackathon wiki. Anyone is welcome to join us for part or all of that event.

DNS Operations (DNSOP)

The DNS Operations (DNSOP) Working Group meets on Monday afternoon from 15:40-17:40. There is a lengthy agenda. Discussion areas of interest to us include:

  • a proposal to allow recursive resolvers to cache negative (NSEC/NSEC3) answers.
  • an implementation of DNS over TLS
  • multiple drafts up for discussion about ways to pass multiple DNS responses to a query (the interest here is in potentially speeding up DNSSEC responses)

If there is time remaining, which may depend upon how long the “special names” discussion goes, I intend to talk about our Internet Draft on DNSSEC cryptographic algorithm agility.

ICANN DNSSEC Root Key Rollover Discussion

On Tuesday from 12:30 – 13:45, representatives of ICANN and Verisign will be holding a discussion in the Bellevue room on “Upcoming ZSK and KSK Changes to the Root Zone“.  This is part of their broader outreach to make sure people are aware of upcoming changes to the size of the keys and the “rolling” of the root key.  Duane Wessels (Verisign) and Matt Larson (ICANN) made a similar presentation at ICANN 56 in Helsinki last month and I’m looking forward to the discussion here in Berlin.

Other Working Groups

We will be monitoring the TLS WG, particularly given the focus on TLS 1.3, the Security Area open meeting and other similar sessions. The DNSSD working group will also be meeting although it’s not clear that security topics will be covered there right now.

While the week will be quieter, we’re definitely looking forward to seeing the work move forward.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 96:

DNSOP (DNS Operations) WG
Monday, 18 July 2016, 1540-1740 CEST, Room Bellevue
Agenda: https://datatracker.ietf.org/meeting/96/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

UTA (Using TLS in Applications) WG
Tuesday, 19 July 2016, 1620-1820 CEST, Room Potsdam II
Agenda: https://datatracker.ietf.org/meeting/96/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/

Follow Us

There’s a lot going on in Berlin, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf96.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security Open Internet Standards Technology

25th DNS Root Key Ceremony

Last week, the 25th DNS root key ceremony took place.

The context of this ceremony is that for DNS security purposes the root of the DNS is signed using a cryptographic key. The use of that key is subject to stringent access requirements and the ceremony provides the transparency that is needed for the Internet community to ultimately trust the authority and integrity of DNS data.

An in-depth explanation of the ceremony is out of scope for this post, but Ólafur Guðmundsson’s blog post gives a reasonable overview of the ceremony itself and the links in that article and our Deploy360 pages on DNSSEC should give you sufficient information if you want to deploy DNSSEC yourself.

The reason for this post is that I want to make two attestations and give a heads up.

Attestation one: I attest that Root Key Ceremony 25 took place according to the script with only one exception: the Ceremony Administration was not performed by Francisco Arias, but by Punky Duero.

Attestation two: During Act 2 of the the ceremony the Operating System DVD was replaced and the old OS DVD copies (Rev600) where discarded, conform step 11 of the script. I took one of the DVDs and using OpenSSL version 1.0.2e from OS X 10.11.4 I verified the SHA256 checksum of the disk. That checksum is exactly the same as the checksum recorded during ceremony 7 – step 12: 7da0d1c5eecb822d7bbd47b31d25e4f0f37bb8a46cfbe288d2b07b32f5e38146

There have been two disks used during the ceremonies, I only took one.

As an aside, the reason for the OS replacement is that the signer needed to be able to deal with the larger (2048 bit) zone signing keys that will be used to sign the root zone. More detail about the key-size increase can be found in this Verisign blog.

Heads up: The plans for the rollover of the root key are being developed. If you run a validating name server this may impact you. Please follow the developments around the KSK rollover project via https://www.iana.org/dnssec.

Pictures from the 25th ceremony by the author can be found on Flickr.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Internet Governance

ICANN 54 in Dublin: IANA, Women In Technology, DNS Security and more…

Over the next seven days we’ll have an Internet Society team on the ground in Dublin, Ireland, at the 54th meeting of the Internet Corporation for Assigned Names and Numbers (ICANN). In fact, some of our team members are already in Dublin engaged in the IANA stewardship transition meetings that will occur for much of this weekend.  As was the case with ICANN 53 in June in Buenos Aires, we expect the IANA transition to dominate much of the policy discussions all week.  Please visit our IANA stewardship transition page for more information about our views.

Beyond IANA, we expect some policy discussions about the upcoming Internet Governance Forum (IGF) in November and the 10-year review of the World Summit on the Information Society (WSIS+10). There will be a public session on “Internet Governance” on Thursday, 22 October, from 9:30 – 11:00 Irish Standard Time (IST) that will be available for remote participation at:

https://meetings.icann.org/en/dublin54/schedule/thu-ig

We expect that Konstantinos Komaitis will participate in that session on our behalf.

Outside of the policy space, our President and CEO, Kathy Brown, will participate in a session on Monday, 19 October, from 15:15 – 16:45 IST on “Women in ICANN, Internet and ICTs: Opportunities and Challenges“. Remote participation is available at:

https://meetings.icann.org/en/dublin54/schedule/mon-women-ict

This builds on Kathy’s activities in Deauville, France, this past week where she spoke on a high-level panel at the Women’s Global Forum about how digital technologies are driving poverty reduction.

As per usual at ICANN meetings, I will be very active with DNS security (DNSSEC) sessions, including an introductory session on Monday and the 6+ hour DNSSEC Workshop most of the day on Wednesday. I wrote about this in more detail over on the Deploy360 blog.   I will also be participating in the Technology Experts Group meeting on Wednesday. (UPDATE, 16 Oct: ICANN CTO David Conrad just canceled the TEG meeting due to scheduling conflicts.)

On Tuesday evening we’ll hold our regular “ISOC@ICANN” meeting for Internet Society members, but we’re changing the format a good bit and trying out some new ideas. We’ll also be holding the event in an actual castle!  You can find out more information in Connect and register if you are an ISOC member who will be attending ICANN54.

Beyond all of that, you can expect us to be visible in many of the sessions throughout the ICANN 54 week, engaging in the discussions and continuing our work to ensure the Internet remains open, trusted and available to all.  Please do find us and say hello!


Image credit: Dan York

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF

Rough Guide to IETF 92: DNSSEC, DANE and DNS Security

As per usual, DNSSEC, DANE and DNS security in general are all topics of great attention at IETF 92. The major DNS-related working groups, DNSOP and DANE, are both meeting with busy agendas and the DPRIVE working group is back again with a focus on DNS privacy concerns. Here is a rough view of what the week looks like…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely and listen to these sessions.

DNS PRIVate Exchange (DPRIVE)

Starting out the week on Monday from 15:20-16:50 will be the second meeting of the DPRIVE Working Group that is chartered to develop: “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.” As the DPRIVE agenda for IETF 92 shows, there should be a good set of discussions about how we can make DNS transactions more secure and confidential.  I’m looking forward to this session!

DNS Operations (DNSOP)

Tuesday afternoon from 15:20-17:20 CDT the DNSOP Working Group has a full agenda that includes some drafts around securing DNS in general (ex. QNAME minimization, restricting DNS meta-queries) as well as some new work about DNS terminology, reserving new TLDs and operational issues with DNS.  The most relevant draft to DNSSEC will be draft-fujiwara-dnsop-nsec-aggressiveuse looking at ways to improve the use of NSEC/NSEC3 to indicate non-existance of domain names.  Overall, though, it should be a strong session looking at ways to make DNS more secure!

DNS-based Authentication of Named Entities (DANE)

Immediately following DNSOP, the working group looking after the DANE protocol  will be meeting from 17:30-18:30 CDT to discuss how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. At the moment I am writing this, the meeting agenda only lists updates from Glen Wiley and Eric Osterweil to the S/MIME library, but we’ll have to see what else gets added. The DANE mailing list has been extremely actively lately and the topics under discussion there may get some time at the Dallas meeting.

Extensible Provisioning Protocol Extensions (EPPEXT)

In the unenviable final session on Friday from 11:50-13:20 CDT, the EPPEXT working group will be meeting to discuss extensions to the EPP protocol used between DNS registrars, registries and similar entities.  An agenda has not yet been posted but the group has a number of documents under active consideration and many participants will also have attended the Registration Operations Workshop on the Sunday prior to IETF 92.  Of most interest to us here are the extensions being proposed that will further automate DNSSEC operations and deployment.

Other Working Groups

Beyond the groups listed above, we’ll also be monitoring working groups such as DNSSD, HOMENET and TRANS.  While none of these groups have anything on their IETF 92 agendas specifically related to DNSSEC or DANE, the topics of DNS security or certificates do come up and its interesting to understand how they may or may not interact with other DNS security efforts.

Bits-and-Bites

Outside of the regular working group sessions, on Thursday evening from 19:00-21:00 CDT there will be the “Bits-and-Bites” reception where attendees can get food and drink and also see various exhibits from sponsors and other organizations.  I’m told that one table will be from Verisign Labs where they will be showing demonstrations of the getdns API being used with DNSSEC and DANE.  I’m not exactly sure what will be there, but if you are going to Bits-and-Bites you may want to stop by their table and see what it is about.

It will be a busy week – but the outcomes of all these sessions should go far to make the DNS more secure!

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 92:

dprive (DNS PRIVate Exchange) WG
Monday, 23 March 2015, 1520-1650 CDT, Venetian
Agenda: https://datatracker.ietf.org/meeting/92/agenda/dprive/ 
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

dnsop (DNS Operations) WG
Tuesday, 24 March 2015, 1520-1720 CDT, Gold
Agenda: https://datatracker.ietf.org/meeting/92/agenda/dnsop/ 
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

dane (DNS-based Authentication of Named Entities) WG 
Tuesday, 24 March 2015, 1730-1830 CDT, Venetian
Agenda: https://datatracker.ietf.org/meeting/92/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/

eppext (Extensible Provisioning Protocol Extensions) WG 
Friday, 27 March 2015, 1150-1320 CDT, Oak
Agenda: https://datatracker.ietf.org/meeting/92/agenda/eppext/ 
Documents: https://datatracker.ietf.org/wg/eppext/ 
Charter: https://datatracker.ietf.org/wg/eppext/charter/

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blogTwitterFacebookGoogle+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf92.

Categories
Building Trust Domain Name System (DNS) Improving Technical Security Technology

NDSS Guest Blog Post: Domain Name Abuse is Still Widespread

The Internet Society hosted the 2015 Network and Distributed System Security (NDSS) Symposium from 8-11 February in San Diego, California, USA. The conference featured a broad set of security topics, ranging from fundamental compiler and run-time vulnerabilities in code execution to observations about security issues at Internet scale. We asked some of the NDSS participants to write guest blog posts about their papers. This is one of those contributions.

Domain name abuse exists in many forms, including soundsquatting, typosquatting and bitsquatting, but in all cases consists of purposefully registering a domain name that is in some way or another confusingly similar to another domain name. In the specific case of typosquatting, a miscreant will register a domain name that is a mistype of a popular domain name or trademark. For instance, a typosquatter might register internetsoceity.org, in the hope of getting hits from visitors intending to visit internetsociety.org. Typosquatting is certainly not a new phenomenon; it has been known and studied for over 15 years. Over these years, many interesting results about typosquatting have been revealed, such as the fact that most typosquatting domains are monetized using ads and that shorter domains are targeted more frequently than longer domains.

What previous studies did not investigate, however, is the evolution over time of the content of typosquatting domains. For instance, it would be interesting to know whether typosquatting domains are changing hands from abusive to legitimate owners or vice versa. These kinds of questions are what inspired us to perform a longitudinal study of the typosquatting landscape, in which we collected and analyzed the contents of the typosquatting domains of the Alexa top 500 websites over a period of 7 months. The main effort of the analysis consisted of classifying those typosquatting domains into content-based categories. Some types of content can be considered legitimate use of a typosquatting domain, while others are abusive. For instance, we consider typosquatting domains that simply redirect their visitors back to the authoritative domain (so-called defensive registrations), and domains with original content that just happen to reside on a typosquatting domain of a popular website as legitimate. On the other hand, domains hosting ads, scams, adult content or malware were deemed abusive.

One of the results that was immediately clear from our analysis, was that the very large majority of the popular domains are the victim of typosquatting: 95% of the 500 authoritative domains we investigated have at least one abusive typosquatting domain. On the other hand, only 31% of the domains have a defensive registration. Hence it seems that legitimate domain owners are either not aware of the problem or do not consider the risks great enough to proactively defend against it.

As for longitudinal results, we found that typosquatting domains are indeed changing hands from abusive to legitimate owners, albeit not in great numbers: from the 28,179 domains we investigated, only 63 changed from legitimate to malicious usage and 91 changed from malicious to legitimate use during our data gathering period. This averages out to about 3 and 2 of such transitions per week respectively. On the other hand, if we look at the number of category transitions within the set of malicious categories, there are over 1,000 transitions per week. These are domains that appear to be diversifying their monetization strategy by switching, for example, from showing ads to hosting scams or vice versa.

Another surprising result is that about 50% of all abusive typosquatting domains are hosted by only 4 companies. Three of these companies are, in some way or another, involved in the domain parking business. A typical parked domain contains no other content than automatically computed advertising banners and links, in an attempt to generate revenue for its owner.

In a second study we conducted, we explored the ecosystem around such parked domains and concluded that it is driven by so-called domainers, domain investors that possess large portfolios of domains names. These investors rely on separate domain parking services, which facilitate the monetization of domain names by hosting parked webpages. In order for this business to be lucrative, parked domains need to receive a lot of visitors.

In the past, before search engines were strongly incorporated into web browsers, surfing the web involved significantly more typing of domain names in a browser’s URL bar than it does today. For instance, users would try to “guess” the domain names of websites relevant to their needs. Thus, a user who is interested in finding “cheap gas” could either visit a search engine and search for that phrase or, alternatively, concatenate the two words, append the most popular TLD and attempt to visit the cheapgas.com website. It is also worth noting that, at the time, browsers were trying to “help” users by appending TLDs before giving up on a domain. That is, if the user typed in cheapgas and the domain did not resolve, the browser would automatically append the .com TLD and try again. In both scenarios, a user could land on a parked page by attempting to type the address of a website. The traffic resulting from this action was appropriately named “type-in” traffic and is, historically, the reason why domain parking services appeared. Most likely, the recent extensive search engine integration into browsers heavily reduced this regular type-in traffic for parking pages, resulting in a huge decline in profit for the domain parking industry.

The way this industry appears to be compensating for this decline, is by resorting to the exploitation of abusive domain names, such as typosquatting domains, as a means of establishing a new source of monetizable visitors. In our research, we found that currently 16% of parked domains are abusing existing trademarks. Moreover, 37% of these domains are displaying advertisements of a competitor. This means that when a user lands on such a trademark-abusing domain, not only would the trademark holder “lose” that user’s visit, but the user could potentially end up on a website of a competing company.

Apart from displaying advertisements, we found that in 7% of the cases, parked domains are monetized by redirecting visitors to entirely different websites, often hosting scams, malware and adult content. This indicates that the domain parking industry is at least partly responsible for the malicious monetization strategies that were also observed in our typosquatting study.

One way to protect end users as well as trademark owners against these practices, is by blocking access to parked pages or by alerting users when they end up on a parked page during a browsing session. To this end, we developed a classifier that can detect parked domains based on page features such as the number of frames and iframes, the amount of third-party HTML content, the number and length of links to third-party content, etc.

From these two studies, we learned that both typosquatting and domain parking are still actively practiced today, despite being well-known for over a decade. Although they can be considered separate phenomena, they are clearly heavily intertwined.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Improving Technical Security Internet Governance

ISOC at ICANN52, Wednesday: The DNSSEC Workshop And Other Technology Topics

As happens on every Wednesday of an ICANN week, a major focus today will be the 6+ hour DNSSEC Workshop that will bring together some of the greatest DNS-related technical minds from across the industry for a session focused on how we continue to move DNSSEC forward and make the Internet more secure.  Attendees will learn about the current state of DNSSEC deployment within the region, about new tools and services and will discuss some of the current challenges and work together to discussion potential solutions.  Organized by the ICANN Security and Stability Advisory Committee (SSAC), the DNSSEC Deployment Initiative and our own Deploy360 Programme, the workshop begins at 8:30am Singapore Time and goes all the way through 2:15pm.  You can join in remotely at:

http://singapore52.icann.org/en/schedule/wed-dnssec

You can also download from that link the many presentations that will be discussed today – and if you can’t watch the event live a recording will be available after the event.  As I discussed last week, the sessions today will include:

  1. Introduction and DNSSEC Deployment Around the World
  2. DNSSEC Deployment in the Asia Region
  3. 10th Anniversary of DNSSEC Workshops
  4. Reverse DNS and DNSSEC in Japan
  5. ccTLD Deployment Experiences
  6. The Operational Realities of Running DNSSEC
  7. When Unexpected DNSSEC Events Occur
  8. DNSSEC and DNS Operators

The regional panel always provides an interesting view into current case studies and several of the other sessions will discuss some new tools and some new ways to use the DANE protocol.  The last panel of the day about DNS Operators should produce some very lively discussion about a challenge that has been identified by CloudFlare and others about how they can automate the large-scale DNSSEC signing of domains.  This should provoke some vigorous discussion as we collectively work to identify a solution.  Along the way we’ll also join in celebrating the 10th anniversary of these DNSSEC Workshops!

After the DNSSEC Workshop is over, I will also be participating with others in a joint meeting of the ICANN Board and the Technical Experts Group (TEG) in a more “forward-looking” session to discuss technologies such as the Internet of Things (IoT) and how that might impact the overall Domain Name System.  You are welcome to follow along at:

http://singapore52.icann.org/en/schedule/wed-board-technical

On the public policy side, our team members here will be continuing to engage in discussions related to the topics Konstantinos Komaitis wrote about last week.  If you look at the ICANN52 schedule for today you can see that the themes of the IANA transition and accountability continue to be discussed across many different groups.

During the day we will also have a lunch meeting with members of our Advisory Council who are here this week and will engage in a great number of individual meetings.  If you are here in Singapore and want to meet with us, please do find us in one of the sessions – or email me directly at york@isoc.org and I can connect you with the right person.

P.S. Please also read our posts from Monday and Tuesday, and our other ICANN52 public policy and technology posts, for more information about what we are doing here in Singapore this week.

Photo: a group picture from the Internet Society Members Meeting that occurred on Tuesday evening.

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security

Rough Guide to IETF 91: DNSSEC, DANE and DNS Security

IETF 91 will once again be busy for those of us interested in DNSSEC, DANE and DNS security in general. Two of the major DNS-related working groups, DNSOP and DANE, are both meeting with busy agenda and a new working group called DPRIVE will be meeting to talk about DNS privacy concerns. There are naturally other items related to DNSSEC and “DNS security” in general scattered throughout the week – here is what the week looks like…

NOTE: If you are unable to attend IETF 91 in person, there are multiple ways to participate remotely and listen to these sessions.

Public Notary Transparency (TRANS)

The week starts off on Monday at 15:20 with the TRANS Working Group focused on “Certificate Transparency” (CT) where the bulk of the agenda is about how to apply CT to the existing TLS/SSL certificate-based infrastructure. However, one draft, draft-zhang-trans-ct-dnssec, looks at how CT could be applied to DNSSEC. It’s an interesting idea and I’m looking forward to the discussion.

Extensible Provisioning Protocol Extensions (EPPEXT)

At the same time as the TRANS WG but over in the Lehua Suite, the EPPEXT Working Group will be meeting to discuss extensions to the EPP protocol used to communicate between registrars and registries for DNS and domain name information.  The DNSSEC angle here is that there will be a discussion of draft-ietf-eppext-keyrelay that documents the current way that SIDN performs secure transfers of a DNSSEC-signed domain from one registrar to another. (SIDN is the registry for the .NL domain in the Netherlands.) There was a good bit of discussion earlier this year about whether the goal is to document existing extensions and practices – or to create new standards-track extensions that could be used more widely.  The author team would like to document the current practice and there was further discussion around the best path forward.  Our interest here is primarily that we see further automation needed within the registry/registrar interactions to make DNSSEC-signing of domains more seamless to the users who are registering and signing domains.

DNS PRIVate Exchange (DPRIVE)

On Tuesday from 13:00-15:00 HST there is the brand new DPRIVE Working Group that is chartered to develop: “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.” The DPRIVE agenda for IETF 91 is full of a number of discussions about how we can best improve the confidentiality and privacy of DNS communication. Much of the discussion that led to the creation of this working group has centered around Stephane Bortzmeyer’s draft-ietf-dprive-problem-statement which lays out many of the concerns. This should be a session of vigorous and passionate discussion with many very different opinions about what needs to be done to improve this aspect of DNS security!

DNS Operations (DNSOP)

Tuesday afternoon from 15:20-17:20 HST the DNSOP Working Group has a busy agenda that includes a bit less about DNSSEC this time around (after the heavy discussion last time at IETF 90). The major DNSSEC-related draft under discussion will be Jason Livingood’s draft-livingood-dnsop-negative-trust-anchors that has generated a substantial bit of discussion on the dnsop mailing list.

Beyond that, though, there will be significant discussion on other DNS security topics such as a new proposed “DNS Cookies” security mechanism , the ideas around qname minimization to improve privacy (a topic coming out of the DPRIVE discussion) and a discussion around improving support for DNS over TCP. All in all it should be quite an interesting session!

DNS-based Authentication of Named Entities (DANE)

On Wednesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. At IETF 91 the DANE agenda looks to mostly focus on the DANE+S/MIME issues that have been heavily discussed in the working group email list. There are some strong disagreements and most recently an intellectual property rights (IPR) disclosure from Verisign that should ignite some discussion. Speaking of Verisign, the DANE agenda shows that Eric Osterweil may be presenting about their DANE+S/MIME prototype so we’ll have a chance to hear about true “running code”.

Matt Miller will also be discussing draft-ietf-dane-srv that specifies a mechanism for application protocols that use SRV records to find and use DANE’s TLSA records. Examples of such protocols include XMPP (Jabber) and SIP, so this draft will help expand DANE usage within real-time communications tools.

I will be closing out the current DANE WG agenda with a discussion of a draft I wrote, draft-york-dane-deployment-observations, that seeks to collect some of the feedback we’ve seen to date as more people roll out DANE usage within their applications and services. My main point is to encourage discussion around questions such as these:

  • What roadblocks are people running into with implementing DANE? (outside of the broader issue of getting DNSSEC validation and signing more widely available) are there lessons we can feed back into our process of developing DANE-related standards?
  • Are there more “Using DANE with <foo>” types of documents that we can or should create? (And who is willing to do so?)
  • Are there some good examples/case studies of DANE implementations that we could perhaps capture as informational RFCs? (The Jabber community’s implementation comes to mind)
  • Are there places where it would be helpful if there were reference implementations of DANE support? For example, DANE for email got a boost when support was added to postfix. Are there other commonly-used open source projects where the addition of DANE support would help move deployment along?
  • Are there test tools that need to be developed? Or existing ones that need to be better promoted? Are there interop tests we can arrange?

Some of these items might fit into work that can be done within the IETF – others might be better for projects like what we are doing here with the Deploy360 Programme. The key point is – what can we do to accelerate deployment of DANE?

Other Working Groups

Beyond the two main DNSSEC-related working groups and the new DPRIVE working group there will be a number of other DNSSEC-related discussions going on in other working groups. Here are some of the other groups that I’ll be monitoring:

HOMENET – On Wednesday morning the HOMENET working group does not have anything on its agenda specifically about DNSSEC, but draft-jeong-homenet-device-name-autoconf explores how home network devices and appliances and sensors that make up the “Internet of Things” (IoT) can be automatically configured with DNS names for monitoring and remote control. Our interest is naturally in how this interaction with DNS can be secured.

DNSSD – Similarly the DNSSD working group continues its work at how to extend “DNS service discovery (DNS-SD)” and “multicast DNS (mDNS)” outside of a simple local network such as a home network. This kind of service discovery is what happens when you, for instance, look to add a local printer or file server and your computer “discovers” the devices available on your network. The question is how to extend this beyond your local network to other networks to which you may want to connect. Hosnieh Rafiee’s draft-rafiee-dnssd-mdns-threatmodel is on the agenda and should generate some good discussion about DNS security.

As per usual at recent IETF meetings, it’s going to be a very busy week for those of involved with strengthening the Internet through improved DNS security!

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 91:

TRANS (Public Notary Transparency) WG
Monday, 10 November 2014, 1300-1500 HST, Hibiscus
Agenda: https://datatracker.ietf.org/meeting/91/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/

EPPEXT (Extensible Provisioning Protocol Extensions) WG
Monday, November 10, 2014, 1520-1720 HST, Lehua Suite
Agenda: https://datatracker.ietf.org/meeting/91/agenda/eppext/
Documents: https://datatracker.ietf.org/wg/eppext/
Charter: https://datatracker.ietf.org/wg/eppext/charter/

DPRIVE (DNS PRIVate Exchange) WG
Tuesday, 11 November 2014, 1300-1500 HST, Coral 5
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSOP (DNS Operations) WG
Tuesday, 11 November 2014, 1520-1720 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DANE (DNS-based Authentication of Named Entities) WG
Wednesday, 12 November 2014, 1300-1500 HST, Coral 3
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 13 November 2014, 1300-1500 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/

HOMENET (Home Networking) WG
Wednesday, 12 November 2014, 0900-1130 HST, Coral 3
Agenda: https://datatracker.ietf.org/meeting/91/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf91.

 

Categories
Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 90: DNSSEC, DANE and DNS Security

Tuesday at IETF 90 seems to be “DNS Day” with two of the major DNS-related working groups, DNSOP and DANE, both meeting that day and addressing some major topics. There are, of course, other items related to DNSSEC and “DNS security” in general scattered throughout the week – let me walk through what the week looks like…

DNS Operations (DNSOP)

Tuesday morning from 9:00-11:30 EDT the DNSOP Working Group kicks off with a full agenda that includes a great amount of DNSSEC activity. Matthijs Mekking will be presenting a draft about DNSSEC key and signing policies. Daniel Migault will be tackling the topic of what the requirements are for DNSSEC validation so that DNS resolvers can always have validation enabled.  

Of particular interest to folks looking to get DNSSEC deployed (as I am) will be the “DNSSEC Roadblock Avoidance” draft that explores what are the problems with DNSSEC validation in many common network environments – and how do we mitigate those problems.

As the agenda indicates, there will be a range of other topics covered in DNSOP, too. The biggest and most controversial discussion may be around how we optimize the distribution of root zone data, with Warren Kumari and Paul Hoffman offering one view of distributing the root zone and Paul Vixie and Xiaodong Lee offering another view of how to scale the root of DNS. Given that DNSSEC plays an important role in both scenarios we’ll be paying close attention to what I expect will be quite a passionate discussion!

Beyond those topics you can probably expect to see some of the many other documents under DNSOP (scroll down the page to see the full list) raised for consideration – unless, of course, the root optimization discussion consumes most of the time, as could easily happen.

DNS-based Authentication of Named Entities (DANE)

Later on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. We should see discussion around the “DANE and OpenPGP” draft as well as the “DANE and SMIME” draft. One of the DANE WG co-chairs, Olafur Gudmundsson, told me that the “SMTP security via opportunistic DANE TLS” draft and the “Using DANE with SRV Records” draft will both be going to Working Group Last Call and so that may or may not trigger some comments.

What may generate more discussion, though, is interest in changing the “DANE Operational Guidance” draft into a “DANEbis” document, i.e. looking at it as a replacement/update for RFC6698 that defines DANE. This should be an interesting discussion!

On a similar track, Paul Wouters will be speaking about standardizing how “Raw Public Keys” for TLS can be authenticated using DANE. As I understand it, Paul wants to extend the TLSA record used in DANE to support more than just PKIX-formatted certificates, allowing DANE to be used for applications that do not require PKIX certs.

I am also intrigued to learn more about ideas from Haixin Duan to use DANE to better secure the usage of HTTPS connections in content distribution networks (CDNs). Haixin Duan and some colleagues have written a paper that goes into more detail (search for “DANE” to jump to the relevant section).  

If there is time Olafur tells me that the chairs also intend to kick off a discussion of “reverse DANE”, i.e. DANE records for clients, that might lead to some interesting applications and areas of work.

Other Working Groups

Beyond the two main DNSSEC-related working groups there will be a number of other DNSSEC-related discussions going on in other working groups. Here are some of the other groups that I’ll be monitoring:

SIPCORE – On Monday afternoon Olle Johansson is on the SIPCORE agenda to talk about how DANE can be used to improve the security of VOIP sessions using TLS and SIP. This is a very cool use of DANE / DNSSEC at an application layer and I’m looking forward to the discussion.

TRANS - On Friday morning the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.

HOMENET - At the exact same time as TRANS on Friday morning, the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE).  The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services.  The second draft proposes new DHCP options that would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.

DNSSD – The DNSSD working group is looking at how to extend “DNS service discovery (DNS-SD)” and “multicast DNS (mDNS)” outside of a simple local network. This kind of service discovery is what happens when you, for instance, look to add a local printer or file server and your computer “discovers” the devices available on your network. The question is how to extend this beyond your local network to other networks to which you may want to connect. There hasn’t been a great amount of attention to DNSSEC here, but in both the DNSSD base requirements document and also the mDNS threat model document there are discussions of security and potential places where DNSSEC may potentially play a role. 

UTA – Finally, the Using TLS in Applications (UTA) working group agenda doesn’t directly mention DNSSEC, but we definitely pay attention to UTA given that the drafts all focus on securing TLS and that DANE could potentially play a role here. (We also have an interest for our “TLS For Applications” section of Deploy360.) Unfortunately UTA is scheduled Tuesday morning at the exact same time as DNSOP, which will make it quite challenging for those of us who want to be in two places at once!

All in all it will be a very busy week for those of involved with strengthening the Internet through improved DNS security! 

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 90:

DNSOP (DNS Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnsop/ 
Documents: https://datatracker.ietf.org/wg/dnsop/ 
Charter: http://tools.ietf.org/wg/dnsop/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)

DANE (DNS-based Authentication of Named Entities) WG 
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/
(Thursday, July 24, 2014, 1520-1720 EDT, Canadian)

TRANS (Public Notary Transparency) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)

UTA (Using TLS in Applications) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)

HOMENET (Home Networking) WG 
Agenda: https://datatracker.ietf.org/meeting/90/agenda/homenet/ 
Documents: https://datatracker.ietf.org/wg/homenet/ 
Charter: https://datatracker.ietf.org/wg/homenet/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)

SIPCORE (Session Initiation Protocol Core) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sipcore/
Documents: https://datatracker.ietf.org/wg/sipcore/
Charter: http://tools.ietf.org/wg/uta/charters/
(Monday, July 21, 2014, 1300-1500 EDT, Territories)

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf90.