Category: TLS for Applications

Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017

lifeguard-beach

Want to learn the latest about DNS privacy? About the latest research and techniques to protect the confidentiality of your DNS info and queries?

Starting at 8:55 am PST (UTC-8) today, there will be what looks to be an outstanding workshop on DNS Privacy streaming live out of the Network and Distributed System Security Symposium (NDSS) in San Diego, California.

View the agenda of the DNS Privacy Workshop to see all the excellent sessions.  You can then join live at:

https://isoc.zoom.us/j/935912695

(Other remote connection options can be found at the bottom of the agenda page.)

Note – this workshop is not about DNSSEC, which is a method to protect the integrity of DNS (to ensure DNS info is not modified in transit), but rather new work being done within the IETF to improve the confidentiality of DNS.

The sessions include:

  • How DNS Works in Tor & Its Anonymity Implications
  • DNS Privacy through Mixnets and Micropayments
  • Towards Secure Name Resolution on the Internet – GNS
  • Changing DNS Usage Profiles for Increased Privacy Protection
  • DNS-DNS: DNS-based De-NAT Scheme
  • Can NSEC5 be practical for DNSSEC deployments?
  • Privacy analysis of the DNS-based protocol for obtaining inclusion proof
  • Panel Discussion: The Tension between DNS Privacy and DNS Service Management
  • The Usability Challenge for DNS Privacy and End Users
  • An Empirical Comparison of DNS Padding Schemes
  • DNS Service Discovery Privacy
  • Trustworthy DNS Privacy Services
  • EIL: Dealing with the Privacy Problem of ECS
  • Panel Discussion: DNS-over-TLS Service Provision Challenges: Testing, Verification, internet.nl

If you are not there in person (as I will not be), you can also follow along on the #NDSS17 hashtag on Twitter. There will also be tweets coming out of:

Stéphane Bortzmeyer will also be attending (and speaking at) the workshop – and he is usually a prolific tweeter at @bortzmeyer.

The sessions will also be recorded for later viewing. I’m looking forward to seeing the activity coming out of this event spur further activity on making DNS even more secure and private.

Please do follow along remotely – and please do share this information with other people you think might be interested. Thank you!


Image from Unsplash – I thought about showing the wide beaches, but the reality is that the conference participants won’t really get a chance to visit them. I thought “Lifeguard” was appropriate, though, because lifeguards are all about protecting people and keeping things safe.

The post Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017 appeared first on Internet Society.

Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017

lifeguard-beach

Want to learn the latest about DNS privacy? About the latest research and techniques to protect the confidentiality of your DNS info and queries?

Starting at 8:55 am PST (UTC-8) today, there will be what looks to be an outstanding workshop on DNS Privacy streaming live out of the Network and Distributed System Security Symposium (NDSS) in San Diego, California.

View the agenda of the DNS Privacy Workshop to see all the excellent sessions.  You can then join live at:

https://isoc.zoom.us/j/935912695

(Other remote connection options can be found at the bottom of the agenda page.)

Note – this workshop is not about DNSSEC, which is a method to protect the integrity of DNS (to ensure DNS info is not modified in transit), but rather new work being done within the IETF to improve the confidentiality of DNS.

The sessions include:

  • How DNS Works in Tor & Its Anonymity Implications
  • DNS Privacy through Mixnets and Micropayments
  • Towards Secure Name Resolution on the Internet – GNS
  • Changing DNS Usage Profiles for Increased Privacy Protection
  • DNS-DNS: DNS-based De-NAT Scheme
  • Can NSEC5 be practical for DNSSEC deployments?
  • Privacy analysis of the DNS-based protocol for obtaining inclusion proof
  • Panel Discussion: The Tension between DNS Privacy and DNS Service Management
  • The Usability Challenge for DNS Privacy and End Users
  • An Empirical Comparison of DNS Padding Schemes
  • DNS Service Discovery Privacy
  • Trustworthy DNS Privacy Services
  • EIL: Dealing with the Privacy Problem of ECS
  • Panel Discussion: DNS-over-TLS Service Provision Challenges: Testing, Verification, internet.nl

If you are not there in person (as I will not be), you can also follow along on the #NDSS17 hashtag on Twitter. There will also be tweets coming out of:

