Archive

Category Archives for "Security"

Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy

It’s going to be a crazy busy week in London next week in the world of DNS security and privacy! As part of our Rough Guide to IETF 101, here’s a quick view on what’s happening in the world of DNS.  (See the full agenda online for everything else.)

IETF 101 Hackathon

As usual, there will be a good-sized “DNS team” at the IETF 101 Hackathon starting tomorrow. The IETF 101 Hackathon wiki outlines the work (scroll down to see it). Major security/privacy projects include:

  • Implementing some of the initial ideas for DNS privacy communication between DNS resolvers and authoritative servers.
  • Implementation and testing of the drafts related to DNS-over-HTTPS (from the new DOH working group).
  • Work on DANE authentication within systems using the DNS Privacy (DPRIVE) mechanisms.

Anyone is welcome to join us for part or all of that event.

Thursday Sponsor Lunch about DNSSEC Root Key Rollover

On Thursday, March 22, at 12:30 UTC, ICANN CTO David Conrad will speak on “Rolling the DNS Root Key Based on Input from Many ICANN Communities“. As the abstract notes, he’ll be talking about how ICANN got to where it is today with the Continue reading

Rough Guide to IETF 101: Privacy, Identity, and Encryption

It’s that time again! In this post of the Rough Guide to IETF 101, I’ll take a quick look at some of the identity, privacy, and encryption related activities at IETF this coming week. Below a few of the many relevant activities are highlighted, but there is much more going on so be sure to check out the full agenda online.

Encryption

Encryption continues to be a priority of the IETF as well as the security community at large. Related to encryption, there is the TLS working group developing the core specifications, several working groups addressing how to apply the work of the TLS working group to various applications, and the Crypto-Forum Research Group focusing on the details of the underlying cryptographic algorithms.

The Transport Layer Security (TLS) Working Group is a key IETF effort developing core security protocols for the Internet. The big news out of this working group is the IESG approval of the TLS 1.3 specification. There is still some way to go before final publication, but the end is in sight.

There will be two TLS sessions this week. The Monday session will focus primarily on the ongoing discussion of data center operator concerns Continue reading

ISOC’s Hot Topics at IETF 101

Tomorrow begins IETF 101 in London, United Kingdom, and it’s the third time that an IETF has been held in the country. Following on the heels of our Rough Guide to IETF 101 where we go in-depth about specific topics of interest, the ISOC Internet Technology Team is again highlighting the latest IPv6, DNSSEC, Securing BGP, TLS and IoT related developments as the week progresses.

Below are the sessions that we’ll be following in the coming week. Note this post was written in advance so please check the official IETF 101 agenda for any updates, room changes, or final details.

Monday, 18 March 2018

Tuesday, 19 March 2018

A Secure Supply Chain for Kubernetes, Part 2

Two weeks ago we shared how the upcoming release of Docker Enterprise Edition (Docker EE) is able to secure the software supply chain for Kubernetes; just as it does for Docker Swarm through a combination of scanning for vulnerabilities and implementing image promotion policies. In this blog, we’ll take a closer look at another part of this solution – Docker Content Trust and image signing.

When combined with granular Role Based Access Controls [RBAC] and the secure clustering features of Docker EE, organizations get a secure container platform solution that is ready for the enterprise.

Restricting Unverified Kubernetes Content

As discussed in Part 1 of this blog post, organizations typically have a “supply chain” for how applications progress from a developer’s laptop to production, whether that is on-premises or in the cloud. For larger organizations, the team that handles QA and testing is not always the same team that develops the applications. There may also be a separate team that handles staging and pre-production before an application is pushed to production. Since an application can pass through several teams before it gets deployed, it’s important for organizations to be able to validate the source of the application.

Docker Content Trust Continue reading

I Can’t Choose the Gear for You

One of my readers sent me a question along these lines after reading the anti-automation blog post:

Your blog post has me worried as we're currently reviewing offers for NGFW solution... I understand the need to keep the lid on the details rather than name and shame, but is it possible to get the details off the record?

I always believed in giving my readers enough information to solve their challenges on their own (you know, the Teach a man to fish idea).

Read more ...

Rough Guide to IETF 101: Internet of Things

The Internet of Things (IoT) is an increasingly hot buzzword around the Internet industry and the broader technology and innovation business arenas. We are often asked what the IETF is doing in relation to IoT and in this short Rough Guide to IETF 101 post I’d like to highlight some of the relevant sessions scheduled during the upcoming IETF 101 meeting in London. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance IoT page for more details about many of these topics. See also this recent article in the IETF Journal: Internet of Things: Standards and Guidance from the IETF.

