Slashdot Mirror

An anonymous reader writes: This week marks the 50th anniversary for the Internet "Request for Comments" (RFC) series, which started in April 1969 with the publication of RFC1 titled "Host Software" authored by Stephen D. Crocker. The early RFCs were meant to be requests for comments on ideas and proposals, says Heather Flanagan, RFC Series Editor. Today over 8500 RFCs have been published, ranging from best practice information, experimental protocols, informational material, to Internet standards. An RFC has been published to mark the fiftieth anniversary to include retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs.

An anonymous reader writes: This week marks the 50th anniversary for the Internet "Request for Comments" (RFC) series, which started in April 1969 with the publication of RFC1 titled "Host Software" authored by Stephen D. Crocker. The early RFCs were meant to be requests for comments on ideas and proposals, says Heather Flanagan, RFC Series Editor. Today over 8500 RFCs have been published, ranging from best practice information, experimental protocols, informational material, to Internet standards. An RFC has been published to mark the fiftieth anniversary to include retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs.

Long-time Slashdot reader syn3rg quotes the DNS Flag Day page: The current DNS is unnecessarily slow and suffers from inability to deploy new features. To remediate these problems, vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019.

This change affects only sites which operate software which is not following published standards. Are you affected?
The site includes a form where site owners can test their domain -- it supplies a helpful technical report about any issues encountered -- as well as suggestions for operators of DNS servers and DNS resolvers, researchers, and DNS software developers. The Internet Systems Consortium blog also has a list of the event's supporters, which include Google, Facebook, Cisco, and Cloudflare, along with some history. "Extension Mechanisms for DNS were specified in 1999, with a minor update in 2013, establishing the 'rules of the road' for responding to queries with EDNS options or flags. Despite this, some implementations continue to violate the rules.

"DNS software developers have tried to solve the problems with the interoperability of the DNS protocol and especially its EDNS extension by various workarounds for non-standard behaviors... These workarounds excessively complicate DNS software and are now also negatively impacting the DNS as a whole. The most obvious problems caused by these workarounds are slower responses to DNS queries and the difficulty of deploying new DNS protocol features. Some of these new features (e.g. DNS Cookies) would help reduce DDoS attacks based on DNS protocol abuse....

"Our goal is a reliable and properly functioning DNS that cannot be easily attacked."

"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.

"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.

The encryption that protects your browser's connection to websites is getting a notch faster and a notch safer to use. From a report: That's because the Internet Engineering Task Force (IETF) on Friday finished a years-long process of modernizing the technology used to secure website communications. You may never have heard of Transport Layer Security -- TLS for short -- but version 1.3 is now complete and headed to websites, browsers and other parts of the internet that rely on its security. "Publishing TLS 1.3 is a huge accomplishment. It is one the best recent examples of how it is possible to take 20 years of deployed legacy code and change it on the fly, resulting in a better internet for everyone," said Nick Sullivan, head of cryptography for Cloudflare, which helps customers distribute their websites and other content around the world, in a blog post.

TLS 1.3 brings some significant improvements over TLS 1.2, which was finished 10 years ago. Perhaps first on the list is that it'll mean websites load faster. Setting up an encrypted connection on the web historically has caused delays since your browser and the website server must send information back and forth in a process called a handshake. The slower your broadband or the more congested your mobile network is, the more you'll notice these delays. Firefox and Chrome already support a draft version of TLS 1.3.

An anonymous reader quotes a report from Bleeping Computer: Security experts have filed a proposal with the Internet Engineering Task Force (IETF) that defines a secure framework for delivering firmware updates to Internet of Things (IoT) devices. Filed on Monday by three ARM employees, their submission has entered the first phase of a three-stage process for becoming an official Internet standard. Titled "IoT Firmware Update Architecture," their proposal -- if approved -- puts forward a series of ground rules that device makers could implement when designing the firmware update mechanism for their future devices. The proposed rules are nothing out of the ordinary, and security experts have recommended and advocated for most of these measures for years. Some hardware vendors are most likely already compliant with the requirements included in this IETF draft. Nonetheless, the role of this proposal is to have the IETF put forward an official document that companies could use as a baseline when designing the architecture of future products. This document could also serve as a general guideline for lawmakers who could draft regulations forcing manufacturers to adhere to this baseline. Some of the main requirements put forward by three ARM engineers in their IETF draft include: The update mechanism must work the same even if the firmware binary is delivered via Bluetooth, WiFi, UART, USB, or other mediums; The update mechanism must work in a broadcast type of delivery, allowing updates to reach multiple users at once; End-to-end security (public key cryptography) must be used to verify and validate firmware images.