Stéphane Bortzmeyer will also be attending (and speaking at) the workshop – and he is usually a prolific tweeter at @bortzmeyer.

The sessions will also be recorded for later viewing. I’m looking forward to seeing the activity coming out of this event spur further activity on making DNS even more secure and private.

Please do follow along remotely – and please do share this information with other people you think might be interested. Thank you!


Image from Unsplash – I thought about showing the wide beaches, but the reality is that the conference participants won’t really get a chance to visit them. I thought “Lifeguard” was appropriate, though, because lifeguards are all about protecting people and keeping things safe.

New RFC 7469 on Certificate Pinning – HTTP Public Key Pinning (HPKP)

TLS badgeA couple of weeks ago those of us interested in Internet security formally received a new tool in our toolbox to improve the overall security of the TLS infrastructure that we use for pretty much all secure communication across the Internet. RFC 7469, “Public Key Pinning Extension for HTTP” was published and is available at:

http://tools.ietf.org/html/rfc7469

I say “formally” because in practice what is more commonly known as “HPKP” or “PKP” has been implemented for some time now by Google Chrome and Mozilla Firefox (see ticket) as the Internet-Draft worked its way through the WEBSEC Working Group within the IETF on its way to becoming a formal RFC.

At a basic level, “certificate pinning” is a fairly simple concept: once you connect to a site and receive its TLS certificate (i.e. you switch to using HTTPS and have the “lock” icon in your browser), “pin” that certificate inside your application for a specified period of time and ONLY accept connections that use that exact TLS certificate.  This removes the possibility of an attacker succeeding with a Man-In-The-Middle (MITM) attack where the attacker can fool your browser into thinking you are connecting to the correct secure site.  (If you want a deeper dive, OWASP has a long description of certificate pinning.)

Certificate pinning is a concept that has been around for a while but this new HPKP header makes it easier for sites to implement.

RFC 7469’s abstract doesn’t put it quite so simply as I did above, but you get the idea:

This document defines a new HTTP header that allows web host operators to instruct user agents to remember (“pin”) the hosts’ cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.

Now in practice it turns out that pinning the exact TLS certificate can cause operational problems in some website configurations and so the specification allows for the pinning of the key of the entity that issues the TLS certificates for your site, such as a certificate authority (CA).  This allows you, for instance, to specify that a browser should only accept TLS certificates from a specific CA.  This reduces the risk of a MITM attack where an attacker uses a TLS cert from a different CA who they were able to get to issue the bogus cert.

This new RFC 7469 dives into all the details of HPKP, but if you want a higher level view, Joseph Bonneau gave a talk in March 2015 at IETF 92 in Dallas about HPKP and its companion, HTTP Strict Transport Security (HSTS – RFC 6797). The slides are available:

cert-pinning-saag-ietf92and you can listen to the presentation starting at about 24:30 in the recording of the SAAG session.

Certificate pinning is a great tool that we have now, although it does have a few challenges to be aware of:

  • Trust-On-First-Use (TOFU) – Certificate pinning relies on you connecting to the correct server on the first connection in order to get the TLS cert that you are now going to pin in the browser.   As noted in the RFC 7469 Introduction, the issue is that if you were to connect to an attacker’s site first you could in fact wind up pinning the false certificate and thereby being blocked out of connecting to the correct site until the time of the pin expires (what is called in the spec “max-age”).
  • Blocking a site due to certificate changes  – If you need to change a TLS cert, or if a TLS cert should be compromised or a private key is lost, you could potentially wind up in a situation where people using browsers that perform cert pinning would not be able to get to your site.  This could happen if you pinned to an exact cert and had to change the cert, or if you pinned to a CA and then switched to a new CA, and in either case were unable to provide enough notice to manage the migration. The Security Considerations section of RFC 7469 discusses this issue.

On the TOFU issue, one way to deal with having to trust the site on first use is to “pre-load” the certificate to be pinned into the web browser or other application.  This is being done by both Chrome and Firefox (see Mozilla’s list).  The only concern here is that if you need to change the certificate in the pre-loaded list, you need to wait for an update to the browser to be available (and for users to install that update).