The IETF Hackathon, held the weekend preceding the main IETF meeting (17-18 March), will include at least four projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki.

Continue reading

Deprecating TLS 1.0 and 1.1 on api.cloudflare.com

Deprecating TLS 1.0 and 1.1 on api.cloudflare.com

On June 4, Cloudflare will be dropping support for TLS 1.0 and 1.1 on api.cloudflare.com. Additionally, the dashboard will be moved from www.cloudflare.com/a to dash.cloudflare.com and will require a browser that supports TLS 1.2 or higher.

No changes will be made to customer traffic that is proxied through our network, though you may decide to enforce a minimum version for your own traffic. We will soon expose TLS analytics that indicate the percent of connections to your sites using TLS 1.0-1.3, and controls to set a specific minimum version. Currently, you may enforce version 1.2 or higher using the Require Modern TLS setting.

Prior to June 4, API calls made with TLS 1.0 or 1.1 will have warning messages inserted into responses and dashboard users will see a banner encouraging you to upgrade your browser. Additional details on these changes, and a complete schedule of planned events can be found in the timeline below.

Background

Transport Layer Security (TLS) is the protocol used on the web today to encrypt HTTPS connections. Version 1.0 was standardized almost 20 years ago as the successor to SSL Continue reading

Applied Networking Research Workshop (ANRW) Call for Papers Due 20 April

We’re excited to share news of the third edition of the Applied Networking Research Workshop (ANRW2018), which will take place in Montreal, Quebec, on Monday, July 16 at the venue of the Internet Engineering Task Force (IETF) 102 meeting. The workshop program already includes some great invited talks and the Call for Papers is open now, with a deadline of 20 April.

ANRW2018 will provide a forum for researchers, vendors, network operators and the Internet standards community to present and discuss emerging results in applied networking research. The workshop will also create a path for academics to transition research back into IETF standards and protocols, and for academics to find inspiration from topics and open problems addressed at the IETF. Accepted short papers will be published in the ACM Digital Library.

ANRW2018 particularly encourages the submission of results that could form the basis for future engineering work in the IETF, that could change operational Internet practices, that can help better specify Internet protocols, or that could influence further research and experimentation in the Internet Research Task Force (IRTF).

If you have some relevant work and would like to join us in Montreal for the workshop and maybe stick Continue reading

What John Oliver gets wrong about Bitcoin

John Oliver covered bitcoin/cryptocurrencies last night. I thought I'd describe a bunch of things he gets wrong.


How Bitcoin works

Nowhere in the show does it describe what Bitcoin is and how it works.

Discussions should always start with Satoshi Nakamoto's original paper. The thing Satoshi points out is that there is an important cost to normal transactions, namely, the entire legal system designed to protect you against fraud, such as the way you can reverse the transactions on your credit card if it gets stolen. The point of Bitcoin is that there is no way to reverse a charge. A transaction is done via cryptography: to transfer money to me, you decrypt it with your secret key and encrypt it with mine, handing ownership over to me with no third party involved that can reverse the transaction, and essentially no overhead.

All the rest of the stuff, like the decentralized blockchain and mining, is all about making that work.

Bitcoin crazies forget about the original genesis of Bitcoin. For example, they talk about adding features to stop fraud, reversing transactions, and having a central authority that manages that. This misses the point, because the existing electronic banking system already Continue reading

Rough Guide to IETF 101: Internet Infrastructure Resilience

In this post of the Internet Society Rough Guide to IETF 101, I’ll focus on important work the IETF is doing that helps improve security and resilience of the Internet infrastructure.

BGP

What happens if an IXP operator begins maintenance work on the switches without ensuring that BGP sessions between the peers have been shut down? A network disruption and outage. A draft now in the RFC editor queue, “Mitigating Negative Impact of Maintenance through BGP Session Culling”, provides guidance to IXP operators on how to avoid such situations by forcefully tearing down the BGP sessions (session culling) affected by the maintenance before the maintenance activities commence. This approach allows BGP speakers to pre-emptively converge onto alternative paths while the lower layer network’s forwarding plane remains fully operational.

Another draft also in the RFC editor queue, “Graceful BGP session shutdown”, addresses issues related to planned maintenance. The procedures described in this document can be applied to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link to be shut down.  These procedures trigger, in both Autonomous Systems (AS), rerouting to alternate paths if they exist within the Continue reading