The Internet Task Engineering Group (IETF) has approved the new HTTP status code 103. The new status code is intended to "minimize perceived latency." From the circular: It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser. Having such links available to the client as early as possible helps to minimize perceived latency. The "preload" ([Preload]) link relation can be used to convey such links in the Link header field of an HTTP response. However, it is not always possible for an origin server to generate the header block of a final response immediately after receiving a request. For example, the origin server might delegate a request to an upstream HTTP server running at a distant location, or the status code might depend on the result of a database query. The dilemma here is that even though it is preferable for an origin server to send some header fields as soon as it receives a request, it cannot do so until the status code and the full header fields of the final HTTP response are determined. [...] The 103 (Early Hints) informational status code indicates to the client that the server is likely to send a final response with the header fields included in the informational response. Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well. However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent. A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response. For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response. Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed. A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself (e.g., as metadata about the 103 (Early Hints) response).

Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:

This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.

What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.

AmiMoJo quotes the Register: The Internet Engineering Task Force has taken another small step in protecting everybody's privacy... As the draft proposal explains, the RFCs that define NTP have what amounts to a convenience feature: packets going from client to server have the same set of fields as packets sent from servers to clients... "Populating these fields with accurate information is harmful to privacy of clients because it allows a passive observer to fingerprint clients and track them as they move across networks".

The header fields in question are Stratum, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, and Receive Timestamp. The Origin Timestamp and Receive Timestamp offer a handy example or a "particularly severe information leak". Under NTP's spec (RFC 5905), clients copy the server's most recent timestamp into their next request to a server – and that's a boon to a snoop-level watcher.
The proposal "proposes backward-compatible updates to the Network Time Protocol to strip unnecessary identifying information from client requests and to improve resilience against blind spoofing of unauthenticated server responses." Specifically, client developers should set those fields to zero.

An anonymous reader quotes a report from Motherboard: For almost six years, Google knew about the exact technique that someone used to trick around one million people into giving away access to their Google accounts to hackers on Wednesday. Even more worrisome: other hackers might have known about this technique as well. On October 4, 2011, a researcher speculated in a mailing list that hackers could trick users into giving them access to their accounts by simply posing as a trustworthy app. This attack, the researcher argued in the message, hinges on creating a malicious application and registering it on the OAuth service under a name like "Google," exploiting the trust that users have in the OAuth authorization process. OAuth is a standard that allows users to grant websites or applications access to their online email and social networking accounts, or parts of their accounts, without giving up their passwords. "Imagine someone registers a client application with an OAuth service, let's call it Foobar, and he names his client app 'Google, Inc.'. The Foobar authorization server will engage the user with 'Google, Inc. is requesting permission to do the following,'" Andre DeMarre wrote in the message sent to the Internet Engineering Task Force (IETF), the independent organization responsible for many of the internet's operating standards. "The resource owner might reason, 'I see that I'm legitimately on the https://www.foobar.com/ site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow,'" DeMarre concluded. As it turns out, DeMarre claims he warned Google directly about this vulnerability in 2012, and suggested that Google address it by checking to see ensure the name of any given app matched the URL of the company behind it. In a Hacker News post, DeMarre said he reported this attack vector back then, and got a "modest bounty" for it.

An anonymous reader writes: A group of independent security researchers and major Silicon Valley tech giants have submitted a proposal for a new email protocol called SMTP STS (Strict Transport Security). In theory, this new extension looks like the HSTS (HTTP Strict Transport Security) extension to HTTPS. Much like HSTS, SMTP STS brings message confidentiality and server authenticity to the process of starting an encrypted email communications channel. HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks. to avoid SSL/TLS downgrades and MitM attacks. The biggest names on the contributors list include Microsoft, Google, Yahoo, LinkedIn, and Comcast. Last year, Oracle also submitted a similar proposal called DEEP (Deployable Enhanced Email Privacy).