In various conversations I’ve suggested DNSSEC could help here because if the local system performed DNSSEC validation on a signed domain, the browser would then have a high level of assurance that it was connecting to the correct IP address where it could then receive a HPKP header with the correct TLS cert to be pinned.  So DNSSEC could help bootstrap the pinning process and get around the TOFU concern.

Whenever I’ve raised this point, the response has typically been that if you have DNSSEC validation available you could simply use DANE to ensure you are using the correct TLS certificate.  This is true, and I’d like to hope we’ll someday get there, but: 1) DANE requires the creation and usage of TLSA records, which is one more step people have to take; and 2) web browsers don’t have full support of DANE yet (although plugins are available).  In the meantime, I still see DNSSEC as a powerful way to help with ensuring cert pinning works correctly.

Regardless, the key point is that RFC 7469 is now out there and certificate pinning via the HPKP header is now possible.  It’s another tool we have and one that anyone interested in TLS security should definitely understand.

I’d love to hear your comments on this – please do feel free to leave them here.  Tell me why cert pinning is great… tell me why it’s not.  Tell me I’m wrong (or right!).  Please do note that we do moderate comments because of spam but we approve basically very comment that isn’t abusive or spam.

Internet.nl Provides An Easy Way To Test Your IPv6, DNSSEC and TLS

“Is Your Internet Up-To-Date?” Does your existing Internet connection work with IPv6 and DNSSEC? Do your web sites support IPv6, DNSSEC and TLS?  Is there a quick way to find out?

Earlier this month a new site, Internet.nl, was launched to make this all easy for anyone to test.  All you do is visit the site at en.internet.nl (also available in Dutch) and just follow the very easy links:

Internet.nl web siteAll you do is click “Test my internet connection” to find out if your current connection supports IPv6 and DNSSEC.  Enter any website address to test whether that site supports IPv6, DNSSEC and TLS.  And enter any email address to find out if it supports IPv6, DNSSEC and DKIM/SPF/DMARC.

Here was the response I received for one of my email accounts:

Internet.nl email test

You then have a link you can follow to get more details.

While there are obviously more detailed tests that can be performed, this site does a nice job giving a high level view of whether your connections are protected.  I also like the fact that it uses “regular” language to explain why someone should care about these tests, rather than using the technical acronyms.

The site is great to have out there and we’ll be adding it to our list of DNSSEC tools and other places within Deploy360.

Congratulations to the various organizations behind Internet.nl on the launch!  May this new site help many more people learn what they need to do to bring their Internet connections and sites up-to-date!

P.S. Please also read Olaf Kolkman’s post providing another perspective on the launch. And yes, both the Internet Society and our Internet Society Netherlands Chapter were involved with the launch.  If you would like to get started with IPv6, DNSSEC or TLS, please visit our Start Here page to begin!

 

 

Deploy360@IETF92, Day 4: More IPv6 Operations, TLS, and much Security

IETF 92 - Kathleen MoriartyThis  fourth day of IETF 92 has a heavy focus on security for us on the Deploy360 team.  While the day starts with the second of two IPv6 Operations (v6OPS) working group sessions, the rest of the day is pretty much all about security, security, security!

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

In the 0900-1130 CDT block this morning, the second IPv6 Operations (v6OPS) sessions continues with their busy agenda in the Gold Room. Here are today’s topics:

A number of those should generate good discussion.

Meanwhile, over in the Oak Room, the TLS Working Group will be discussing improvements to this incredibly critical protocol that we are using to encrypt so many different communications over the Internet.  As my colleague Karen O’Donahue wrote:

The tls (Transport Layer Security) working group is actively working on an update to the TLS protocol. They recently conducted an interim meeting in Seattle, WA, on 10-11 March 2015. Agenda items for IETF 92 include backwards compatibility, rekeying, and client authentication.

After lunch the 1300-1500 CDT block has the Security Area Open Meeting in the International Room. The current agenda is this:

  • Joe Bonneau/HSTS and HPKP in practice (30 mins)
  • Adam Langley/QUIC (15 mins)
  • Jan Včelák/NSEC5 (10 mins)
  • Ladar Levinson/Darkmail (20 mins)
  • Paul Wouters/Opportunistic IPsec update (1 minute)
  • Eric Rescorla/Secure Conferencing (5 mins)

