Categories
Domain Name System Security Extensions (DNSSEC) IPv6 Open Standards Everywhere Transport Layer Security (TLS)

Listen to the Hedge Podcast 39 to Learn about the Open Standards Everywhere Project

What is our Open Standards Everywhere (OSE) project all about? How did it get started? What are the project goals? What are some of the challenges web server operators face? How can we work together to make web servers more secure and available?

Recently Russ White and his team interviewed me on The Hedge Podcast Episode 39 to discuss all these questions and much more. I’ve known Russ for a good number of years and it was fun to talk with him and his co-hosts Eyvonne Sharp and Tom Ammon about all things related to the OSE project. I hope you enjoy listening to the episode as much as we enjoyed having the conversation!

Listen now

I would encourage you to listen to some of the other Hedge podcast episodes, too, as they have some great content. A few I personally enjoyed included: episode 37 about DNS privacy; episode 31 about network operator groups (NOGs); and episode 30 with Ethan Banks from the Packet Pushers Network about why understanding the fundamentals of networking is so important.

Thank you to Russ, Eyvonne, and Tom for having me on the show!

Want to be more involved with the Open Standards Everywhere project?

Thank you for your help in getting open standards deployed everywhere!

Categories
Building Trust Deploy360 Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 4: Trusted Systems, IoT & IPv6

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Thursday actually represents the last day of the meeting this time, although there’s still several sessions to draw attention to.

SUIT is meeting first thing at 09.00 UTC+9. This is considering how the firmware of IoT devices can securely updated, and the architecture and information models for this will be discussed. There are three other drafts relating to manifest formats that are the meta-data describing the firmware images.


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


DMM is the first of the afternoon sessions at 13.50 UTC+7, and there are several IPv6-related drafts under consideration. Proxy Mobile IPv6 extensions for Distributed Mobility Management proposes a solution whereby mobility sessions are anchored at the last IP hop router, whilst Segment Routing IPv6 for Mobile User Plane defines segment routing behaviour and applicability to the mobile user plane behaviour and defines the functions for that. There’s also three updated drafts on 5G implementations which may interest some.

To round off the week, there’s a choice of two sessions starting at 16.10 UTC+7.

ACME will be focusing on the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates. It will also consider how ACME can support TLS certificates for end-users.

Alternatively, 6TiSCH will be focusing on the specification for a combining a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH). The 6top protocol that enables distributed scheduling is now heading for publication as an RFC, and there are also updates to the description of a scheduling function that defines the behavior of a node when joining a network and to define a security framework for joining a 6TiSCH network. If there’s time, a method to protect network nodes against a selective jamming attack will be discussed.

With that, IETF 103 comes to a close and we say Sà-wàd-dee to Bangkok. Many thanks for reading along this week… please do read our other IETF 103-related posts … and we’ll see you at IETF 104 which is being on 23-29 March 2019 in Prague, Czech Republic.

Relevant Working Groups

Categories
Deploy360 Events IETF Transport Layer Security (TLS)

IETF 103, Day 3: DNS Privacy, TLS & IoT

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Wednesday is a relatively light day in this respect, although there’s some pretty important matters being discussed today.

DPRIVE kicks off the day at 09.00 UTC+9, and will mostly be discussing user perspectives with respect to the recently introduced implementations of DNS-over-TLS and DNS-over-HTTPS, as well as the issues of DNS privacy between resolvers and authoritative servers. There’s also a new draft up for discussion on DNS-over-TLS for insecure delegations that describe an alternative authentication mechanism without need for DNSSEC support.


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


TLS holds its second session of the week immediately after lunch at 12.20 UTC+7. This will carry-on where it left off on Monday, although will be discussing a DANE Record and DNSSEC Authentication Chain Extension for TLS. The intention is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups.

Then at 13.50 UTC+7, Homenet will be focusing on Homenet Naming and Service Discovery Architecture. There’s also an agenda item for general security questions, and a demonstration of SecureHomeGateway, before moving into discussions on re-chartering the group.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 1: IPv6, TLS, DNS Privacy & Other Crypto

The Working Group sessions start tomorrow at IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Only four days have been scheduled for the working groups this time around, which means there’s a lot of pack into each day; with Monday being no exception.

V6OPS is a key group and will be meeting on Monday morning starting at 09.00 UTC+7. It’s published four RFCs since its last meeting, including Happy Eyeballs v2, and this time will kick-off with a presentation on the CERNET2 network which is an IPv6-only research and education in China.