An anonymous reader writes: A group of independent security researchers and major Silicon Valley tech giants have submitted a proposal for a new email protocol called SMTP STS (Strict Transport Security). In theory, this new extension looks like the HSTS (HTTP Strict Transport Security) extension to HTTPS. Much like HSTS, SMTP STS brings message confidentiality and server authenticity to the process of starting an encrypted email communications channel. HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks. to avoid SSL/TLS downgrades and MitM attacks. The biggest names on the contributors list include Microsoft, Google, Yahoo, LinkedIn, and Comcast. Last year, Oracle also submitted a similar proposal called DEEP (Deployable Enhanced Email Privacy).

An anonymous reader writes: Ars notes that the RFC for IPv6 was published just over 20 years ago, and the protocol has finally reached the 10% deployment milestone. This is an increase from ~6% a year ago. (The percentage of users varies over time, peaking on the weekends when most people are at home instead of work.) "If a 67 percent increase per year is the new normal, it'll take until summer 2020 until the entire world has IPv6 and we can all stop slicing and dicing our diminishing stashes of IPv4 addresses."

"A decade or so ago, it was still quite common for people to complain about certain IPv6 features, and proclaim the protocol would never catch on. Although part of that can be blamed on the conservative nature of network administrators, it's true that adopting IPv6 requires abandoning some long standing IPv4 practices. For instance, with IPv4, it's common to use Network Address Translation (NAT) so multiple devices can share the use on an IPv4 address. IPv6 has more than enough addresses to give each device its own, so there's no NAT in IPv6. The Internet is probably better off without NAT and the complications that it adds, but without NAT as a first but relatively porous line of defense against random packets coming in from the open Internet, it's necessary to be much more deliberate about which types of packets to accept and which to reject."

An anonymous reader writes: British programmer and writer John Graham-Cumming has spotted what appears to be a 'code-protest' in the next generation of the hypertext protocol. Each new connection forged by the HTTP/2.0 protocol spells out the word 'PRISM' obliquely, though the word itself is obscured to the casual observer by coded returns and line-breaks. Work on the hidden message in HTTP/2.0 seems to date back to nine days after the Snowden revelations broke, with the final commit completed by July of 2013. In July 2013 one of the protocol's architects appealed to the development group to reconsider design principles in the light of the revelations about the NSA's worldwide surveillance program.

An anonymous reader writes: As tweeted by Jacob Appelbaum, the Internet Assigned Numbers Authority today listed .onion as a special-use domain, and the IETF approved a Draft RFC for the domain describing its intended uses. As described on the Facebook Over Tor page, "Jointly, these actions enable '.onion' as special-use, top-level domain name for which SSL certificates may be issued in accordance with the Certificate-Authority & Browser Forum 'Ballot 144' — which was passed in February this year. ... Together, this assures the validity and future availability of SSL certificates in order to assert and protect the ownership of Onion sites throughout the whole of the Tor network."

An anonymous reader writes: Korean users are among the most bandwidth-hungry smartphone users. During the MPTCP WG meeting at IETF'93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1 Gbps. This is not yet 5G, but the first large scale commercial deployment of Multipath TCP by a mobile operator to combine fast LTE and fast WiFi to reach up to 1 Gbps. This service is offered on the Samsung Galaxy S6 whose Linux kernel includes the open-source Multipath TCP implementation and SOCKSv5 proxies managed by the network operator. Several thousands of users are already actively using this optional service.

An anonymous reader writes: Korean users are among the most bandwidth-hungry smartphone users. During the MPTCP WG meeting at IETF'93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1 Gbps. This is not yet 5G, but the first large scale commercial deployment of Multipath TCP by a mobile operator to combine fast LTE and fast WiFi to reach up to 1 Gbps. This service is offered on the Samsung Galaxy S6 whose Linux kernel includes the open-source Multipath TCP implementation and SOCKSv5 proxies managed by the network operator. Several thousands of users are already actively using this optional service.

AmiMoJo writes: SSLv3 should not be used, according to the IETF's RFC 7568. Despite being replaced by three versions of TLS, SSLv3 is still in use. Clients and servers are now recommended to reject requests to use SSLv3 for secure communication. "SSLv3 Is Comprehensively Broken," say the authors, and lay out its flaws in detail.