Several of these presentations tie directly into the work we are doing here.  The HSTS/HPKP is “certificate pinning” and very relevant to TLS, as is the QUIC presentation.  The NSEC5 is a new proposal for DNSSEC that, judging by the mailing list traffic, should get strong debate.

The 1520-1720 CDT block doesn’t contain any of the working groups we usually track, but there will be both a Routing Area Open Meeting as well as an Operations Area Open Meeting.

In the final 1740-1840 CDT block the Operational Security (OPSec) Working Group will be meeting in the Far East Room with a number of IPv6 and routing issues on their agenda.

Bits-and-Bites

The day will end with the Bits-and-Bites reception from 1900-2100 CDT  where attendees can get food and drink and also see various exhibits from sponsors and other organizations.  As I wrote in my Rough Guide post:

 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.

I understand there may be some cool demos from other vendors and groups as well. (I’m looking forward to seeing photos!)

For some more background, please read these Rough Guide posts from Andrei, Phil and Karen:


Relevant Working Groups:


For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo from Jari Arkko of Kathleen Moriarty and Lisandro Granville at the IETF 92 Administrative Plenary

Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW)

Jen Linkova at IETF 92Today’s third day of IETF 92 turns out to be a quieter one for the topics we cover here on Deploy360.  The big activity will be in the first of two IPv6 Operations (v6OPS) working group sessions.  There will also be a reboot of the SUNSET4 working group and what should be an interesting discussion about “route leaks” in the GROW working group.  Here’s what our day looks like…

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

In the 0900-1130 CDT block this morning, we’re not actively tracking any of the listed working groups as they don’t tie directly into our Deploy360 topics. However the BESS session about BGP-enabled services could be interesting, as could the SPUD BOF looking at what are barriers to implementing new transport protocols on the Internet (more info in the SPUD overview presentation).

After lunch from 1300-1500 CDT in the International Room will be the first of two IPv6 Operations (v6OPS) sessions (the second being tomorrow) with a packed agenda looking at design choices for IPv6 networks, IPv6 deployment case studies / lessons learned and more.  As IPv6 deployment continues to grow month over month, incorporating feedback from that deployment process back into the standards process is an essential part of ensuring continued growth.

In the 1520-1620 CDT block over in the Gold Room, the IPv6 discussion will continue in the SUNSET4 working group that is chartered to document and explore how well things will work in an IPv6-only environment when IPv4 is no longer available (i.e. IPv4 has “sunsetted”).  As noted in the SUNSET4 agenda, the working group has had a loss of momentum and will be looking today at how to restart efforts to move work items along.

Simultaneously over in the Parisian Room the Global Routing Operations (GROW) working group will be looking at how to improve the operations of the Internet’s global routing infrastructure.  As my colleague Andrei Robachevsky wrote in his Rough Guide to IETF 92 post:

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/.

This issue of “route leaks” is one that comes up repeatedly and is causing problems on the global Internet. For instance, yesterday DynResearch tweeted about a route hijack of Google’s site by Belarus Telecom – now I don’t know if that was an actual “route leak”, but it’s the kind of routing issue we do see often on the Internet… which is why this class of issues needs to be identified and solutions proposed.

And just because we really want to be in three places at once… over in the Venetian Room during this same 1520-1620 time block will be the “Automated Certificate Management Environment (ACME)” BOF looking at ways to automate management of TLS certificates. As the agenda indicates, the session is primarily about discussing draft-barnes-acme and the efforts being undertaken as part of the Let’s Encrypt initiative.  The ideas are intriguing and proposals that help automate the security of the Internet can certainly help reduce the friction for regular users.

After all of that is over we’ll be joining in for the Operations and Administrative Plenary from 1640-1910 CDT.  You can view a live video stream of the plenary at http://www.ietf.org/live/    And then… we’ll be getting ready for Day 4…

For some more background, please read these Rough Guide posts from Andrei, Phil and I:


Relevant Working Groups:


For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Olaf Kolkman of Jen Linkova at IETF 92. Part of a larger set of IETF 92 photos Olaf has published.

Deploy360@IETF92, Day 1: SIDR, 6MAN, DPRIVE and UTA