There’s also four drafts to be discussed, including three new ones. IPv6-Ready DNS/DNSSSEC Infrastructure recommends how DNS64 should be deployed as it modifies DNS records which in some circumstances can break DNSSEC. IPv6 Address Assignment to End-Sites obsoletes RFC 6177 with best current operational practice from RIPE-690 that makes recommendations on IPv6 prefix assignments, and reiterates that assignment policy and guidelines belong to the RIR community. Pros and Cons of IPv6 Transition Technologies for IPv4aaS discusses different use case scenarios for the five most prominent IPv4-as-a-service (IPv4aaS) transitional technologies, whilst NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks is an updated draft that describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network.


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


Running in parallel on Monday morning is ROLL which focuses on IPv6 routing issues for low-power and lossy networks. This will be discussing an update ton the ROLL-BIER design that extends RPL to support routing based on Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. There are also seven other drafts up for discussion, all related to RPL enhancements.

CFRG will be held during the late morning at 11.20 UTC+7. The group has yet to publish the agenda, but there’s a number of currently active drafts covering issues that include Public Key ExchangeThe Transition from Classical to Post-Quantum Cryptography, Randomness Improvements for Security ProtocolsRe-keying Mechanisms for Symmetric Keys, and Hash-Based Signatures.

There’s a choice of two sessions after lunch, starting at 13.50 UTC+7.

TLS holds the first of its two sessions (the second is on Wednesday afternoon) and has a number of important drafts up for discussion including the proposed DTLS 1.3 specification, and Connection Identifiers for DTLS, to avoid the need for additional handshaking upon NAT rebinding. There is also a proposal to deprecate TLS 1.0 and 1.1 as these versions lack support for current and recommended cipher suites.

Other drafts cover TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates, a TLS 1.3 extension that allows a server to authenticate with a certificate while also providing a pre-shared key (PSK) as an input, and definition of universal PSKs for TLS that use an extra key derivation step to reuse the same secret for all TLS 1.3 KDF hashes. In addition, a revised working group charter has been proposed.

DNSOP meets at the same time, and there’s a couple of interesting drafts worth mentioning. One outlines how run a root server instance on the same server as a recursive resolver in order to decrease access time, and another specifies a way of resolvers telling clients what its associated DNS-over-HTTPS (DoH) servers are.

6LO concludes the day at 16.10 UTC+7. This will be discussing drafts to update RFC 6775 to support registration extensions for simplifying these operations in 6LoWPAN routers, to update Address Protected Neighbor Discovery for Low-power and Lossy Networks, to update RFC 4944 with a simple protocol to recover packet fragments over a mesh network, as well preparing the IPv6 Backbone Router draft for a Working Group Last Call. The session will be rounded-off with a performance report on fragment forwarding and recovery.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Categories
Deploy360 Improving Technical Security Transport Layer Security (TLS)

Deploying TLS 1.3

Last week saw the formal publication of the TLS 1.3 specification as RFC 8446. It’s been a long time coming – in fact it’s exactly 10 years since TLS 1.2 was published back in 2008 – but represents a substantial step forward in making the Internet a more secure and trusted place.

What is TLS and why is it needed?

Transport Layer Security (TLS) is widely used to encrypt data transmitted between Internet hosts, with the most popular use being for secure web browser connections (adding the ‘S’ to HTTP). It is also commonly (although less visibly) used to encrypt data sent to and from mail servers (using STARTTLS with SMTP and IMAP/POP etc..), but can be used in conjunction with many other Internet protocols (e.g. DNS-over-TLS, FTPS) where secure connections are required. For more information about how TLS works and why you should use it, please see our TLS Basics guide.

TLS is often used interchangeably with SSL (Secure Socket Layers) which was developed by Netscape and predates it as an IETF Standard, but many Certification Authorities (CAs) still market the X.509 certificates used by TLS as ‘SSL certificates’ due to their familiarity with users. It should be noted though, that all versions of the SSL protocol are now obsolete whilst TLS 1.0 is deprecated and should not be used.

How is TLS 1.3 improving things?

TLS 1.3 offers a number of technical advantages such as a simplified handshake to establish secure connections, and allow clients to more quickly resume sessions with servers. This should reduce setup latency and the number of failed connections on poor links that is often used as a justification for maintaining HTTP-only connections.