AmiMoJo writes: SSLv3 should not be used, according to the IETF's RFC 7568. Despite being replaced by three versions of TLS, SSLv3 is still in use. Clients and servers are now recommended to reject requests to use SSLv3 for secure communication. "SSLv3 Is Comprehensively Broken," say the authors, and lay out its flaws in detail.

jones_supa writes: Mozilla is officially beginning to phase out non-secure HTTP to prefer HTTPS instead. After a robust discussion on the mailing list, the company will boldly start removing capabilities of the non-secure web. There are two broad elements of this plan: setting a date after which all new features will be available only to secure websites, and gradually phasing out access to browser features for non-secure websites, especially regarding features that pose risks to users' security and privacy. This plan still allows for usage of the "http" URI scheme for legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the "http" scheme can be automatically translated to "https" by the browser, and thus run securely. The goal of this effort is also to send a message to the web developer community that they need to be secure. Mozilla expects to make some proposals to the W3C WebAppSec Working Group soon.

An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.

An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.

An anonymous reader writes HTTP/2 is back in the spotlight again. After drawing significant ire over a proposal for officially sanctioned snooping, the IETF is drawing criticism for plowing ahead with its plans for HTTP/2 on an unrealistically short schedule and with an insufficiently clear charter. A few days ago the IETF announced Last Call for comments on the HTTP/2 protocol.

Poul-Henning Kamp writes, "Some will expect a major update to the world's most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of 'faster.' Many will probably also assume it is 'greener.' And some of us are jaded enough to see the "2.0" and mutter 'Uh-oh, Second Systems Syndrome.' The cheat sheet answers are: no, no, probably not, maybe, no and yes."

"Given this rather mediocre grade-sheet, you may be wondering why HTTP/2.0 is even being considered as a standard in the first place. The Answer is Politics. Google came up with the SPDY protocol, and since they have their own browser, they could play around as they choose to, optimizing the protocol for their particular needs. SPDY was a very good prototype which showed clearly that there was potential for improvement in a new version of the HTTP protocol. Kudos to Google for that. But SPDY also started to smell a lot like a 'walled garden'."

"The IETF, obviously fearing irrelevance, hastily 'discovered' that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol. With only the most hideous of SPDY's warts removed, and all other attempts at improvement rejected as 'not in scope,' 'too late,' or 'no consensus,' the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative."

AlbanX sends word that security researchers from Google have published details on a vulnerability in SSL 3.0 that can allow an attacker to calculate the plaintext of encrypted communications. Google's Bodo Moller writes, SSL 3.0 is nearly 15 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue. Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response (PDF) is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

An anonymous reader writes "Microsoft [Wednesday] announced it is developing at least four new features for the next release of Internet Explorer (IE): Web Audio API, Media Capture and Streams, ES6 Promises, and HTTP/2. The company says this is not an exhaustive list of what to expect in the next version, but merely what it is currently confident that it will be able to deliver. For those who don't know, HTTP/2 is a faster protocol for transporting Web content. It is based on Google's SPDY open networking protocol and is currently being standardized by the IETF. Web Audio is a JavaScript API for processing and synthesizing audio in Web applications while Media Capture provides access to the user's local audio and video input/output devices. Promises is meant to help developers write cleaner asynchronous code."

msm1267 (2804139) writes with a bit of news from last week that seems to have slipped under the radar. The IETF TLS working group has reached consensus on dropping static RSA cipher suites from TLS 1.3, instead requiring the use of Diffie-Hellman Exchange (or the faster ellipitic curve variant). Static DH and not just ephemeral DH key exchange will be supported, so not all connections will have forward secrecy. The consensus is subject to change before the final TLS 1.3 specification is released, and there are still details to be worked out. The changes to the draft are pending as a git pull request.

msm1267 (2804139) writes with a bit of news from last week that seems to have slipped under the radar. The IETF TLS working group has reached consensus on dropping static RSA cipher suites from TLS 1.3, instead requiring the use of Diffie-Hellman Exchange (or the faster ellipitic curve variant). Static DH and not just ephemeral DH key exchange will be supported, so not all connections will have forward secrecy. The consensus is subject to change before the final TLS 1.3 specification is released, and there are still details to be worked out. The changes to the draft are pending as a git pull request.