ROW workshop at IETF 92On this first day of IETF 92 in Dallas, our attention as the Deploy360 team is on securing the Internet’s routing infrastructure, improving the IPv6 protocol and securing the privacy and confidentiality of DNS queries.


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


The day begins with two sessions in the 0900-1130 CDT block.  In the Parisian room the SIDR working group will be working through a good number of Internet Drafts relating to both RPKI and BGPSEC.  Both of these are some of the tools we view as important in securing BPG and making the routing infrastructure more resilient and secure.  Our colleague Andrei Robachevsky dived into more detail in his recent Rough Guide post.  Also on the agenda is the release of results about a survey about RPKI and DNSSEC deployment undertaken last fall by researchers at the Freie Universitaet Berlin which could be interesting to learn about.

At the same time over in the International Room, the 6MAN working group has a long agenda relating to various points discovered during the ongoing deployment of IPv6.   Given that we keep seeing solid growth each month in IPv6 deployment measurements, it’s not surprising that we’d see documents brought forward identifying ways in which the IPv6 protocol needs to evolve.  This is great to see and will only help the ongoing deployment.

Moving on to the 1300-1500 CDT session block, there are two working groups that are not ones we primarily follow, but are still related to the overall themes here on the site:

  • the TRANS working group is looking to standardize “Certificate Transparency” (CT), a mechanism to add a layer of checking to TLS certificates;
  • the DNSSD working group continues its work to standardize DNS-based service discovery beyond a simple single network.  Our interest here is really that this kind of service discovery does need to be secured in some manner.

In the 1520-1650 CDT session block, a big focus for us will be the newer DPRIVE working group that is looking into mechanisms to make DNS queries more secure and confidential.  As I wrote in my Rough Guide post, a concern is to make it harder for pervasive monitoring to occur and be able to track what a user is doing through DNS queries.  DPRIVE has a full agenda, and knowing some of the personalities I expect the debate to be passionate.

Simultaneously, over in the Parisian Room, the Using TLS In Applications (UTA) working group will continue it’s work to make it easier for developers to add TLS to applications.  The UTA agenda at IETF 92 shows a focus on one mechanism for email privacy.

After all of this, we’ll be heading to the Technical Plenary from 1710-1910 CDT where the technical topic is on “Smart Object Architecture” which sounds interesting.  You can watch a live video stream of the Technical Plenary at http://www.ietf.org/live/

For some more background, please read these Rough Guide posts from Andrei, Phil, Karen and myself:


Relevant Working Groups:


For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Chris Grundemann of the ROW workshop on the Sunday prior to IETF 92.

Deploy360@IETF92, Day 1: SIDR, 6MAN, DPRIVE and UTA

ROW workshop at IETF 92On this first day of IETF 92 in Dallas, our attention as the Deploy360 team is on securing the Internet’s routing infrastructure, improving the IPv6 protocol and securing the privacy and confidentiality of DNS queries.


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


The day begins with two sessions in the 0900-1130 CDT block.  In the Parisian room the SIDR working group will be working through a good number of Internet Drafts relating to both RPKI and BGPSEC.  Both of these are some of the tools we view as important in securing BPG and making the routing infrastructure more resilient and secure.  Our colleague Andrei Robachevsky dived into more detail in his recent Rough Guide post.  Also on the agenda is the release of results about a survey about RPKI and DNSSEC deployment undertaken last fall by researchers at the Freie Universitaet Berlin which could be interesting to learn about.

At the same time over in the International Room, the 6MAN working group has a long agenda relating to various points discovered during the ongoing deployment of IPv6.   Given that we keep seeing solid growth each month in IPv6 deployment measurements, it’s not surprising that we’d see documents brought forward identifying ways in which the IPv6 protocol needs to evolve.  This is great to see and will only help the ongoing deployment.

Moving on to the 1300-1500 CDT session block, there are two working groups that are not ones we primarily follow, but are still related to the overall themes here on the site:

  • the TRANS working group is looking to standardize “Certificate Transparency” (CT), a mechanism to add a layer of checking to TLS certificates;
  • the DNSSD working group continues its work to standardize DNS-based service discovery beyond a simple single network.  Our interest here is really that this kind of service discovery does need to be secured in some manner.