Just as importantly, it also removes support for several outdated and insecure encryption and hashing algorithms that are currently permitted (although no longer recommended) to be used with earlier versions of TLS, including SHA-1, MD5, DES, 3DES and AES-CBC, whilst adding support for newer cipher suites. Other enhancements include more encrypted elements of the handshake (e.g. the exchange of certificate information is now encrypted) to reduce hints to potential eavesdroppers, as well as improvements to forward secrecy when using particular key exchange modes so that communications at a given moment in time should remain secure even if the algorithms used to encrypt them are compromised in the future.

How can I use TLS 1.3?

So we’ve established that TLS 1.3 is a good thing for the Internet. but how can people actually take advantage of it? Of course, both the client and server need to have the ability to support TLS 1.3 to take advantage of the improvements, but the good news is that developers, vendors and service providers have been actively working to implement it for some time now, and it’s already supported by a number of applications.

Starting with web browsers, Google Chrome (including the Android version) from version 67 onwards, and Mozilla Firefox from version 61 onwards, already have support for TLS 1.3 by default. The latest version (54) of Opera also supports it, although it needs to be specifically enabled.

Apple has already implemented draft support for TLS 1.3 in both MacOS 10.13 and iOS 11, although this also needs to be specifically enabled.

With respect to server-side applications, many of these utilise TLS libraries and several of the more popular implementations including OpenSSL 1.1.1, GnuTLS 3.5.x, Google’s Boring SSL and Facebook’s Fizz are already supporting TLS 1.3. This should allow the protocol to quickly and easily be added to many widely used server applications, and indeed a number of Internet services including Google, Facebook, Akamai and Cloudflare are already supporting TLS 1.3 from compatible clients.

Microsoft does not yet support TLS 1.3 on any of its operating systems or in the Edge and Internet Explorer browsers, preferring to wait until the specification was finalised. It should be noted that early implementations of TLS 1.3 have been based on various versions of the specification (of which there were 28 in all), so a shakeout period will be required to bring implementations up to full standard, but this is likely to be short given the significance and importance of this protocol.

So what can possibly go wrong?

Well it’s not really a problem with TLS 1.3 per se, but whilst it has a mechanism to negotiate TLS 1.2 connections to those devices that can only support that protocol, there are a significant number of older applications that can only support earlier versions of TLS. As use of TLS 1.3 becomes more widespread and secure connections become expected, many devices and applications that cannot be upgraded may no longer be usable. However, the question that must be asked whether it’s advantageous or reasonable to keep supporting older protocols (e.g. TLS 1.0 and 1.1) when they become obsolete and potentially insecure?

The 0-RTT feature that allows data to be sent earlier when resuming secure connections to enable performance comparable with unencrypted handshaking, has been identified as having a potential weakness with respect to replay attacks (see Section 8 of RFC 8446). Nevertheless, replay attacks can happen with earlier versions of the TLS as well, and applications already need to implement specific restrictions on the scope of requests. 0-RTT can also be optionally turned off, or similarly limited in scope if this is a concern for particular types of application, and some guidelines for this can be found in RFC 8446.

Last but not least, many organisations implement middle box solutions to inspect and monitor traffic that is traversing their networks, particularly organisation have have strong regulatory and compliance requirements, This may be used identifying unauthorised or malicious communications, malware, or for monitoring self-signed or fake certificates for example, but as TLS 1.3 changes the handshake behaviour and encrypts certain parts of this (e.g. the certificate information exchange), this may affect middlebox functionality, downgrade TLS connections, or even prevent connections being made entirely.

The issue was identified during testing of early implementations of TLS 1.3, and changes made to allow certain features of the TLS 1.2 handshake to be replicated even though these are not actually necessary for the functioning of the new protocol. In addition, it’s still possible to implement other workarounds such as terminating all connections at the middlebox or distributing custom root certificates that allow decryption of the traffic, with the caveat there are resource and administrative practicalities to consider.

It should be appreciated though, that TLS 1.3 has been introduced to address some of the potential and actual vulnerabilities of earlier versions of the protocol such as the Triple Handshake, BEAST, FREAK and Logjam attacks. Whilst TLS 1.2 is not inherently a poor or even insecure protocol, it does require careful configuration to ensure obsolete cipher suites with identified vulnerabilities are not used in conjunction with it. TLS 1.3 removes the need to make these decisions, and brings significant performance improvements which should ensure there are no longer any reasons to be using unencrypted connections in future.