pdclarry writes: "On April 8, Yahoo implemented a new DMARC policy that essentially bars any Yahoo user from accessing mailing lists hosted anywhere except on Yahoo and Google. While Yahoo is the initiator, it also affects Comcast, AT&T, Rogers, SBCGlobal, and several other ISPs. Internet Engineering Council expert John R. Levine, a specialist in email infrastructure and spam filtering, said, 'Yahoo breaks every mailing list in the world including the IETF's' on the Internet Engineering Task Force (IETF) list.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a two-year-old proposed standard previously discussed on Slashdot that is intended to curb email abuse, including spoofing and phishing. Unfortunately, as implemented by Yahoo, it claims most mailing list users as collateral damage. Messages posted to mailing lists (including listserv, mailman, majordomo, etc) by Yahoo subscribers are blocked when the list forwards them to other Yahoo (and other participating ISPs) subscribers. List members not using Yahoo or its partners are not affected and will receive posts from Yahoo users. Posts from non-Yahoo users are delivered to Yahoo members. So essentially those suffering the most are Yahoo's (and Comcast's, and AT&T's, etc) own customers. The Hacker News has details about why DMARC has this effect on mailing lists. Their best proposed solution is to ban Yahoo email users from mailing lists and encourage them to switch to other ISPs. Unfortunately, it isn't just Yahoo, although they are getting the most attention."

Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012." Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.

Lauren Weinstein writes "You'd think that with so many concerns these days about whether the likes of AT&T, Verizon, and other telecom companies can be trusted not to turn our data over to third parties whom we haven't authorized, that a plan to formalize a mechanism for ISP and other 'man-in-the-middle' snooping would be laughed off the Net. But apparently the authors of IETF (Internet Engineering Task Force) Internet-Draft 'Explicit Trusted Proxy in HTTP/2.0' (14 Feb 2014) haven't gotten the message. What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."

Trailrunner7 writes "The NSA surveillance scandal has created ripples all across the Internet, and the latest one is a new effort from the IETF to change the way that encryption is used in a variety of critical application protocols, including HTTP and SMTP. The new TLS application working group was formed to help developers and the people who deploy their applications incorporate the encryption protocol correctly. TLS is the successor to SSL and is used to encrypt information in a variety of applications, but is most often encountered by users in their Web browsers. Sites use it to secure their communications with users, and in the wake of the revelations about the ways that the NSA is eavesdropping on email and Web traffic its use has become much more important. The IETF is trying to help ensure that it's deployed properly, reducing the errors that could make surveillance and other attacks easier."

First time accepted submitter ConstantineM writes "Inspired by a recent Google initiative to adopt ChaCha20 and Poly1305 for TLS, OpenSSH developer Damien Miller has added a similar protocol to ssh, chacha20-poly1305@openssh.com, which is based on D. J. Bernstein algorithms that are specifically optimised to provide the highest security at the lowest computational cost, and not require any special hardware at doing so. Some further details are in his blog, and at undeadly. The source code of the protocol is remarkably simple — less than 100 lines of code!"

agizis writes "Google presented their new QUIC (Quick UDP Internet Connections) protocol to the IETF yesterday as a future replacement for TCP. It was discussed here when it was originally announced, but now there's real working code. How fast is it really? We wanted to know, so we dug in and benchmarked QUIC at different bandwidths, latencies and reliability levels (test code included, of course), and ran our results by the QUIC team."

New submitter bmurray7 writes "You might think that the country that has the fastest average home internet speeds would be a first adapter of modern browsers. Instead, as the Washington Post reports, a payment processing security standard forces most South Koreans to rely upon Internet Explorer for online shopping. Since the standard uses a unique encryption algorithm, an ActiveX control is required to complete online purchases. As a result, many internet users are in the habit of approving all AtivceX control prompts, potentially exposing them to malware."