In the 1520-1650 CDT session block, a big focus for us will be the newer DPRIVE working group that is looking into mechanisms to make DNS queries more secure and confidential.  As I wrote in my Rough Guide post, a concern is to make it harder for pervasive monitoring to occur and be able to track what a user is doing through DNS queries.  DPRIVE has a full agenda, and knowing some of the personalities I expect the debate to be passionate.

Simultaneously, over in the Parisian Room, the Using TLS In Applications (UTA) working group will continue it’s work to make it easier for developers to add TLS to applications.  The UTA agenda at IETF 92 shows a focus on one mechanism for email privacy.

After all of this, we’ll be heading to the Technical Plenary from 1710-1910 CDT where the technical topic is on “Smart Object Architecture” which sounds interesting.  You can watch a live video stream of the Technical Plenary at http://www.ietf.org/live/

For some more background, please read these Rough Guide posts from Andrei, Phil, Karen and myself:


Relevant Working Groups:


For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Chris Grundemann of the ROW workshop on the Sunday prior to IETF 92.

The post Deploy360@IETF92, Day 1: SIDR, 6MAN, DPRIVE and UTA appeared first on Internet Society.

At IETF92 Next Week, Much Happening With IPv6, DNSSEC, DANE, TLS and more…

Dallas skylineNext week is IETF 92 in Dallas, Texas, and there will be a great amount of activity happening with the topics we cover here on Deploy360: IPv6, DNSSEC (and DANE), TLS, anti-spoofing and securing BGP.  As part of the Rough Guide to IETF 92, several of us have written posts outlining what’s happening in the various topic areas:

In each of those posts you’ll find a summary of what’s happening and a list of the relevant working groups and the associated links about how to learn more.  More information about IETF 92 in general can be found on the main Rough Guide to IETF 92 page at:

https://www.internetsociety.org/rough-guide-ietf92

Beyond all of that, Chris Grundemann will also be talking about our “Operators and the IETF” work and discussing Best Current Operational Practices (BCOP) with people as well.

If you can’t get to Dallas next week, you can attend remotely!  Just visit the IETF 92 remote participation page or check out http://www.ietf.org/live/ for more options.

To that end, as a bit of a change both Megan Kruse and I (Dan York) will be participating in this IETF 92 remotely.  It’s very strange to not be attending an IETF meeting in person, but different circumstances have made it not possible for both of us.  Jan Žorž will also be remote having just returned from v6 World Congress in Paris and about to head off to another event.   Chris Grundemann will be there on site in Dallas, though, and so if you have any questions about Deploy360 activities or want to get more involved, please contact Chris!

We’re looking forward to the usual crazy busy blur of a week that is an IETF meeting… and we’re looking forward to learning what else we can do to help accelerate the deployment of these key Internet technologies to make the Internet work better, faster and be more secure!

 

TLS-O-MATIC Now Available To Test TLS In Applications

TLS-O-MATIC logoDo you want to test how well your application supports TLS over HTTP?  If so, you can now head over to:

http://www.tls-o-matic.com/

and run your application through a whole series of self-tests.

As he explains in a blog post announcing TLS-O-MATIC, Olle Johansson launched the site as a public service with 15 tests for the HTTPS protocol.

I’ve known Olle for many years through his work seeking to add security to various voice-over-IP (VoIP) services and protocols – and in recent years he has been focused around the idea of getting more encryption deployed.  He typically uses the “#MoreCrypto” hashtag on Twitter and other services – and we wrote about his #MoreCrypto 2.0 slide deck he released back in December 2014.

Some of the tests included in TLS-O-MATIC are:

  • Bad hostname
  • One cert, multiple names
  • Wildcard certificate
  • Not yet valid certificate
  • Expired certificate
  • Unknown CA
  • Client certificate
  • Weak certificate
  • Intermediate certificate
  • Chain of trust
  • A huge certificate
  • A strong key
  • Wrong usage bits
  • Server Name Indication
  • International DNS

We applaud Olle for making this test site available and hope it will be helpful to application developers to test if their applications fully support TLS.  If you are an application developer, please do visit the site and give Olle any feedback you may have as you use it.

Sites like this can help make encryption available everywhere and bring about a stronger and more secure Internet!