What You can do!

TLS 1.3 is being deployed now in browsers and many other applications, and in many cases you can already use it by selecting a browser that supports it. We also encourage you ask your IT teams, server administrators and developers to ensure that your sites and services support it, so we can collectively build a more secure Internet!

The Internet Society supports making encryption the new norm on the Internet, and our Deploy360 programme is developing resources on how to implement TLS in different applications.

Further Information

Categories
Deploy360 Transport Layer Security (TLS)

DNS privacy in new Android 9

I recently enrolled in the Android developer preview programme and got hold of the Android P (9 beta) OTA image for my Nokia 7 Plus phone, and while discovering what’s new, I found a new advanced option under network settings called ‘Private DNS’ that got my attention. This led to me finding an article from Erik Kline describing this new feature in Android 9, which to my surprise supports DNS-over-TLS (RFC 7858).

Last year we wrote about the experiments in the Go6lab with DNS-over-TLS where we set up a recursive DNS resolver listening on port 853 and serving DNS answers to queries encrypted with TLS. This setup was useful if your local DNS resolver was Unbound or Stubby, and since then I’ve been using Stubby as my local DNS client on MacOS with the Unbound DNS server at the Go6lab (privacydns.go6lab.si) as a recursive resolver for encrypted DNS queries without any issues.

So armed with the information from Erik, I decided to test out the Android implementation.

First thing was to turn on the setting and test it with the ‘privacydns.go6lab.si’ server which worked fine. Enabling ‘log-queries’ on the Unbound server quickly revealed that DNS queries are reaching the server and being properly resolved. Since ‘privacydns.go6lab.si’ port 853 is openly reachable from the Internet – you can test it as well.

Encouraged with this success, I thought of adding this functionality to the Go6lab recursive resolvers that I use on a daily basis, but this time it needs to listen on the standard DNS port 53 and as well as port 853 for DNS-over-TLS queries. Since we are running recursive resolvers in Go6lab on Unbound software, this was not a difficult task.

I had to install certbot, obtain a Let’s Encrypt certificate for the host, and add 5 new lines of configuration to unbound.conf…

interface: 0.0.0.0@853
interface: ::0@853
interface: 0.0.0.0@53
interface: ::0@53

ssl-service-key: “/etc/letsencrypt/live/recursive1.go6lab.si/privkey.pem”
ssl-service-pem: “/etc/letsencrypt/live/recursive1.go6lab.si/fullchain.pem”
ssl-port: 853

To make sure it’s also listening on port 53, I added the two lines ending with @53 as a precaution.

After rebooting the Unbound server, setting the ‘Private DNS’ setting on my phone to ‘recursive1.go6lab.si and briefly setting the ‘log-queries’ setting to ‘yes’, the first queries started to appear in the query log.

I was not sure whether queries were coming in over port 53 or 853, and therefore whether they were encrypted or not, so I used tcpdump to capture the traffic from the IPv6 address of my phone.

As we can see, traffic is flowing to and from port 853, indicating that our DNS traffic is being encrypted. Examining the tcpdump capture file with Wireshark reveals this is actually TLS 1.2 traffic and that the content of the packets is encrypted.

Most excellent I thought, but the problem is that with a pre-set ‘Private DNS’ server I would have issues when outside of the Go6lab network (or without a VPN connection back into it) as our DNS recursive resolvers are not reachable from outside to prevent DDOS attacks.

Well there’s a setting in ‘Private DNS’ that says ‘Automatic’ which is pretty opportunistic, and after switching this on, the phone tries to send the DNS query to port 853 and falls back to port 53 if there’s no answer. Observing this through tcpdump confirmed the automatic setting does exactly what is expected – it figures out whether DNS-over-TLS is working on our recursive resolvers and starts using it. This option doesn’t validate server names or hashes, but it makes sure it can negotiate TLS 1.2 (and probably also validates the certificate chain that’s provided). However, in ‘Strict Mode’, the system does additionally validate the hostname where this is entered.

The great aspect of automatic mode is that it does not lock you into one pre-set DNS resolving server, but uses whatever is provided when connecting to a different network. And it’s been confirmed by the user of a Pixel phone that this option is also present in the release version of Android 9 Pie, so this functionality will probably stick around in future versions of Android.