On September 9, The Internet Society issued a position paper in which it said the group "...is alarmed by continuing reports alleging systematic United States government efforts to circumvent Internet security mechanisms," and went on to say, "The Internet Society President and CEO, Lynn St. Amour, said, 'If true, these reports describe government programmes that undermine the technical foundations of the Internet and are a fundamental threat to the Internet’s economic, innovative, and social potential. Any systematic, state-level attack on Internet security and privacy is a rejection of the global, collaborative fabric that has enabled the Internet's growth to extend beyond the interests of any one country.'" Those are tough words from an international organization that usually spends its time bringing the Internet to people in out-of-the-way villages and sponsoring the Internet Engineering Task Force. You can join the Internet Society for as little as $0 per year, and possibly help beat back some of the U.S. government eavesdropping and encryption circumvention efforts. And if you can make it to San Francisco on October 2, you can attend a (free) Internet Society discussion. Meanwhile, today's Slashdot interviewee is Paul Brigner, the Internet Society Regional Bureau Director for North America, who talks about the Internet Society in general, as well as the group's reaction to the U.S. government's online surveillance.

Olivier Bonaventure writes "Besides changes in UI, multitasking and other features that the press discusses, iOS7 also includes support for Multipath TCP. Multipath TCP is a major extension to TCP that is able to use different interfaces for the same connection. Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel. iOS7 changes that, with millions of Multipath-TCP enabled devices that can switch from 3G to WiFi without losing existing TCP connections. This is not yet the case on iOS7, which currently seems to only enable it for SIRI, but other use cases will likely appear in the future."

hypnosec writes "PRISM-Proof Security Considerations, a draft proposal to make it harder for governments to implement and carry out surveillance activities like PRISM, has been floated by the Internet Engineering Task Force (IETF). The draft highlights security concerns as a result of government sponsored PRISM-like projects and the security controls that may be put into place to mitigate the risks of interception capabilities. Authored by Phillip Hallam-Baker of the Comodo Group the draft is however very sparse on details on how the Internet can be PRISM-proofed."

IamTheRealMike writes "In the wake of Bruce Schneier's statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected ... and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is 'Standards for Efficient Cryptography'), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a "verifiably random" process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general."

earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"

lpress writes "If you use a mouse, hyperlinks, video conferencing, WYSIWYG word processor, multi-window user interface, shared documents, shared database, documents with images & text, keyword search, instant messaging, synchronous collaboration, or asynchronous collaboration, you can thank Doug Engelbart, who passed away today."

A few months ago, Tatu Ylonen (creator of SSH 1.x) declared that lax key management was hazardous. Now there's work being done on a standard for automated key management. hypnosec sent in the news; quoting Parity News on the content of the draft: "It presents a process that would allow for moving of already issued keys to protected location, removal of unused keys, key rotation, providing rights of what can be done with the keys and establishing an approval process for issue of new keys." There's a non-WG mailing list; the final version of the standard is expected in October.

A few months ago, Tatu Ylonen (creator of SSH 1.x) declared that lax key management was hazardous. Now there's work being done on a standard for automated key management. hypnosec sent in the news; quoting Parity News on the content of the draft: "It presents a process that would allow for moving of already issued keys to protected location, removal of unused keys, key rotation, providing rights of what can be done with the keys and establishing an approval process for issue of new keys." There's a non-WG mailing list; the final version of the standard is expected in October.

An anonymous reader writes "As reported by Slashdot, Nokia recently notified the IETF that its RFC 6386 video codec (aka VP8, released by Google under a BSD license with a waiver of that company's patent rights) infringed several dozen of its patents; furthermore, Nokia was not inclined to license them under FRAND (fair, reasonable, and non-discriminating) terms. While the list provided by Nokia looks intimidating, Pamela Jones at Groklaw discovered that many appeared to be duplicates except for the country of filing; and even within a single country (e.g. the U.S.), some appeared to be overlapping. In other words, there may be far fewer distinct patented issues than what appears on Nokia's IETF form. Thom Holwerda at OSNews also weighed in, recalling another case where sweeping patent claims by Qualcomm and Huawei against the Opus open source audio codec proved to be groundless FUD. The familiar name Florian Mueller pops up again in Holwerda's article."

An anonymous reader writes "Google just settled video codec patent claims with MPEG LA and its VP8 format, which it wants to be elevated to an Internet standard, already faces the next round of patent infringement allegations. Nokia submitted an IPR declaration to the Internet Engineering Task Force listing 64 issued patents and 22 pending patent applications it believes are essential to VP8. To add insult to injury, Nokia's declaration to the IETF says NO to royalty-free licensing and also NO to FRAND (fair, reasonable and non-discriminatory) licensing. Nokia reserves the right to sue over VP8 and to seek sales bans without necessarily negotiating a license deal. Two of the 86 declared IPRs are already being asserted in Mannheim, Germany, where Nokia is suing HTC in numerous patent infringement cases. A first VP8-related trial took place on March 8 and the next one is scheduled for June 14. In related Nokia-Google patent news, the Finns are trying to obtain a U.S. import ban against HTC to force it to disable tethering (or, more likely, to pay up)."

