Jekyll2022-09-30T16:45:15+00:00https://pluggabletransports.info/feed.xmlPluggable Transports{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoPop Up PTIM Session Video: Gamers Games Unblocked, Minecruft PT2022-09-30T00:00:00+00:002022-09-30T00:00:00+00:00https://pluggabletransports.info/blog/may2022-popup-ptim-minecruft-video<h1 id="pop-up-ptim-session-video-presentation">Pop Up PTIM Session: Video presentation</h1>
<h2 id="presented-by-dr-richard-brooks">Presented by Dr. Richard Brooks</h2>
<p>The presentation of the Pop Up PTIM Session <strong>Gamer Games Unblocked</strong> video
recording is available on <a href="https://archive.org/details/popup-ptim-gamer-games">Internet
Archive</a>.</p>
<p>Further information about the session can be found on the <a href="/blog/popup-ptim-minecruft-announcement/">announcement blog
post</a>.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoPop Up PTIM Session: Video presentationIETF July 2022 Monthly Report2022-09-28T00:00:00+00:002022-09-28T00:00:00+00:00https://pluggabletransports.info/blog/july2022-ietf-report<p>In our IETF series, we have contributions from David Oliver of <a href="https://guardianproject.info">Guardian
Project</a>. David has attended several
<a href="https://ietf.org">IETF</a> meetings, learning about new protocols that can help
advance Pluggable Transports work and benefit censorship circumvention
developers.</p>
<h2 id="july-2022-report">July 2022 Report</h2>
<p>By David Oliver of Guardian Project -
<a href="mailto:david@guardianproject.info">david@guardianproject.info</a></p>
<h2 id="tldr">TL;DR</h2>
<p>The Internet Engineering Task Force (IETF) has rapidly scaled up
privacy-focused standards activity since mid-2019. The most important are:
<a href="https://datatracker.ietf.org/wg/masque/about/">MASQUE</a>, <a href="https://datatracker.ietf.org/wg/mls/about/">Messaging Layer
Security</a>, <a href="https://datatracker.ietf.org/wg/privacypass/about/">Privacy
Pass</a>, <a href="https://datatracker.ietf.org/wg/ohai/about/">Oblivious HTTP
Application Intermediation</a>,
<a href="https://datatracker.ietf.org/wg/ppm/about/">Privacy Preserving Measurementand</a>
and <a href="https://datatracker.ietf.org/doc/html/rfc8446">TLS 1.3</a> with <a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/">Encrypted
Client Hello</a>. The main
privacy-focused advocacy groups within IETF are the <a href="https://datatracker.ietf.org/doc/charter-irtf-hrpc/">Privacy Enhancements and
Assessments Research
Group</a> and the <a href="https://datatracker.ietf.org/doc/charter-irtf-hrpc/">Human
Rights Protocol Considerations Research
Group</a>.</p>
<p>The effort undertaken here has developed key relationships within IETF as well
as knowledge of its processes, brought knowledge of these activities into the
Internet Freedom community, and engaged actively in the standards process with
the definition and implementation of <a href="https://datatracker.ietf.org/doc/draft-schinazi-httpbis-transport-auth/07/">HTTP Transport
Authentication</a>
which the <a href="https://datatracker.ietf.org/wg/httpbis/about/">HTTPbisWorking</a>
Group is now considering for adoption. More of these implementation efforts -
cooperations among the Internet Freedom community, the open source community
and the IETF - are recommended along with continued participation in its
ongoing activities.</p>
<h2 id="introduction">Introduction</h2>
<p>Let’s review why we thought this work might be important.</p>
<p>The majority of Internet Freedom funding is focused on solving immediate-term
problems stemming from active surveillance, active suppression of Internet
access (or access to specific content) and broad inequities in the availability
of Internet access around the world. Solutions with short-term and measurable
impact are sought. However, while this body of work has positively-impacted
many lives, it’s safe to say that the hoped-for impacts have not been <em>at
Internet scale</em> - euphemistically molehills, not mountains. Standards bodies,
by contrast, operate at Internet scale and address problems in ways that can
produce highly-generalized and durable solutions. However, because standards
bodies are <em>deliberative</em>, results are not delivered in a timely fashion (or
sometimes not at all). The question was asked: If a small amount of Internet
Freedom funding was focused on steering Internet standards toward minimizing
unwanted surveillance, improving privacy and enhancing access around the world
could the gap be bridged between small-scale, short-term success and
large-scale, long-term success?</p>
<p>The Internet’s two most important standards bodies are the Internet Engineering
Task Force (<a href="https://www.ietf.org/">IETF</a>) and the World Wide Web Consortium
(<a href="https://www.w3.org/Consortium/">W3C</a>) - the former with focus on the
protocols that move content around the Internet, the latter with focus on the
content itself. The IETF, therefore, is the body most likely to produce
standards that impact our areas of interest. Fortunately, given the long-held
spirit of cooperation among participants, the IETF has shown itself to be very
effective at delivering standards that (a) are defined in a manner agreeable to
the parties that must implement them and (b) have proven-interoperable
implementations demonstrating success <em>before</em> the standard is agreed.</p>
<p>Although IETF’s interest in privacy didn’t start in July 2019 (with the
<a href="https://www.cs.columbia.edu/~smb/talks/ietf-privacy.pdf">plenary talk</a> at the
105th meeting of the IETF by Columbia’s Steven Bellovin), IETF participants
have been running their privacy efforts in high gear since that time. In
addition to technical efforts such as <a href="https://datatracker.ietf.org/wg/privacypass/about/">Privacy
Pass</a> and <a href="https://datatracker.ietf.org/wg/ppm/about/">Privacy
Preserving Measurement</a>, the
<a href="https://datatracker.ietf.org/rg/pearg/about/">Privacy Enhancements and Assessments Research
Group</a> and the <a href="https://datatracker.ietf.org/rg/pearg/about/">Human Rights
Protocol Considerations</a> Research
Group monitor, respectively, the most modern research in the implications of
technology on privacy and the human implications of the protocols IETF designs.
These close interactions among researchers, advocates and implementers have
created a strong feedback loop that improves the chance of long term success in
network protocol design. For example, [Transport Layer
Security](https://datatracker.ietf.org/doc/rfc5246/(https://datatracker.ietf.org/rg/pearg/about/)
now secures <a href="https://radar.cloudflare.com/">over 99% of all Internet browsing
traffic</a>. The most recent version, TLS 1.3, with
even better security and supporting the privacy-enhancing <a href="https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.html">Encrypted Client
Hello</a>, already
accounts for 60% of Internet traffic, mostly via the <a href="https://www.google.com/chrome/downloads/">Chrome
browser</a> (the Internet’s most
popular). Development of the initial version of TLS and the current version
each took over four years to complete. Here’s <a href="https://dl.acm.org/doi/fullHtml/10.1145/3442381.3450057">an excellent
article</a> describing
the process of bringing TLS 1.3 into broad adoption. An effort similar to TLS
(called <a href="https://datatracker.ietf.org/wg/mls/about/">Messaging Layer Security</a>,
expected to reach standardization in 2023) is having a similar gestation period
and could have TLS’s level of industry-wide impact on the privacy and security
of messaging systems.</p>
<p>Within this context, we set out to discover if engaging with the IETF could
both inform our work solving the most immediate privacy problems of the
Internet and if our work could inform future IETF efforts to create durable and
widespread standards-based solutions. From our original proposal, this initial
foray was intended to:</p>
<ul>
<li>Identify standards proposals applicable to Internet freedom via engagement
with IETF working groups and research teams, as well as individual
participants as necessary</li>
<li>Report on related new work and on the progress/status of existing work items</li>
<li>Engage others in the Internet Freedom community to identify existing
standards where work is necessary to correct failings or enhance Internet
freedom</li>
</ul>
<h2 id="important-developing-standards">Important developing standards</h2>
<p>At any one time, the IETF is engaged in the development of hundreds of
standards - from small corrections or additions to existing standards (for
example, <a href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/">management of traffic
congestion</a> in
TCP) to major protocol upgrades (for example,
<a href="https://datatracker.ietf.org/wg/quic/about/">QUIC</a>). While even seemingly
minor protocol nuances can have <a href="https://mailarchive.ietf.org/arch/msg/quic/up8EhFHPIHMQbFK3yHVFV6JrZM0/">huge future implications on privacy and
Internet
Freedom</a>
(for example, the <a href="https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-00">QUIC Spin
Bit</a>), our
efforts were focused on major privacy-first <em>from-whole-cloth</em> activities.
Here’s a condensed description of these works and where they stand today.</p>
<h3 id="masque">MASQUE</h3>
<p>Multiplexed Application Substrate over QUIC Encryption
(<a href="https://datatracker.ietf.org/wg/masque/about/">MASQUE</a>) began life with a
small idea: provide a mechanism to co-locate networking applications -
specifically VPNs - behind an HTTPS web server in a manner that makes those
services indistinguishable from other HTTPS content and services to any
unauthenticated observer. The MASQUE definition grew much larger, however, when
it was realized that the definition of the QUIC and HTTP/3 protocols could be
enhanced with all forms of proxy flow, not just one narrow definition. The
original idea was hived off into a <a href="https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-transport-auth-00">separate
draft</a>,
to await later discussion (more on this later), a Working Group was formed and
a suite of key standards was developed.</p>
<p>In April, the MASQUE Working Group reached consensus on both <a href="https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/">HTTP/3
Datagrams</a>
(datagrams for HTTP) and
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/">Connect-UDP</a>
(proxying datagrams over HTTP). In June, as expected, both drafts were
submitted for publication as Proposed Standards. The Working Group has now
commenced work on
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/">Connect-IP</a>
(proxying IP packets over HTTP) which defines the last of the required proxying
scenarios agreed by this Working Group. Upon completion, all forms of Internet
traffic - IP, UDP, TCP and QUIC - will have an HTTP proxying definition. At
IETF114 in July, work began on interoperation testing for Connect-IP.</p>
<h3 id="messaging-layer-security-mls">Messaging Layer Security (MLS)</h3>
<p>Messaging Layer Security (<a href="https://datatracker.ietf.org/wg/mls/about/">MLS</a>) is
IETF’s attempt to specify a single, secure and private group messaging
framework while allowing for multiple implementations can offer different
application feature sets. The concept for and thinking around MLS is similar to
that of TLS: it’s better (for users) to have a single
cryptographically-correct, well-architected protocol for a capability when no
one is seeking to compete in the same area. MLS is defined via an architecture
and a protocol, with implementations of the latter left up to individual
vendors.</p>
<p>After nearly 18 months of hiatus on protocol changes (while implementers worked
to get their implementations to meet the then-current protocol drafts), draft
#14 of the <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">MLS
protocol</a> was
submitted for final comment in May 3. Two Working Group interim meetings were
held in June on the issues raised by draft #14. <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">Drafts #15</a> and
<a href="https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-16.html">#16</a>
were created and #16 was submitted for standards consideration. A new
architecture draft (<a href="https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-08.html">draft #8</a>)
was created in June to reflect the changes adopted in the protocol during the
last quarter. It, too, was submitted in July for final review.</p>
<p>Last month we mentioned the <a href="https://datatracker.ietf.org/doc/draft-robert-mls-extensions/">MLS Extensions
draft</a>. By
agreement of the Working Group over the last six months, this document moves a
number of initially-imagined protocol “features” into hoped-for sanctioned
extensions (in order to speed the adoption of the currently-defined protocol).
In mid-June, this document was submitted officially to the Working Group for
adoption (as a work item for the WG to officially act on) and the document was
voted through at IETF114 in July.</p>
<p>Via these activities, and rapid progress on protocol implementations, it’s
likely MLS will reach the status of Proposed Standard by mid-2023.</p>
<h3 id="privacy-pass">Privacy Pass</h3>
<p>With the rise of automated-agent (so-called <em>bots</em>) traffic on the Internet (<a href="https://www.imperva.com/company/press_releases/the-pandemic-of-the-internet-imperva-research-labs-reveals-bot-traffic-climbs-to-record-high-in-2020/">a
large percentage of it
malicious</a>),
the content delivery network providers have needed to find ways to assurance
visitors are genuine. <a href="https://en.wikipedia.org/wiki/CAPTCHA">CAPTCHA</a>, in its
many forms, became popular with CDN operators despite being a “punish the good
ones” strategy. CAPTCHA also foils legitimate users who prefer less popular
browsers, those who use content filtering tools, those requiring access aids
and people using browsers built around Tor.
<a href="https://datatracker.ietf.org/wg/privacypass/about/">Privacy Pass</a> can be seen
as a genuinely user-friendly approach: once a real human has proved they’re a
real human, Privacy Pass leverages that proof around more of the Internet for a
longer duration of time. There are vestiges of OAuth/OAuth2 here - centralized
authorities control the issuance and verification of tokens - but the
protocol’s design prohibits the operators of Privacy Pass services from
learning the underlying behavior of its users (<em>request unlinkability is the
preferred term</em>).</p>
<p>Like MLS, Privacy Pass has both
<a href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-architecture/">architecture</a>
and
<a href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/">protocol</a>
specifications working their way toward standardization. Privacy Pass also
specifies the
<a href="https://datatracker.ietf.org/doc/DRAFT-ietf-privacypass-auth-scheme/">scheme</a>
by which issued tokens are presented to participating services. Not
standardized: the mechanism by which issuers of Privacy Pass tokens assure
humans are humans.</p>
<p>In June, Apple announced Private Access Tokens - its branded version of Privacy
Pass - in the iOS 16 and macOS Ventura beta releases. Apple says they are
supporting <a href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/">Privacy Pass
authentication</a> (with type 2 - blind
RSA - tokens) as defined in the <a href="https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/">protocol
draft</a>. The
Apple scheme requires Apple hardware and leverages Apple’s unique relationship
with its customers. Apple device owners with the newest operating system
releases can experiment with Private Access Tokens today - CDN providers
Cloudflare and Fastly have demonstration Privacy Pass token issuers to try. See
<a href="https://developer.apple.com/news/?id=huqjyh7k">here</a> and (especially)
<a href="https://developer.apple.com/videos/play/wwdc2022/10077/">here</a> for a complete
description. This is, of course, a major step forward for Privacy Pass. Will
Google be forced for follow suit on behalf of Android device owners?</p>
<h3 id="oblivious-http-now-oblivious-http-application-intermediation-ohai">Oblivious HTTP (now Oblivious HTTP Application Intermediation, OHAI)</h3>
<p>Oblivious- the watchword that seems to have infected all of IETF. <em>Oblivious</em>
is code for blinding a service provider’s view of the client’s IP address
behind a pair of trusted intermediary servers. The key predecessor ideas
underlying OHAI were published in June as RFC9230 - <a href="https://datatracker.ietf.org/doc/rfc9230/">Oblivious DNS over
HTTP</a>, an independent submission (by
Apple and others), brought forward as <em>experimental</em>, specifically for service
requests to the Domain Name Service. Well in advance of reaching publication
status, Oblivious DNS over HTTP raised a possibility: could <em>all</em> transactional
uses of HTTP (Online Certificate Status Protocol among them, perhaps browser
telemetry) be protected in this way? New work - Oblivious HTTP Application
Intermediation, OHAI - was chartered to bring concept of <em>obliviousness</em> to
this broader arena. The tortured name, by the way, is meant to reflect that web
browsing - whose usage pattern is more interactive than transaction - is
specifically not to be covered by this protocol definition.</p>
<p>The Working Group’s primary specification was given a much-needed refresh in
July, updating terminology and clarifying the scope and use cases for OHAI as
being <em>transactional</em>. It is believed by the Working Group - and, it seems, by
the broader IETF community, that privacy (and more specifically blinding of the
client’s IP address) is being handled by the MASQUE efforts (since proxies are
required to implement obliviousness, and MASQUE is all about proxies).</p>
<p>The major service providers have begun to field implementations for
interoperability testing.</p>
<h3 id="privacy-preserving-measurement-ppm">Privacy Preserving Measurement (PPM)</h3>
<p>Measurement seems a benign word - hard to imagine anyone getting worked up over
it. It’s possible to characterize almost all measurements taken on Internet
traffic as being good. But, too often, the stated requirements for measurement
hide the real and intended uses. Many people characterize the Internet of
today as a <em>surveillance economy</em>. Consumers have tried to fight back - with
particular support in the European Union - but with modest success. More
recently, however, state actors have begun using the surveillance economy as a
way to justify suppression of certain Internet services, particularly the most
popular media and social media outlets who are also the biggest contributors to
the mining and correlation of personal data for commercial use. With
livelihoods threatened, newer approaches to measure without surveilling were
needed. Enter <em>privacy-preserving measurement</em>.</p>
<p><a href="https://en.wikipedia.org/wiki/Differential_privacy">Differential Privacy</a> is
the approach being taken by IETF to address intrusive measurement.
Differential Privacy is a way to describe patterns within a dataset (say,
access to a website) without disclosing individual actors in the dataset.
However, the current state of play among the top data-harvesting firms is such
that individuals can be targeted even in the presence of early versions of this
technique. To solve these problems, <em>distributed aggregation</em> is being tried,
leveraging new mathematical techniques as well as some of the work mentioned
above (OHAI in particular). Two approaches -
<a href="https://eprint.iacr.org/2021/576.pdf">Prio</a> and
<a href="https://datatracker.ietf.org/doc/html/draft-dss-star">STAR</a> - are now being
considered. Based on Prio, the <a href="https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/">Distributed Aggregation Protocol for Privacy
Preserving Measurement</a>
was made an official working group document in May 2022. Mailing list
discussion now centers on initial interoperability testing - a step forward,
indicating more interested parties are willing to invest in implementations, at
least for study/research. This is especially pertinent because there are still
open theoretical questions about the actual privacy this solution can offer.</p>
<h2 id="smaller-standards-activities">Smaller standards activities</h2>
<h3 id="encrypted-client-hello-ech-formerly-encrypted-server-name-identifier-esni">Encrypted Client Hello (ECH) (formerly, Encrypted Server Name Identifier, ESNI)</h3>
<p>The need for encryption of the TLS protocol handshake is described in this <a href="https://blog.cloudflare.com/encrypted-client-hello/">excellent article</a> on
the Cloudflare blog:</p>
<blockquote>
<p>The most widely used cryptographic protocol for [exchanging encryption keys]
is the <a href="https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/">Transport Layer Security
(TLS)</a>
handshake. Today, a number of privacy-sensitive parameters of the TLS
connection are negotiated in the clear. This leaves a trove of metadata
available to network observers, including the endpoints’ identities, how they
use the connection, and so on.</p>
</blockquote>
<blockquote>
<p>ECH encrypts the full handshake so that this metadata is kept secret.
Crucially, this closes a long-standing privacy leak by protecting the Server
Name Indication (SNI) from eavesdroppers on the network. Encrypting the SNI
is important because it is the clearest signal of which server a given client
is communicating with. However, and perhaps more significantly, ECH also lays
the groundwork for adding future security features and performance
enhancements to TLS while minimizing their impact on the privacy of end
users.</p>
</blockquote>
<p><a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/">Draft 14</a> of the
Encrypted Client Hello specification was released in February. Though not all
specification features are closed, implementation work is underway. Perhaps the
most interesting effort is <a href="https://defo.ie/"><em>Developing ECH for OpenSSL
(DEfO)</em></a>. Guardian Project team members are involved in the
implementation and interoperability testing work done by this project. In
addition to making the changes in OpenSSL itself (a widely-used open source
software library implementing the TLS specification), key open source software
platforms that integrate OpenSSL - <a href="https://nginx.org/en/">nginx</a>,
<a href="https://httpd.apache.org/">apache2</a>, and <a href="https://www.haproxy.org/">haproxy</a>
among them - are also being modified. This is an excellent example of the
Internet Freedom community bringing some of its core expertise (implementation
of, and experience with, encryption) to the broader open source software
community (which, in many cases, is providing dominant software that underlies
most Internet applications).</p>
<h3 id="hpke">HPKE</h3>
<p>Since late 2018, the IETF and its companion research organizations have been
working very hard on updating the Internet’s pre-existing uses of cryptography
and applying new advances to modern protocol proposals and applications. Among
the major advances, the IETF’s <a href="https://www.rfc-editor.org/rfc/rfc9180.html">Hybrid Public Key Encryption
(HPKE)</a> was crowned a standard -
RFC9180 - in February. Cloudflare has an <a href="https://blog.cloudflare.com/hybrid-public-key-encryption/">excellent
summary</a> with
references. Many of the Internet Drafts I’ve cited in here depend on HPKE,
including Oblivious HTTP Application Intermediation and Messaging Layer
Security. TLS Encrypted Client Hello (ECH), above, is also dependent on HPKE.</p>
<h3 id="http-transport-authentication">HTTP Transport Authentication</h3>
<p>We mentioned that <em>HTTP Transport Authentication</em> was,
<a href="https://datatracker.ietf.org/doc/html/draft-schinazi-masque-00">originally</a>
(February 2019), called MASQUE. The specification is designed to authenticate
protocol flows in a manner that does not reveal any information to an attacker.
Therefore, applications using <em>HTTP Transport Authentication</em> are resistant to
active probing by network adversaries. However, the ideas originally expressed
got IETF’s creative juices flowing and, as above, a Working Group was formed to
define the standards around carrying all types of traffic (IP, UDP, and TCP)
over HTTP/3 and QUIC (and therefore leveraging QUIC’s many perceived benefits:
performance, congestion control and enhanced encryption). The HTTP Transport
Authentication draft languished while this effort was in high gear. With HTTP/3
Datagrams and CONNECT-UDP now standardized and CONNECT-IP ready for
interoperability testing, it was time to dust off this draft and build an
actual implementation.</p>
<p>At IETF113 in March, we picked up work originally done by one of our teammates
implementing <a href="https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html">draft #5</a>
of HTTP Transport Authentication and joined the
<a href="https://github.com/IETF-Hackathon/ietf113-project-presentations/blob/main/HTTP_Transport_Auth_ietf113.pdf">Hackathon</a>
with a project to get that code working on an updated environment and in a
testable way. We got the original code running in Google Conscrypt (TLS for
Java/Android), verified its function (as defined in the Internet Draft) and
created a public open source repository with a demonstration capability. We
presented the work to Hackathon attendees (~50 people) and discussed the work
with the specification’s author. Here’s our implementation
<a href="https://github.com/guardianproject/HTTPTransportAuthentication">repository</a>.</p>
<p>Subsequently, Guardian Project became a co-author of an updated <a href="https://datatracker.ietf.org/doc/draft-schinazi-httpbis-transport-auth/07/">draft #7</a>
of HTTP Transport Authentication which was
<a href="https://datatracker.ietf.org/meeting/114/materials/slides-114-httpbis-transport-authentication-00">presented</a>
at IETF114 in July to the HTTPbis Working Group, responsible for maintenance of
and extensions to the HTTP protocol. The Working Group requested minor
modifications to the draft which will subsequently be submitted for possible
adoption as a work item. The existence of an open source implementation along
with interest from the Internet Freedom community (in the form of participation
by the Guardian Project) could be important factors in the decision to proceed
with this work.</p>
<h2 id="opportunities-ahead">Opportunities ahead</h2>
<p>The IETF is fortunate to have gifted individuals from the Internet Freedom
community deeply involved, advocating for human rights in the design of the
Internet and assuring that specifications produced adhere to high standards of
security and privacy while becoming more accessible by people in challenging
economic and cultural situations. The effort undertaken here sought to create a
two-way street between the knowledge and expertise of the Internet Freedom
community and the IETF standards community for the benefit of both. The effort
indicates that there remains ample opportunity for the technical members of the
Internet Freedom community to extend their expertise into what has become an
increasingly-important niche within IETF: real-world experience with
implementing privacy and Internet Freedom technologies in the face of
entrenched adversaries, dominant service providers and recalcitrant
governments. Efforts like Encrypted Client Hello and HTTP Transport
authentication indicate that, based on the strong relationships already
developed (and partly due to the present project), technical activities by
members of the Internet Freedom community, within the IETF framework, can more
rapidly enhance the long-term benefits of IETF’s efforts for the citizens of
the Internet. Mountains from molehills, perhaps.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoIn our IETF series, we have contributions from David Oliver of Guardian Project. David has attended several IETF meetings, learning about new protocols that can help advance Pluggable Transports work and benefit censorship circumvention developers.Pluggable Transports September 2022 Meetup2022-09-27T00:00:00+00:002022-09-27T00:00:00+00:00https://pluggabletransports.info/blog/pt-meetup-sep2022<p>Hello, September’s Pluggable Transports meetup will take place on Thursday, September
29 at <a href="https://time.is/0200PM_29_September_2022_in_UTC?PT_meetup_September_29">2:00pm UTC</a>.</p>
<p>Please add any topics you would like to discuss during the meeting
<a href="https://pad.riseup.net/p/pt-meetup-keep">here</a>.</p>
<p>The meetup will take place on PT’s chat channel available on multiple networks.</p>
<p>Pick your favorite communication protocol and join us on:</p>
<ul>
<li><a href="https://matrix.to/#/#pluggable-transports:matrix.org">Matrix</a></li>
<li><a href="https://webchat.oftc.net/?channels=pluggable-transports">IRC (no account required)</a></li>
<li><a href="https://openobservatory.slack.com/messages/pluggable-transports/">Slack</a></li>
<li><a href="https://community.internetfreedomfestival.org/community/channels/pluggable-transport">Mattermost</a></li>
</ul>
<p>Hope to see many of you there!</p>
<p><strong>Date: Thursday, September 29, 2022</strong><br />
<strong>Time: 10:00 AM EDT / 16:00 PM CEST / 14:00 PM UTC</strong></p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoHello, September’s Pluggable Transports meetup will take place on Thursday, September 29 at 2:00pm UTC.Pop Up PTIM Session Recap: VPN censorship, Probes and Resilience: Building Feedback Loops with Open Data2022-09-20T00:00:00+00:002022-09-20T00:00:00+00:00https://pluggabletransports.info/blog/popup-ptim-ooni-recap<h1 id="pop-up-ptim-session-recap">Pop Up PTIM Session: RECAP</h1>
<h2 id="presented-by-ain-ghazal-icfp-ooni">Presented by Ain Ghazal ICFP @OONI</h2>
<p>Thank you to all those who attended the Pop Up PTIM! For those of you who
missed it or want to refresh your memory, here is a short recap of the
presentation.</p>
<p>This session was presented by Ain Ghazal, a fellow at the Open Observatory of
Network Interference, titled “VPN Censorship, Probes, and Resilience: Building
Feedback Loops with Open Data”.</p>
<p>The presentation focused on how OONI can help make VPNs better through OONI
probes and their world-wide network of volunteers, probing real-life networks.
Ghazal continued to explain the intricacies of this idea as well possible
setbacks such as adversaries having access to this kind of public information.</p>
<p>If you would like to learn more, you can view the presentation slides
<a href="/assets/slides/ain-vpn-censorship-probes-resilience.pdf">here</a>.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoPop Up PTIM Session: RECAPPluggable Transports July 2022 Meetup2022-07-25T00:00:00+00:002022-07-25T00:00:00+00:00https://pluggabletransports.info/blog/pt-meetup-jul2022<p>Hello, July’s Pluggable Transports meetup will take place on Thursday, July
28 at <a href="https://time.is/0200PM_28_July_2022_in_UTC?PT_meetup_July_28">2:00pm UTC</a>.</p>
<p>Please add any topics you would like to discuss during the meeting
<a href="https://pad.riseup.net/p/pt-meetup-keep">here</a>.</p>
<p>The meetup will take place on PT’s chat channel available on multiple networks.
Join us on:</p>
<ul>
<li><a href="https://matrix.to/#/#pluggable-transports:matrix.org">Matrix</a></li>
<li><a href="https://webchat.oftc.net/?channels=pluggable-transports">IRC (no account required)</a></li>
<li><a href="https://openobservatory.slack.com/messages/pluggable-transports/">Slack</a></li>
<li><a href="https://community.internetfreedomfestival.org/community/channels/pluggable-transport">Mattermost</a></li>
</ul>
<p>Hope to see many of you there!</p>
<p><strong>Date: Thursday, July 28, 2022</strong><br />
<strong>Time: 10:00 AM EDT / 16:00 PM CEST / 14:00 PM UTC</strong></p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoHello, July’s Pluggable Transports meetup will take place on Thursday, July 28 at 2:00pm UTC.Pop Up PTIM Session: VPN censorship, Probes and Resilience - Building Feedback Loops with Open Data2022-07-05T00:00:00+00:002022-07-05T00:00:00+00:00https://pluggabletransports.info/blog/popup-ptim-ooni-announcement-july22<h2 id="presented-by-ooni">Presented by OONI</h2>
<p>We are excited to announce the next Pop Up PTIM Session! These are stand alone
sessions, allowing the community to discuss PT related topics and stay up to
date on the progress of this community.</p>
<p>Our next session will be presented by members of the Open Observatory of
Network Interference (OONI). This presentation will cover the ongoing efforts
to incorporate protocol-aware VPN probes into the OONI ecosystem.</p>
<p>This session will cover:</p>
<ul>
<li>The high level goals of the project (quantify network interference with VPN
flows; both vanilla -which in principle is trivially fingerprintable- and
encrypted).</li>
<li>Which kind of data analysis pipelines and APIs can be useful to researchers,
protocol designers and service providers.</li>
<li>How the planned probes & experiments can be further enriched to capture
evolving realities in the circumvention arena.</li>
</ul>
<p>This session will take place on <strong>July 13th at 16:00 UTC/12:00 ET/18:00 CEST</strong>.
Please use <a href="https://cryptpad.fr/form/#/2/form/view/dWaOQCbEqzgIlAmPh8JhprzllYl+bHCt7NZ5ER2UwLg/">this link</a>
to register for the event. This takes no more than 2 minutes! You can expect to
receive log in details 24 hours prior to the event.</p>
<p>We are excited to see you all there!</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoPresented by OONIIETF April 2022 Monthly Report2022-06-30T00:00:00+00:002022-06-30T00:00:00+00:00https://pluggabletransports.info/blog/ietf-april2022-report<p>In our IETF series, we have contributions from David Oliver of <a href="https://guardianproject.info">Guardian
Project</a>. David has attended several
<a href="https://ietf.org">IETF</a> meetings, learning about new protocols that can help
advance Pluggable Transports work and benefit censorship circumvention
developers.</p>
<h2 id="april-2022-monthly-report">April 2022 Monthly Report</h2>
<p>By David Oliver of Guardian Project -
<a href="mailto:david@guardianproject.info">david@guardianproject.info</a></p>
<h2 id="masque">MASQUE</h2>
<p>The MASQUE Working Group reached consensus on both <a href="https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/">HTTP/3
Datagrams</a> and
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/">Connect-UDP</a>
during April, allowing higher-level review of these drafts before publication
as Recommendations. This is a major milestone since these two protocols
represent the core of the modern MASQUE ideas (together, allow proxying of both
QUIC and IP datagrams over HTTP connections). The
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/">Connect-IP</a>
draft will complete the vision: proxying of all types of IP-based traffic of
HTTP/3 (QUIC).</p>
<p>As we’ve said in our previous reports, we still hold out hope for <a href="https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html">HTTP
Transport
Authentication</a>,
though the draft has currently expired. The foremost reason for this is that
the author is now on the IETF’s Architecture Board and chairs two other working
groups.</p>
<p>A new MASQUE-related draft was created related to finding services in a MASQUE
environment -
<a href="https://sandbox.ietf.org/doc/draft-schwartz-masque-access-descriptions/">HTTP Access Service Description Objects</a>.
This draft describes how to find a MASQUE server if (1) software is starting
with an HTTP CONNECT proxy or (2) use of multiple services in combination (e.g.
CONNECT-UDP + CONNECT-IP + DoH + …) is required. According to the author, the
design could also serve as a building block for a solution to the key
consistency problem in Oblivious HTTP, described in Key Consistency for
Oblivious <a href="https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency-doublecheck/">HTTP by
Double-Checking</a>.</p>
<h2 id="messaging-layer-security-mls">Messaging Layer Security (MLS)</h2>
<p>The MLS Working Group submitted its call for consensus on draft #14 of the <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">MLS
protocol</a> document
on May 3, 2022. While this will likely get some “editorial” commentary, it
appears the technical content of this draft is ready for recommendation to IETF
as a standard.</p>
<p>A potential blocker: one of the Working Group chairs filed an <a href="https://datatracker.ietf.org/ipr/4015/">Intellectual
Property Rights disclosure</a> (as
procedure requires) on the protocol draft. The WG will have to deal with this
in list discussion or in an interim meeting, and come up with a formal
resolution/response if the draft is to proceed.</p>
<p>A virtual interim meeting on the protocol draft is scheduled for June 2, 2022.</p>
<h2 id="privacy-pass">Privacy Pass</h2>
<p>Two updated drafts have been released:</p>
<ol>
<li><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-protocol-04.html">draft-ietf-privacypass-protocol-04.txt</a>
and</li>
<li><a href="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-03.html">draft-ietf-privacypass-architecture-03.txt</a></li>
</ol>
<p>Mailing list discussion indicates there is still considerable work to do in
both areas, however Apple updated its draft <a href="https://datatracker.ietf.org/doc/draft-pauly-privacypass-auth-scheme/">Privacy Pass HTTP Authentication
Scheme</a>
(such a scheme is required for client interaction with the Privacy Pass
protocol). Does this seek to standardize work Apple has already experimented
with in its iCloud Private Relay? Pure speculation.</p>
<p>A new draft was submitted relating to work - discussed at IETF113 - on rate
limiting. <a href="https://www.ietf.org/archive/id/draft-privacypass-rate-limit-tokens-01.txt">Rate-Limited Token Issuance
Protocol</a>.</p>
<h2 id="oblivious-http-now-oblivious-http-application-intermediation-ohai">Oblivious HTTP (now Oblivious HTTP Application Intermediation, OHAI)</h2>
<p>As above, a new draft (<a href="https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency-doublecheck/">Key Consistency for Oblivious HTTP by
Double-Checking</a>)
was submitted to the OHAI working group after IETF113 discussion about the
relationship between key consistency and key discovery. The author felt it is
natural to combine discovery and consistency-checking, this draft exploring how
that could work. Note that this technique relies on the Oblivious Proxy also
being a MASQUE server, so that the client can fetch the KeyConfig from both the
proxy (providing consistency) and the origin (providing authenticity).
Interesting aggregation of technologies. This draft will provide room for
debate on at least some of the key-related issues in OHAI.</p>
<p>The core OHAI draft has not advanced further this month.</p>
<h2 id="privacy-preserving-measurement-ppm">Privacy Preserving Measurement (PPM)</h2>
<p>After what was thought to be a thorough (but many felt confusing)
<a href="https://datatracker.ietf.org/meeting/113/materials/slides-113-ppm-ppm-overview/">presentation</a>
on PPM at IETF113, and an <a href="https://datatracker.ietf.org/doc/draft-gpew-priv-ppm/01/">update to the original
draft</a> submitted
mid-month, a yet-newer draft has been submitted by the principals: <a href="https://www.ietf.org/archive/id/draft-ietf-ppm-dap-00.html">Distributed
Aggregation Protocol for Privacy Preserving
Measurement</a> to
replace those original submissions, after a lengthy discussion on the mailing
list. There is clearly a long way to go on this effort - the overall trust
model not being well understood nor (as a constituent problem) authentication
between parties.</p>
<h2 id="ietf114">IETF114</h2>
<p>IETF has announced that IETF114 will go forward as planned in Philadelphia PA,
July 25-29 2022 with the Hackathon running July 23-24. I will attend both
events.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoIn our IETF series, we have contributions from David Oliver of Guardian Project. David has attended several IETF meetings, learning about new protocols that can help advance Pluggable Transports work and benefit censorship circumvention developers.IETF 113 Hackathon2022-06-30T00:00:00+00:002022-06-30T00:00:00+00:00https://pluggabletransports.info/blog/ietf113-hackathon<p>In our IETF series, we have contributions from David Oliver of <a href="https://guardianproject.info">Guardian
Project</a>. David has attended several
<a href="https://ietf.org">IETF</a> meetings, learning about new protocols that can help
advance Pluggable Transports work and benefit censorship circumvention
developers.</p>
<h2 id="ietf113-hackathon-review">IETF113 Hackathon Review</h2>
<p>By David Oliver of Guardian Project -
<a href="mailto:david@guardianproject.info">david@guardianproject.info</a>, Hans-Christoph
Steiner of Guardian Project</p>
<p><strong>TL;DR</strong></p>
<ul>
<li>
<p><a href="https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html">Specification</a></p>
</li>
<li>
<p><a href="https://github.com/guardianproject/HTTPTransportAuthentication">Implementation Repo</a></p>
</li>
</ul>
<p>We picked up the work originally done by teammate Ali Hussain, got it running
in newest Google Conscrypt (TLS for Java/Android), verified its function and
created a public open source repository. We presented the work to Hackathon
attendees (~50 people), took questions from the general IETF community, and
discussed the work with the specification author.</p>
<h3 id="clarification">Clarification</h3>
<p>When we initiated our work in this area, it was called MASQUE (Multiplexed
Application Substrate over QUIC Encryption). The <a href="https://tools.ietf.org/id/draft-schinazi-masque-01.html">initial
draft</a> discussed the
mechanism we describe here, but also addressed some wider ideas. The draft
generated a lot of interest in the IETF Transport Area, a Working Group was
formed and a broad set of activities - all use cases for proxying over QUIC -
was taken on by that group. The working group decided to excise the specific
VPN use case – the one we’re most interested in – using a slightly different
proposal to be added to HTTP as an extension. That extension is called <em>HTTP
Transport Authentication</em>.</p>
<h3 id="why-http-transport-authentication">Why HTTP Transport Authentication?</h3>
<p><a href="https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html">HTTP Transport Authentication</a>
was proposed with modern HTTP use cases in mind - specifically those that don’t
follow the classic request/response model. WebTransport and MASQUE are examples
of protocols that leverage the advantages of HTTP but open durable and
sometimes interactive protocol flows with other servers. <em>HTTP Transport
Authentication</em> is designed to authenticate such protocol flows in a manner
that does not reveal any information to an attacker during failure cases.
Therefore, applications using <em>HTTP Transport Authentication</em> are resistant to
active probing by network adversaries. The specification describes two types of
authentication scheme (already common), but also supports extensions for
situations where novel authentication schemes are useful or required.</p>
<h3 id="how-does-http-transport-authentication-work">How does HTTP Transport Authentication Work?</h3>
<p><em>HTTP Transport Authentication</em> is defined as a new HTTP <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-5">Request
Header</a> valid for all
versions of HTTP. In HTTP/1.1, it is designed to accompany the
<a href="https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.6">CONNECT</a> method.
The client request arrives at the web server via HTTPS (HTTP over TLS) and,
thus, prior to HTTP protocol execution, an encrypted TLS session is available,
over which protocol messages flow. <em>HTTP Transport Authentication</em> uses
<a href="https://www.rfc-editor.org/rfc/rfc5705">RFC5705 Keying Material Exporters</a> to
extract a derivative encryption key from the TLS session, and uses the key to
symmetrically encrypt an authentication token presented with the CONNECT verb
in the form of a new HTTP header:</p>
<p><code class="language-plaintext highlighter-rouge">CONNECT server.example.com:443 HTTP/1.1</code><br />
<code class="language-plaintext highlighter-rouge">Host: server.example.com:443</code><br />
<code class="language-plaintext highlighter-rouge">Transport-Authorization: Signature a=AVAL; u=UVAL; p=PVAL(encrypted)</code></p>
<p>The web server receives this request, uses the same technique to extract the
same derivative key from the TLS session and uses the key to decrypt the P
value in the <em>Transport-Authorization</em> header. If the decrypted value - along
with the other information provided- matches an entry on the server side, the
server can be satisfied that this client is permitted to use a <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.6">proxied
connection through
it</a> to a
destination origin server. Failure cases - lack of a Transport-Authentication
header, improper encryption of the header, improper authentication information
or the request otherwise badly-formed - result in a generic error response
(<a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.5">405 Method Not
Allowed</a>). Network
entities actively probing the web server with badly-formed requests will also
receive this generic response - the standard response for web servers that
don’t offer CONNECT/proxying at all, making the host offering the service
“invisible” in all cases except the success case.</p>
<h2 id="implementation-details">Implementation Details</h2>
<p>The popular (and nearly ubiquitous) OpenSSL library - along with its Google
counterpart, BoringSSL - implements the function
<code class="language-plaintext highlighter-rouge">SSL_Export_Keying_Materials()</code> which itself implements the RFC5705 standard.
Many higher-level programming libraries and languages bind to one of these
implementations for their SSL/TLS support. Java (OpenJDK, Conscrypt, Cronet),
Go and Rust are examples. PyOpenSSL for Python binds to OpenSSL, as does
Python’s native SSL support, though the latter does not support this specific
method. Microsoft’s NSS library supports the function.</p>
<p><code class="language-plaintext highlighter-rouge">SSL_Export_Keying_Materials()</code> takes a string as input (officially, an
<a href="https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html#section-7.2">IANA-defined
entry</a>)
that it uses to create a derived key from the underlying TLS connection’s
master secret. This key, unique to the session, is used by the client to
encrypt an authentication token placed in a new HTTP header which the server
can decrypt with the same key derived in the same way from its underlying
connection. The server then matches that authentication token(s) provided
against its records before returning connection status.</p>
<h2 id="implementation">Implementation</h2>
<p>Based on earlier work, we wrote an implementation of the new header and its
handling without a complete proxied flow. In other words, the client will
attempt to CONNECT using this technique, the web server will process the
request (yielding failure or success) and immediately close the client’s
session. Our demonstration is written in Java (Conscrypt Java for Google
Android). Conscrypt itself is unchanged.</p>
<h3 id="possible-next-steps">Possible Next Steps</h3>
<p>An improved - more complete - demonstration would be beneficial. We do not have
the funding under this project to complete this work, however. We will explore
other opportunities in the Internet Freedom space. Should funding become
available, a logical next step is to implement the new function in Python, in
an existing open source proxy server. Two are easily available:</p>
<ol>
<li><a href="https://github.com/inaz2/proxy2">Proxy2 (Python)</a>, small codebase, simple
function:
<ul>
<li>First step would be to get this working with PyOpenSSL (to get the
keying material function)</li>
<li>Second step would be to add the HTTP TA function</li>
</ul>
</li>
<li><a href="https://github.com/swinkelhofer/python_proxy">Python Static and Reverse Proxy</a>,
slightly richer codebase (reverse proxy functions, too):
<ul>
<li>Same steps as above</li>
</ul>
</li>
</ol>
<h3 id="possible-consumers-of-this-capability">Possible Consumers of this Capability</h3>
<p>Viewed optimistically given its resistance to probing attacks, <em>HTTP Transport
Authentication</em> potentially turns every web server into a VPN tunnel in the
same way <em>Encrypted Client Hello</em> potentially turns every web server into a
domain front. Many parties implementing Pluggable Transports - VPN service
providers, for example - have likely developed special client verification
handshakes allowing only designated users and software access to their service
infrastructure. <em>HTTP Transport Authentication</em> might offer a standard and more
probe-resistant alternative that better “blends in” with standard web server
functions. Alternatively, the client and bridge components of the pluggable
transport itself could implement <em>HTTP Transport Authentication</em> “privately”
between them (using, for example, a private authentication scheme).</p>
<h3 id="discussion-with-the-author-of-the-internet-draft">Discussion with the Author of the Internet Draft</h3>
<p>As expected, the author noted that this work has been sidelined mostly for
personal reasons (too much other IETF responsibility including the MASQUE
Working Group, the WebTransport Working Group and the Internet Architecture
Board), but also because the definition of MASQUE has been fluid for two years
and the requirements of those protocol changes have not been fully understood.
As the MASQUE work comes to completion (2022), <em>HTTP Transport Authentication</em>
might see the light of day again in some modified form, to be decided. In the
meantime, the proposal stands as a published and available draft. Our work
provides a demonstration code base implementing it.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoIn our IETF series, we have contributions from David Oliver of Guardian Project. David has attended several IETF meetings, learning about new protocols that can help advance Pluggable Transports work and benefit censorship circumvention developers.IETF May 2022 Monthly Report2022-06-30T00:00:00+00:002022-06-30T00:00:00+00:00https://pluggabletransports.info/blog/may2022-ietf-report<p>In our IETF series, we have contributions from David Oliver of <a href="https://guardianproject.info">Guardian
Project</a>. David has attended several
<a href="https://ietf.org">IETF</a> meetings, learning about new protocols that can help
advance Pluggable Transports work and benefit censorship circumvention
developers.</p>
<h2 id="may-2022-monthly-report">May 2022 Monthly Report</h2>
<p>By David Oliver of Guardian Project -
<a href="mailto:david@guardianproject.info">david@guardianproject.info</a></p>
<h2 id="masque">MASQUE</h2>
<p>In April, the MASQUE Working Group reached consensus on both <a href="https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/">HTTP/3
Datagrams</a> and
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/">Connect-UDP</a>,
allowing higher-level review of these drafts before publication as Proposed
Standards. In May, two of those reviews are nearing completion, three more are
requested. Barring major issues - unexpected - these will close in June. As we
suggested in April, this is a major milestone since these two protocols
represent the core of the modern MASQUE ideas (together, allow proxying of both
QUIC and IP datagrams over HTTP connections).
<a href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/">Connect-IP</a> -
which will complete the vision - remains in its initial draft state while the
work above completes.</p>
<p>Here’s one I’ve missed: the second draft of <a href="https://datatracker.ietf.org/doc/draft-schwartz-masque-h3-datagram-ping/">HTTP Datagram PING and
TIMESTAMP</a>
was posted at the end of May. This draft defines new mechanisms for measuring
the functionality and performance of an HTTP Datagram path, matching protocol
artifacts already available for TCP measurement. These mechanisms can be used
with CONNECT-UDP, CONNECT-IP, or any other instantiation of the Capsule
Protocol from the HTTP/3 Datagrams design.</p>
<h2 id="messaging-layer-security-mls">Messaging Layer Security (MLS)</h2>
<p>As mentioned last month, draft #14 of the <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">MLS
protocol</a> document
was submitted for Working Group Last Call on May 3, 2022. A virtual interim
meeting on the protocol draft was held on May 26, 2022 and a number of issues
were raised and submitted as Github issues and <a href="https://datatracker.ietf.org/doc/minutes-interim-2022-mls-05-202205261000/">pull
requests</a>.
Many have now been resolved. During that meeting the protocol’s AppAck
extension was scheduled to be removed, in favor of a new generalized extensions
draft. This now exists as <a href="https://datatracker.ietf.org/doc/draft-robert-mls-extensions/">The Messaging Layer Security (MLS)
Extensions</a>.</p>
<p>Federation is back on the menu! Given <em>popular demand</em>, a slightly modernized
version of the original federation draft has been submitted, removing parts
that have become outdated in the intervening 2 years, and fleshed out existing
parts where more clarity now exists in the protocol draft itself. The author
states that this document merely gives a high-level overview and serves as a
starting point for discussion. It’s (currently) not a normative document so,
like the architecture document that kicked off the MLS protocol work, this
document could act as an umbrella document, referencing more other
more-concrete specifications. Here’s the new
<a href="https://datatracker.ietf.org/doc/draft-ietf-mls-federation/">draft</a>.</p>
<p>The Working Group agreed to update its milestones as well, putting some
pressure on themselves to finalize this work. The WG has decided to submit the
now-expired <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/">MLS
Architecture</a>
document as an Informational document (rather than a Proposed Standard) with
milestone of September 2022. The milestone for final submission of the <a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">MLS
Protocol</a> document
was also set at September 2022. This leaves one more IETF in-person meeting to
hash out the final details before submission for higher review.</p>
<h2 id="privacy-pass">Privacy Pass</h2>
<p>The core drafts were not updated in May, and there was limited discussion on
GitHub. <a href="https://www.ietf.org/archive/id/draft-privacypass-rate-limit-tokens-01.txt">Rate-Limited Token Issuance
Protocol</a>
was refreshed with a draft #2. Good thing! The latest change fixes a replay
attack in the issuance protocol. From the authors:</p>
<blockquote>
<p>The rate-limited issuance protocol is a three-party protocol between Client,
Attester, and Issuer. The input is a challenge from the Origin and the output
is a token bound to that Origin. We found an issue that would allow a malicious
Attester (or an attacker who compromises the Attester<>Issuer channel) to
replay a Client token request and receive a valid token response for a
different Origin.</p>
</blockquote>
<h2 id="oblivious-http-now-oblivious-http-application-intermediation-ohai">Oblivious HTTP (now Oblivious HTTP Application Intermediation, OHAI)</h2>
<p>Two drafts have been updated by the Working Group: <a href="https://datatracker.ietf.org/doc/draft-pauly-ohai-svcb-config/">Discovery of Oblivious
Services via Service Binding
Records</a>
(well-named!) and <a href="https://datatracker.ietf.org/doc/draft-rdb-ohai-feedback-to-proxy/">Oblivious Proxy
Feedback</a>
(feedback on rate-limiting, at least initially). These drafts flesh out the
original proposal to handle situations already arising in interop testing and
development.</p>
<p>The core OHAI draft has not advanced further this month. Frankly, I’m not sure
why this seems to have stalled.</p>
<h2 id="privacy-preserving-measurement-ppm">Privacy Preserving Measurement (PPM)</h2>
<p><a href="https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/">Distributed Aggregation Protocol for Privacy Preserving
Measurement</a> was made an
official working group document in early May. There are eleven new issues and
nine pull requests on this version of the document to date. Mailing list
discussion still centers on understanding the key ideas (as opposed to debating
the details).</p>
<p><a href="https://datatracker.ietf.org/doc/draft-dss-star/">STAR: Distributed Secret Sharing for Private Threshold Aggregation
Reporting</a>, initially
submitted in March, offers a different approach to solving the same problem.</p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoIn our IETF series, we have contributions from David Oliver of Guardian Project. David has attended several IETF meetings, learning about new protocols that can help advance Pluggable Transports work and benefit censorship circumvention developers.Pluggable Transports June 2022 Meetup2022-06-24T00:00:00+00:002022-06-24T00:00:00+00:00https://pluggabletransports.info/blog/pt-meetup-jun2022<p>Hello, June’s Pluggable Transports meetup will take place on Tuesday, June
28 at <a href="https://time.is/0200PM_28_June_2022_in_UTC?PT_meetup_June_28">2:00pm UTC</a>.</p>
<p>Please add any topics you would like to discuss during the meeting
<a href="https://pad.riseup.net/p/pt-meetup-keep">here</a>.</p>
<p>The meetup will take place on PT’s chat channel available on multiple networks.
Join us on:</p>
<ul>
<li><a href="https://matrix.to/#/#pluggable-transports:matrix.org">Matrix</a></li>
<li><a href="https://webchat.oftc.net/?channels=pluggable-transports">IRC (no account required)</a></li>
<li><a href="https://openobservatory.slack.com/messages/pluggable-transports/">Slack</a></li>
<li><a href="https://community.internetfreedomfestival.org/community/channels/pluggable-transport">Mattermost</a></li>
</ul>
<p>Hope to see many of you there!</p>
<p><strong>Date: Tuesday, June 28, 2022</strong><br />
<strong>Time: 10:00 AM EDT / 16:00 PM CEST / 14:00 PM UTC</strong></p>{"name"=>nil, "avatar"=>"/assets/images/ptavatar.png", "bio"=>nil, "location"=>nil, "email"=>"contact@pluggabletransports.info", "uri"=>nil, "bitbucket"=>nil, "codepen"=>nil, "dribbble"=>nil, "flickr"=>nil, "facebook"=>nil, "foursquare"=>nil, "github"=>nil, "google_plus"=>nil, "keybase"=>nil, "instagram"=>nil, "lastfm"=>nil, "linkedin"=>nil, "pinterest"=>nil, "soundcloud"=>nil, "stackoverflow"=>nil, "steam"=>nil, "tumblr"=>nil, "twitter"=>"plugtransports", "vine"=>nil, "weibo"=>nil, "xing"=>nil, "youtube"=>"https://www.youtube.com/channel/UCzJGT8SUVi2_j-qUm6BtZUA/"}contact@pluggabletransports.infoHello, June’s Pluggable Transports meetup will take place on Tuesday, June 28 at 2:00pm UTC.