Just a guy in Vermont trying to connect all the dots...
Dan York
Author's posts
Apr 20
Asia-Pacific Job Opening: Join Internet Society Deploy360 Programme to Promote IPv6, DNSSEC, More (Featured Blog)
Do you live in the Asia-Pacific region and are interested in accelerating the deployment of key technologies such as IPv6, DNSSEC, TLS or secure routing mechanisms? If so, my Internet Society colleagues involved with the Deploy360 Programme are seeking a "Technical Engagement Manager" based somewhere in the AP region. Find out more information about the position, the requirements and the process for applying. More...
Apr 11
Facebook Takes On Snapchat With Launch of "Messenger Codes" To Easily Connect Users
On the eve of Facebook's major "F8 Developer Conference" happening April 12-13, the company has launched a clear attack on Snapchat's "Snapcode" method of connecting users with their new "Messenger Codes". If you go into the newest version of Facebook Messenger on iOS (which is the only platform I have to test right at this moment) and click on the gear icon in the lower right labeled "Settings", you now see a brand new profile screen:
There are two things to note here:
- The circular shaped code around my profile image; and
- The new short URL of m.me/dyork which brings me to a web version of Facebook Messenger. (More on that in a different post.)
The circular code clearly reminded me of Snapchat's "Snapcode", where mine is:
And sure enough, when I clicked on the "People" icon at the bottom of the Messenger app, the first option on the top is "Scan Code":
Since I had learned about these codes via a tweet from Chris Messina, I pointed my phone at my laptop screen where his Messenger Code was visible:
As I got closer to the code, the Messenger app automagically recognized the code and put me into a message window with Chris:
I didn't chat with him as I didn't have a reason to do so and I don't recall us actually meeting. But I could ... it was this easy to get connected.
In a similar way to Snapchat, from the "Scan Code" window there is a symbol in the lower left corner that lets you access your phone's photos. So if you receive a Messenger Code via some other method (such as Twitter where people are already posting their codes using the #F8 hashtag) and save that image to your photos, you can access it from the "Scan Code" page and connect with the person.
From that same "Scan Code" page you can also tap "My Code" to see your code. Here's mine:
I can now share that Messenger Code out through the icon in the upper right and get it out into other social services (as I did on Twitter), or via text message, email, DropBox or anything else.
(Amusingly, while I could share the image out to Snapchat, the image is shared as square and since Snapchat uses full vertical images it cropped the image... meaning that the full Messenger Code would not be displayed and presumably would not work.)
So What?
At this point you may be saying "so what?" and wondering what value this really brings.
As I wrote about last year, messaging is all about "the directory dilemma", i.e.
People will only USE a communication application if the people they want to talk to are using the application.
It's all about having the most massive directory of users and growing that directory.
As Snapchat has demonstrated, the use of these "user codes" takes away the friction of figuring out how to connect with someone.
Over the past months a number of people I know have changed their Twitter and Facebook profile images to be their Snapcode. All I need to do, then, is point Snapchat on my phone toward their image and... ta da.. I can send them a connection request. No worry trying to look up their name... or figure out which of the many "Dan Yorks" I am if they are trying to connect to me.
Simple. Easy.
In many ways it's the proprietary version of QR codes... although focused on connecting two users rather than (as is often the case with a QR code) sending you to a web page or other site.
I expect we'll start seeing people change their Twitter profile photos to include their Facebook Messenger Code.
If people do, Facebook can steal the messaging from that rival platform. If you advertise your Messenger Code as the profile on another service, you are effectively saying "I prefer to get Facebook Messenger messages".
Take away the friction of connecting and let users advertise how to connect on your messaging platform.
If I were the organizer of an event, and I wanted to use FB Messenger as my primary messaging app, I could very easily see adding my Messenger Code to the event website, or even to printed flyers that might hang in a local coffee shop, library, gym, school or wherever...
Simple. Easy.
What About Brands? Facebook Pages?
I could see a huge benefit to brands to be able to publish these Messenger Codes, particularly with the expectation of "chat bots" being unveiled at F8 this week.
Again, from Facebook's point of view, this would keep the messaging within Facebook's walled garden, and continue to keep Facebook having the biggest directory of active users.
Tonight I couldn't discover anything similar in the Pages app or any other place. But you would think it would be coming... we'll have to stay tuned to F8 coverage this week to find out more.
What About Messaging Spam?
But if you publish your Messenger Code everywhere, what about spam?
Another good question... and since I published my Messenger Code on Twitter, perhaps I'll find out the answer over the next day or so! :-)
Perhaps Facebook will filter them all into the "Message Requests" that was very hard to find. I don't know! I have to think they will do something to ensure Messenger doesn't descend into the spam pit as email has.
How Else Can Messenger Codes Be Used?
We'll have to see what they tell us at the "F8 Developer Conference" this week... stay tuned!
What do you think about these Messenger Codes? Do you think it will help in connecting you with people? Will your promote your code? Or do you think it is all a waste of time? Let me know in the comments or on social media...
Mar 31
DNS-OARC 24 Streaming Live March 31 / April 1 from Buenos Aires
Today and tomorrow you have a great opportunity to listen to some of the newest research into the Domain Name System (DNS) operations and security through the live video stream of the 24th meeting of the DNS Operations Analysis and Research Center (DNS-OARC). You can watch live at:
https://www.youtube.com/c/DnsoarcNetPlus/live
and view the past recordings on the DNS-OARC YouTube channel. The DNS-OARC 24 agenda covers a wide range of topics related to the overall operations of DNS. Some of the sessions that Deploy360 readers may find of interest include:
- Thursday, March 31
- How we are developing a next generation DNS API for applications
- State of the “DNS privacy” project: running code
- QNAME minimisation in Unbound (DNS privacy)
- Friday, April 1
- Knot DNS Resolver
- Threshold-Cryptography Distributed HSM
- Review and analysis of attack traffic against A-root and J-root on November 30 and December 1, 2015
- ECDSA – Reviewed
- Rolling the Root Key
- Algorithm roll-over experiences
- Panel: DNSSEC algorithm flexibility
The last four sessions that I highlighted in bold all fit into the larger work of moving to use newer elliptic curve cryptographic algorithms within DNSSEC that I wrote about recently. As I mentioned in that article, I’ll be moderating this final panel tomorrow afternoon.
I would encourage people to tune in and watch the sessions. Do visit the DNS-OARC 24 timetable to find out the times when different sessions will be happening. All times are in Argentina time (ART) which is UTC-3.
And if you want to get started with DNSSEC yourself, please visit our Start here page to begin.
Image credit: a photo of the DNS-OARC 24 room I took this morning.
Mar 30
TDYR 298 – Heading To Buenos Aires for #IETF95 and more…
I am heading to Buenos Aires, Argentina, for the 95th meeting of the Internet Engineering Task Force (IETF) and several other meetings. In this episode I talk about what I will be doing there.
Mar 29
The Path Toward Increasing the Security of DNSSEC with Elliptic Curve Cryptography (Featured Blog)
How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way? Over the past few months we've been discussing these questions within the community of people implementing DNSSEC, with an aim of increasing both the security and performance of DNSSEC. More...
Mar 28
The Next Steps Toward Increasing The Security of DNSSEC with Elliptic Curve Cryptography
How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?
Over the past few months we’ve been discussing these questions within the community of people implementing DNSSEC, with an aim of increasing both the security and performance of DNSSEC. Ondřej Surý of CZ.NIC Labs has been leading the way both with writing Internet drafts (draft-ietf-curdle-dnskey-ed25519 and draft-ietf-curdle-dnskey-ed448) and also in helping to organize sessions at various events.
Here’s a brief view of where that discussion has and will be taking place:
- 9 March 2016 – a panel session at ICANN 55 DNSSEC Workshop in Marrakech, Morocco- (see below)
- 1 April 2016 – a panel session at DNS-OARC in Buenos Aires
- 5 April 2016 – a discussion of the drafts in the CURDLE Working Group at IETF 95
- 6/8 April 2016 – a discussion of another draft in the DNSOP Working Group to reduce usage of older DNSSEC crypto algorithms
- 23-27 May 2016 – a panel session at RIPE 72 in Copenhagen, Denmark
- 27 June 2016 – a proposed panel session at the ICANN 56 DNSSEC Workshop in Helsinki, Finland
Let me provide a quick overview of what happened at ICANN 55 and then explain a new Internet draft that came out of that experience.
ICANN 55 DNSSEC Workshop
At ICANN 55 in Marrakech, we had a panel that I moderated where we presented several different viewpoints about how we go about implementing new DNSSEC algorithms and what are the challenges. I started out with a presentation where I outlined some of the challenges in this set of slides:
Challenges To Deploying New DNSSEC Cryptographic Algorithms from Deploy360 Programme (Internet Society)
I was then followed by four panelists (links are to the slide decks three of the four panelists had):
- Geoff Huston, APNIC — ECDSA P-256 support in DNSSEC-validating Resolvers
- Jim Galvin, Afilias
- Ólafur Guðmundsson, CloudFlare — Adding New DNSSEC Algorithms: Reality Check
- Ondřej Surý, CZNIC — New Curves in DNSSEC
Geoff started out giving an overview of what APNIC’s research had found in the support of a current elliptic curve algorithm (ECDSA) in DNS resolvers (remembering that there are two sides to DNSSEC). Jim Galvin then provided a view of DNSSEC algorithms from a registry perspective. Olafur reported on the experience CloudFlare had rolling out ECDSA support and Ondřej wrapped up the session explaining the two new elliptic curve algorithms proposed for DNSSEC. There were a good number of questions asked and it was a healthy discussion.
Our Internet Draft on new deploying DNSSEC algorithms
After that ICANN 55 session, I went back and wrote up a summary of what we learned out of that discussion and then incorporate further input from Ondřej, Ólafur and Paul Wouters and turned that into a new Internet-draft:
As I said in the abstract:
As new cryptographic algorithms are developed for use in DNSSEC signing and validation, this document captures the steps needed for new algorithms to be deployed and enter general usage. The intent is to ensure a common understanding of the typical deployment process and potentially identify opportunities for improvement of operations.
We are looking forward to further discussion – and welcome any and all feedback on the document.
The DNS-OARC panel on Friday, April 1
Which leads to a mention of the next discussion happening on this Friday, April 1, at the DNS-OARC 24th meeting happening in Buenos Aires right before IETF 95. The very last session from 1700-1745 ART (UTC-3) will be on “DNSSEC algorithm flexibility” . I’ll be moderating the panel again and the focus this time will be on software implementations and what needs to be done there to support more encryption algorithms. Ondřej will be part of the panel along with Paul Wouters (Red Hat), Evan Hunt (ISC / BIND) and several others.
I’m told their will be a live stream of the DNS-OARC session and it should be accessible from the DNS-OARC Google+ page. I’ll update this post once I have an exact URL.
Our goal with all of this work is to lay out a solid path forward to bringing strong elliptic curve algorithms to DNSSEC – and then making that plan a reality. The end goal is an even more secure DNSSEC infrastructure that brings about an even more trusted DNS.
We’d welcome your comments and assistance with this – please do send us comments on the Internet Draft (email addresses at the end) or comment here or on social media about any of this. We need many different people helping move this forward!
P.S. If you are not yet using DNSSEC, please visit our Start Here page to begin!
Mar 28
Rough Guide to IETF 95: DNSSEC, DPRIVE, DANE and DNS Security
The most passionate discussions involving "DNS security" at IETF 95 in Buenos Aires may possibly take place not in the "traditional" DNS-related Working Groups, but rather over in the Using TLS in Applications (UTA) Working Group on Monday, April 4, 2016, at 14:00 ART where what looks like a vigorous discussion is shaping up about how to protect and secure email communication. Yes, email!
Dan York
Mar 27
Rough Guide to IETF 95: DNSSEC, DPRIVE, DANE and DNS Security
The most passionate discussions involving “DNS security” at IETF 95 in Buenos Aires may possibly take place not in the “traditional” DNS-related Working Groups, but rather over in the Using TLS in Applications (UTA) Working Group on Monday, April 4, 2016, at 14:00 ART where what looks like a vigorous discussion is shaping up about how to protect and secure email communication. Yes, email! On the UTA agenda there is not one but three different proposals for securing email – and all three include some discussion of DNSSEC and DANE (particularly after the publication of RFC 7672 in October about securing email with the DANE protocol). Based on the lengthy threads on the UTA mailing list, I expect a strong amount of discussion.
A second strong thread of activity will be around efforts to increase the security of DNSSEC through the use of elliptic curve cryptography. This will be discussed in both the DNSOP working group and also a new focused working group called CURDLE. It’s also the topic of a recent Internet-Draft I published with a number of others about the steps needed to implement elliptic curve cryptography.
The DPRIVE Working Group will also be meeting to continue its work on securing the connection between DNS clients and recursive resolvers. The DNSSD and TRANS groups will also be meeting and a new Birds-of-a-Feather (BOF) session on ARCING will also meet. The DANE Working Group will not be meeting in BA, but as mentioned above, there will be a good discussion related to DANE as part of the broader UTA discussions on Monday.
Beyond UTA, here are how some of the other groups are looking at IETF95…
DNS Operations (DNSOP)
The DNS Operations (DNSOP) Working Group meets twice: first for an hour on Wednesday (in the timeslot previously scheduled for DANE) and then again for two hours on Friday. Two pieces of DNSSEC work in the new business area of the DNSOP agenda: a draft from Warren Kumari about speeding up negative answers from NSEC records at the root of DNS; and then a draft from Paul Wouters and Ondrej Sury about requirements and usage guidance for DNSSEC cryptographic algorithms. This second draft is interesting because the intent is to phase out usage of older cryptographic algorithms. Beyond that, DNSOP typically winds up with discussions that affect the overall performance and operations of DNS that make for an interesting time.
DNS PRIVate Exchange (DPRIVE)
The DPRIVE Working Group will be meeting on Wednesday morning to continue the discussions about DNS over TLS and DNS over DTLS. All of this DPRIVE work is focused on securing the connection between DNS clients and the recursive resolvers that people use (such as those typically at an Internet Service Provider (ISP) or on the edge of a network) to add a layer of confidentiality. We see this as an important part of the overall encryption work being done by the IETF to protect against the pervasive monitoring that we’ve seen on the Internet. Mechanisms such as what DPRIVE is developing will raise the overall amount of trust in Internet-based communication.
CURves, Deprecating and a Little more Encryption (CURDLE)
The CURDLE Working Group potentially wins the award for biggest stretch of a name to fit an acronym… but on a serious level the group is focused on an extremely important area of work – increasing the cryptographic security of a number of common protocols, including DNSSEC. On the CURDLE agenda are two drafts from Ondrej Sury and Robert Edmonds that specify new algorithms for DNSSEC.
DNS Service Discovery (DNSSD)
We haven’t covered the DNS Service Discovery (DNSSD) Working Group too often in the past, but at IETF 95 the DNSSD agenda has two interesting drafts up for discussion: one is related to the overall threat model and the other about privacy extensions. This WG is looking at how you “discover” services on a network using DNS when that “network” is bigger than just your own local network. For instance, how do you discover a printer that might be at, say, your parents’ house? And of course, how do you do all that securely? DNSSEC is not directly part of these discussions, but they are part of the broader “DNS security” area of our interest.
Other Working Groups
The TRANS WG focused on “certificate transparency” (CT), a mechanism for tracking changes in TLS certificates, is meeting on Monday and has a draft out about the attack model and threats on CT. This isn’t exactly related to DNS, but we’ll pay attention because it is looking at the same “securing TLS for the Web” area that is applicable to DANE. We’ll also of course be monitoring the TLS WG (because of the connection to DANE), the Security Area open meeting and other similar sessions. There is also a BOF called “Alternative Resolution Contexts for Internet Naming (ARCING)” that doesn’t directly affect “DNS security”, per se, but is looking at the larger issue of “alternate” systems of name resolution on the Internet. For example, the naming resolution that happens within the Tor onion routing system. More info can be found on the BOF page and also in the ARCING mailing list archive.
It will be a busy week – but the outcomes of all these sessions should go far to make the DNS – and the overall Internet – more secure!
Please see the main Rough Guide to IETF 95 page to learn about more of what we are paying attention to in Buenos Aires.
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:
- http://www.internetsociety.org/deploy360/dnssec/
- http://www.internetsociety.org/deploy360/resources/dane/
Relevant Working Groups at IETF 95:
UTA (Using TLS in Applications) WG
Monday, 4 April 2016, 1400-1530 ART, Room Antlico C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/
TRANS (Public Notary Transparency) WG
Monday, 4 April 2016, 1550-1720 ART, Room Quebracho A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: http://tools.ietf.org/wg/trans/charters/
DNSSD (Extensions for Scalable Service Discovery) WG
Monday, 4 April 2016, 1550-1720 ART, Room Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/
CURDLE (CURves, Deprecating and a Little more Encryption) WG
Tuesday, 5 April 2016, 1620-1720 ART, Room Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/curdle/
Documents: https://datatracker.ietf.org/wg/curdle/
Charter: http://tools.ietf.org/wg/curdle/charters/
DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 6 April 2016, 1000-1230 ART, Room Atlantico C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/
DNSOP (DNS Operations) WG
Wednesday, 6 April 2016, 1620-1720 ART, Room Atlantico B
Friday, 8 April 2016, 1000-1200 ART, Room Buen Ayre C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/
Follow Us
There’s a lot going on in Buenos Aires, 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 https://www.internetsociety.org/tag/ietf95/.
The post Rough Guide to IETF 95: DNSSEC, DPRIVE, DANE and DNS Security appeared first on Internet Society.