First time accepted submitter Olivier Bonaventure writes "The TCP protocol is closely coupled with the underlying IP protocol. Once a TCP connection has been established through one IP address, the other packets of the connection must be sent from this address. This makes mobility and load balancing difficult. Multipath TCP is a new extension that solves these old problems by decoupling TCP from the underlying IP. A Multipath TCP connection can send packets over several interfaces/addresses simultaneously while remaining backward compatible with existing TCP applications. Multipath TCP has several use cases, including smartphones that can use both WiFi and 3G, or servers that can pool multiple high-speed interfaces. Christoph Paasch, Gregory Detal and their colleagues who develop the implementation of Multipath TCP in the Linux kernel have achieved 50 Gbps for a single TCP connection [note: link has source code and technical details] by pooling together six 10 Gbps interfaces."

alphadogg writes "With an eye towards updating the Web to better accommodate complex and bandwidth-hungry applications, the Internet Engineering Task Force has started work on the next generation of HTTP, the underlying protocol for the Web. The HTTP Strict Transport Security (HSTS), is a security protocol designed to protect Internet users from hijacking. The HSTS is an opt-in security enhancement whereby web sites signal browsers to always communicate with it over a secure connection. If the user is using a browser that complies with HSTS policy, the browser will automatically switch to a secure version of the site, using 'https' without any intervention of the user. 'It's official: We're working on HTTP/2.0,' wrote IETF Hypertext Transfer Protocol working group chair Mark Nottingham, in a Twitter message late Tuesday."

New submitter jmv writes "It's official. The Opus audio codec is now standardized by the IETF as RFC 6716. Opus is the first state-of-the-art, fully Free and Open audio codec ratified by a major standards organization. Better, Opus covers basically the entire audio-coding application space and manages to be as good or better than existing proprietary codecs over this whole space. Opus is the result of a collaboration between Xiph.Org, Mozilla, Microsoft (yes!), Broadcom, Octasic, and Google. See the Mozilla announcement and the Xiph.Org press release for more details."

An anonymous reader writes "With the success of world IPv6 day in 2011, there is a lot of speculation about IPv6 in 2012. But simply turning on IPv6 does not make the problems of IPv4 exhaustion go away. It is only when services are usable with IPv6-only that the internet can clip the ties to the IPv4 boat anchor. That said, FreeBSD, Windows, and Android are working on IPv6-only capabilities. There are multiple accounts of IPv6-only network deployments. From those, we we now know that IPv6-only is viable in mobile, where over 80% (of a sampling of the top 200 apps) work well with IPv6-only. Mobile especially needs IPv6, since their are only 4 billion IPv4 address and approaching 50 billion mobile devices in the next 8 years. Ironically, the Android test data shows that the apps most likely to fail are peer-to-peer, like Skype. Traversing NAT and relying on broken IPv4 is built into their method of operating. P2P communications was supposed to be one of the key improvements in IPv6."

An anonymous reader writes "With the success of world IPv6 day in 2011, there is a lot of speculation about IPv6 in 2012. But simply turning on IPv6 does not make the problems of IPv4 exhaustion go away. It is only when services are usable with IPv6-only that the internet can clip the ties to the IPv4 boat anchor. That said, FreeBSD, Windows, and Android are working on IPv6-only capabilities. There are multiple accounts of IPv6-only network deployments. From those, we we now know that IPv6-only is viable in mobile, where over 80% (of a sampling of the top 200 apps) work well with IPv6-only. Mobile especially needs IPv6, since their are only 4 billion IPv4 address and approaching 50 billion mobile devices in the next 8 years. Ironically, the Android test data shows that the apps most likely to fail are peer-to-peer, like Skype. Traversing NAT and relying on broken IPv4 is built into their method of operating. P2P communications was supposed to be one of the key improvements in IPv6."