Implementation of this new privacy and security feature by the good people at Android is a big boost for making encryption the norm on the Internet, and opens the opportunity for network operators, DNS operators, VPN providers and everyone else running recursive DNS resolvers to quite easily add this functionality. Whoever connects to your network with Android 9 will automatically start using encrypted DNS service and will make sniffing of the queries at the transport layer a little bit more difficult for eavesdroppers.

With Unbound this is pretty simple – and in my next blog post we’ll be looking into how to enable DNS-over-TLS in Bind and some other DNS servers.

There are already few public recursive DNS resolvers currently supporting DNS-over-TLS on port 853 – Cloudflare on 1.1.1.1, Quad9 on 9.9.9.9, and also CleanBrowsing. But we’re also appealing to network operators and anyone who operates a recursive resolver to please add this functionality to your server. It won’t hurt as regular DNS clients will not even notice it, but for those whose operating systems can take advantage of port 853, it will benefit them a lot.

For more information about why DNS-over-TLS is important, the DNS Privacy Project has a good problem statement on its website, along with an explanation of the technical solutions.

Further Information

Categories
Improving Technical Security Technology Transport Layer Security (TLS)

TLS 1.3 – Internet Security Gets a Boost

Today marks the formal publication of an overhaul of the Transport Layer Security (TLS) protocol. TLS is an Internet standard used to prevent eavesdropping, tampering, and message forgery for various Internet applications. It is probably the most widely deployed network security standard in the world. Often indicated by the small green padlock in a web browser’s address bar1, TLS  is used in financial transactions, by medical institutions, and to ensure secure connections in a wide variety of other applications.

We believe the new version of this protocol, TLS 1.3, published as RFC 8446, is a significant step forward towards an Internet that is safer and more trusted.

Under development for the past four years and approved by the Internet Engineering Task Force (IETF) in March 2018, TLS 1.3 addresses known issues with the previous versions and improves security and performance, in particular it is able to establish a session more quickly than its predecessors. Because it is more efficient, TLS 1.3 promises better performance for the billions of users and organizations that use TLS every day. As with every IETF standard, TLS 1.3 was developed through open processes and participation, and included contributions from scores of individuals.

Many companies have indicated that they plan to implement and deploy TLS 1.3 in the near future and several have already done so. Part of their readiness can be traced back to the fact that the standard’s development was informed along the way by “running code” – test implementations that helped identify issues in and provide additional clarity to the specification, ensuring TLS 1.3 would not only look good on paper but that it would work well in the real world too. TLS 1.3 was also reviewed extensively by academic security and cryptography experts to help identify and address possible weaknesses before it was widely deployed.

A popular saying in the IETF community is that “there are no protocol police.” This reflects the reality that adoption of IETF protocols is voluntary and each network, enterprise, and Internet user is free to decide whether or not to use them. Given how widely TLS is deployed, it is inevitable that some challenges will be encountered as TLS 1.3 adoption gathers pace. Additional work may be required to address these challenges. However, on balance, TLS 1.3 represents a significant security win for the Internet and its users. We look forward to using it and tracking its adoption on the Internet.

See also:


1 – Editor’s Note: The TLS protocol is often mistakenly called “SSL” or “Secure Socket Layer”. SSL was the name of the original protocol developed by Netscape back in the mid-1990s. It was replaced by TLS 1.0 in 1999. (Yes, almost 20 years ago!) TLS 1.0 was in turn replaced by 1.1, 1.2, and now 1.3.

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards Transport Layer Security (TLS)

IETF 102, Day 4: DNS, IoT & TLS

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Today we’re focusing on DNS, IoT and TLS issues.

LPWAN is the first event of the day starting at 09.30 EDT/UTC-4. There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).


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


The first session of V6OPS commences at 13.30 EDT/UTC-4, and will continue on Friday morning. Today’s agenda items include a presentation on World IPv6 Trends from APNIC Labs, followed by discussion on a new draft NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network. Two existing drafts will also be discussed – Requirements for IPv6 Routers that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; and Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service which extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS).

During the second part of the afternoon starting at 15.50 EDT/UTC-4, there’s a choice of two meetings.

DNS Resolver Identification and Use (DRIU) is a BoF to discuss how to identify DNS stub resolvers that support privacy (i.e. DNS-over-TLS and DNS-over-HTTPS) using DHCP and DHCPv6. There’s a couple of drafts under discussion on DHCPv6 Options for private DNS Discovery, and DOH digests that provides a mechanism for selecting a DNS-over-HTTPS (DOH) server.

Alternatively, you can choose T2TRG that will consider the report from the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), along with an update on the iot.schema.org that enables webmasters to embed structured data on their web pages for use by search engines and other applications. Following this will be a discussion on the next steps for IoT security, including a draft that reviews the state-of-the-art and the challenges for IoT security. A further draft offers guidance for designing Internet of Things (IoT) systems that follow the REST architectural style.

Then for the evening session starting at 18.10 EDT/UTC-4, there’s again the choice of two meetings:

TLS continues on from Monday afternoon, and will consider three drafts during this session. Certificate-based Authentication with External PSK specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK); Ticket Requests describes a mechanism by which clients may request tickets as needed during a connection, in order to address a limitation on the number of parallel connection a client may initiate; whilst Encrypted Server Name Indication (ESNI) defines a simpler mechanism to conceal the domain name a client is trying to connect to.

DNSOP also continues from where it left off on Wednesday morning. A couple of interesting drafts that may come up in this session include a DNS proxy use case to tunnel DNS query and response using DNS over HTTPs (DOH) protocol; and a proposed protocol and DNS Resource Record to compute, sign, represent, and use a message digest to verify the contents of a DNS zone.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Events IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

IETF 102, Day 1: IETF arrive à Montréal

Tomorrow sees kickoff of the Working Groups sessions at IETF 102 in Montreal, Canada, we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Monday is an important day, with meetings of the TLS, 6MAN and SIDROPS Working Groups, along with two other IoT related groups.

6MAN commences at 09.30 EDT/UTC-4, and has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.


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


ACE is running parallel with 6MAN, and will be discussing various drafts related to using DTLSOAuth, and Object Security in RESTful Environments and Proof of Possession for Web Tokens. There is also an important draft on Enrollment over Secure Transport for provisioning certificates over HTTPS.

Then in the afternoon starting at 13.30 EDT/UTC-4, you’ll need to choose between three working groups. The first TLS session of the week (the meeting continues on Thursday afternoon) has several important items related to the deployment of TLS 1.3 and there’s a proposal to formally deprecate TLS versions 1.0 and 1.1.

There’s two other drafts updating DTLS to version 1.3 (see https://tools.ietf.org/html/draft-ietf-tls-dtls13-28 and https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-01), and another describing a TLS extension to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. The remaining couple of drafts on the agenda relate to a mechanism that allows for exportable proof of ownership of a certificate that can be transmitted out of band and verified by another party, and on delegating credentials on TLS to allow server operators to
create their own credential delegations without breaking compatibility with clients that do not support this specification.

Over in SIDROPS, there’s three recommendations up for discussion that network operators avoid using the maxLength attribute when issuing Route Origin Authorizations under RPKI; how to improve Origin Validation within a trusted environment; and definition of a RPKI signed object that can be used by Trust Anchors to allow Relying Parties to migrate to new keys. There’s also a couple of profiles being defined for verifying that a Customer AS holder has authorised a Provider AS to be its upstream provider, and for AS Provider Authorization objects to verify the AS_PATH attribute of routes advertised by BGP. Finally, there will be a discussion on validation deployment planning.

There’s just the two drafts being discussed during the IPWAVE meeting, but important ones. The first is an update of the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications; the other defines the use cases for IP-based vehicular networks.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

ISOC’s Hot Topics at IETF 102

The 102nd meeting of the IETF starts tomorrow in Montreal, Canada. This is will be the third time that an IETF has been held in the city, and tenth time in Canada – the first being way back in 1990.

The ISOC Internet Technology Team is as always highlighting the latest IPv6, DNSSEC, Securing BGP, TLS and IoT related developments, and we discuss these in detail in our Rough Guide to IETF 102. But we’ll also be bringing you daily previews of what’s happening each day as the week progresses.

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

Monday, 16 July 2018

Tuesday, 17 July 2018

Wednesday, 18 July 2018

Thursday, 19 July 2018

Friday, 20 July 2018

The IETF Hackathon will be held on both Saturday, 15 July 2018 (09.00-22.00 UTC-4) and Sunday, 16 July 2018 (08.30-16.00 UTC-4) in the Centre Ville Room. The Hackathon provides an opportunity for developers and implementers to discuss ideas, solutions and code to develop practical implementations of IETF standards.

The IETF Code Sprint will also be held on Saturday, 15 July 2018 (09.30-16.00 UTC-4) in the Sherbrooke/Mansfield Room. The Code Sprint brings together volunteers from the IETF Community to work on code for the IETF Datatracker, mailing lists, and other tools used by the IETF community.

You can also read the Internet Society’s latest Rough Guide to IETF 102. In particular, see:

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

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Internet Exchange Points (IXPs) Internet of Things (IoT) IPv6 Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

SEE 7: Connectivity, Routing Security & IoT

The 7th RIPE South-East Europe (SEE 7) meeting is being held on 18-19 June 2018 in Timisoara, Romania, and is focusing on several of the subjects of interest to the Internet Society. It’s also being chaired by our colleague Jan Žorž, whilst I’ll be talking about IoT Security and the OTA IoT Trust Framework.

In Monday, there are talks on BGP monitoring from Paolo Lucente (pmacct), and from Krzysztof Grzegorz Szarkowicz (Juniper Networks) on improvements to routing protocols to suit the centralised data centre-based architectures that are becoming more prevalent on the Internet, and which are the subject of an Internet Draft. Zoran Perovic (SOX) will also talk about paradigm shifts in the implementation of Internet Exchange Points.

On Tuesday, there will be a discussion led by Goran Slavic (SOX) on implementing MANRS in an IXP, which is very relevant to the current MANRS initiative which is increasingly being adopted by IXPs. Our colleague Jan will then be presenting about RIPE-690 which provides recommendations for IPv6 address prefix assignments for end-users. Preceding this, will be an update on IPv6 adoption in the SEE region from Massimiliano Stucchi (RIPE NCC).

Some other highlights are the talk on Quad9DNS by Nishal Goburdhan (PCH) that’s supporting secure DNS queries over TLS between client and resolver, and the road to 400 Gb/s connectivity from Thomas Weible, Flexoptix GmbH. On Monday morning there’s a tutorial on IPv6 Security being led by Massimiliano Stucchi (RIPE NCC), whilst for those with a policy bent, the Tuesday evening session will focus on GDPR.

My own presentation on IoT Security will be on Tuesday afternoon.

More information can be found on the SEE 7 website. The meeting is free to attend, although it is necessary to register. Alternatively you can participate remotely.

Categories
Building Trust Deploy360 Internet of Things (IoT) IPv6 Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

SINOG 5: IPv6, DNS Privacy and IoT Security

There will be significant Internet Society involvement at SINOG 5 next week, which is being co-organised by our colleague Jan Žorž, supported by ISOC, and will feature talks on NAT64Check and the Online Trust Alliance. SINOG is the Slovenian Network Operators Group, and the meeting is held on 7-8 June 2018 at the Biotehniška Fakulteta in Ljubljana, Slovenia.

It’s well worth coming for the keynote alone, which will be given by Ron Broersma (DREN) – one of the earliest Internet pioneers who operated Node #3 of ARPANET. He’ll be talking about IPv6, the Cloud, and a bit of Internet history, and as he was involved in the NCP-to-TCP/IP migration back in 1983, there are perhaps some lessons to be learned in migrating from IPv4-to-IPv6.

Following-on from this will be how IPv6 was implemented at IBM from Andy Mindnich (IBM), a discussion on the issues of CGN and IPv6 from a law enforcement perspective from Sara Marcolla (Europol), some of which we touched upon in a previous blog, and then an update on version 2 of the NAT64Check portal from Sander Steffann. NAT64Check is a tool allowing you to enter the URL of a particular website and run tests over IPv4, IPv6 and NAT64, and the development of this new version that will offer improved checks and aggregated statistics is being funded by ISOC.

Also worth highlighting is the talk on the Quad9: DNS Resolver from Nishal Goburdhan (PCH) which implements DNS queries over TLS between client and resolver, and on the challenges of routing security from Natalie Trenaman (RIPE NCC). Ivan Pepelnjak (ipSpace) is always good value for money, and will be kicking off Friday morning with his observations on real-life network monitoring.

Finally, just to mention my own presentation on OTA which will discuss the issues and challenges with IoT devices, and will present the OTA initiative which aims to promote best practices in protection of user security, privacy, identity, and data stewardship.

More information can be found on the SINOG website. The meeting is free to attend, although it is necessary to register.