<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Standards on Guardian Project</title>
    <link>https://guardianproject.info/categories/standards/</link>
    <description>Recent content in Standards on Guardian Project</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sun, 12 Apr 2026 04:04:30 +0000</lastBuildDate>
    <atom:link href="https://guardianproject.info/categories/standards/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>IETF119 Conference Report: Monday March 18, 2024</title>
      <link>https://guardianproject.info/2024/03/18/ietf119-conference-report-monday-march-18-2024/</link>
      <pubDate>Mon, 18 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2024/03/18/ietf119-conference-report-monday-march-18-2024/</guid>
      <description>&lt;p&gt;&lt;em&gt;It&amp;rsquo;s Opening Day of the &lt;a href=&#34;https://www.ietf.org/how/meetings/119/&#34;&gt;119th IETF meeting&lt;/a&gt; in Brisbane Australia.  This post commences a daily rundown of privacy and Internet Freedom activities at this IETF meeting. For the rundown on IETF119 Hackathon, see my &lt;a href=&#34;https://guardianproject.info/2024/03/17/ietf119-hackathon-report/&#34;&gt;Hackathon report&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;&#xA;&lt;h2 id=&#34;dispatch&#34;&gt;Dispatch&lt;/h2&gt;&#xA;&lt;p&gt;IETF meetings don&amp;rsquo;t often kick off with the open dispatch but this time it happened. Dispatch sessions are meant to help specification authors find a home for their work if a home isn&amp;rsquo;t obvious. There are two classes of dispatch request:&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF119 Conference Report: Hackathon March 17, 2024</title>
      <link>https://guardianproject.info/2024/03/17/ietf119-conference-report-hackathon-march-17-2024/</link>
      <pubDate>Sun, 17 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2024/03/17/ietf119-conference-report-hackathon-march-17-2024/</guid>
      <description>&lt;p&gt;&lt;em&gt;Hackathon Weekend at the &lt;a href=&#34;https://www.ietf.org/how/meetings/119/&#34;&gt;119th IETF meeting&lt;/a&gt; in Brisbane Australia.  This post commences a daily rundown of privacy and Internet Freedom activities at this IETF meeting.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;IETF&amp;rsquo;s Hackathon, held at each face-to-face IETF meeting, is designed to encourage interoperability testing of standards under development. See this meeting&amp;rsquo;s wiki page for a description of&lt;a href=&#34;https://wiki.ietf.org/en/meeting/119/hackathon&#34;&gt;this year&amp;rsquo;s twenty-four projects&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-auth/&#34;&gt;The HTTP Signature Authentication Scheme&lt;/a&gt; has been winding its way through the &lt;a href=&#34;https://datatracker.ietf.org/wg/httpbis/charter/&#34;&gt;HTTPbis Working Group&lt;/a&gt; since being adopted as a Working Group draft in July 2022. This work proposes a mechanism by which HTTP servers can offer authenticated resources without telegraphing they do so (thus resisting probing attacks).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF116 Conference Report: Friday March 31, 2023</title>
      <link>https://guardianproject.info/2023/04/04/ietf116-conference-report-friday-march-31-2023/</link>
      <pubDate>Tue, 04 Apr 2023 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2023/04/04/ietf116-conference-report-friday-march-31-2023/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Five of the &lt;a href=&#34;https://www.ietf.org/how/meetings/116/&#34;&gt;116th IETF meeting&lt;/a&gt; in Yokohama Japan.  For the rundown on Day Four, see my &lt;a href=&#34;https://guardianproject.info/2023/03/30/ietf116-conference-report-thursday-march-30-2023/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;With a lot of focus on privacy with respect to Internet protocols, novel new cryptography schemes are an important requirement for new protocol designs.  For example, &lt;a href=&#34;https://datatracker.ietf.org/wg/ppm/about/&#34;&gt;Privacy Preserving Measurement&lt;/a&gt; is relying on new cryptography to support distributed aggregation of a wide range of measurements in the advertising domain as well as application telemetry.  &lt;a href=&#34;https://datatracker.ietf.org/wg/privacypass/about/&#34;&gt;Privacy Pass&lt;/a&gt; is relying on new cryptography to allow web browsing across the broad Internet after a single, lightweight authentication to an authority.  IETF Working Groups are encouraged to work with the &lt;a href=&#34;https://irtf.org/cfrg&#34;&gt;Crypto Forum Research Group&lt;/a&gt; of the Internet Research Task Force (&lt;a href=&#34;https://www.ietf.org/about/groups/irtf/&#34;&gt;IRTF&lt;/a&gt;) to develop, test and refine new cryptography techniques that meet defined security/privacy goals and can scale for Internet-wide use.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF116 Conference Report: Thursday March 30, 2023</title>
      <link>https://guardianproject.info/2023/03/30/ietf116-conference-report-thursday-march-30-2023/</link>
      <pubDate>Thu, 30 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2023/03/30/ietf116-conference-report-thursday-march-30-2023/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Four of the &lt;a href=&#34;https://www.ietf.org/how/meetings/116/&#34;&gt;116th IETF meeting&lt;/a&gt; in Yokohama Japan.  For the rundown on Day Three, see my &lt;a href=&#34;https://guardianproject.info/2023/03/30/ietf116-conference-report-wednesday-march-29-2023/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;The IETF is getting serious about interoperability among messaging services (&lt;a href=&#34;https://www.eff.org/deeplinks/2022/04/eu-digital-markets-acts-interoperability-rule-addresses-important-need-raises&#34;&gt;this&lt;/a&gt; might have had something to do with it).  The charter for the Messaging Layer Security Working Group (MLS) specifically &lt;em&gt;excluded&lt;/em&gt; interoperability, though the group organized a draft that addressed the basic concepts that would allow MLS-compatible systems to federate. In early 2023, a new Working Group - More Instant Messaging Interoperability (&lt;a href=&#34;https://datatracker.ietf.org/group/mimi/about/&#34;&gt;MIMI&lt;/a&gt;) - was chartered to expand on the MLS federation work.  Given IETF&amp;rsquo;s relatively long and somewhat checkered history with messaging, the Working Group&amp;rsquo;s charter included this reminder to itself:&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF116 Conference Report: Wednesday March 29, 2023</title>
      <link>https://guardianproject.info/2023/03/30/ietf116-conference-report-wednesday-march-29-2023/</link>
      <pubDate>Thu, 30 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2023/03/30/ietf116-conference-report-wednesday-march-29-2023/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Three of the &lt;a href=&#34;https://www.ietf.org/how/meetings/116/&#34;&gt;116th IETF meeting&lt;/a&gt; in Yokohama Japan.  For the rundown on Day Two, see my &lt;a href=&#34;https://guardianproject.info/2023/03/29/ietf116-conference-report-tuesday-march-29-2023/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;The long-running work on &lt;a href=&#34;https://datatracker.ietf.org/wg/masque/about/&#34;&gt;MASQUE&lt;/a&gt; - proxying all network-layer datatypes over QUIC (HTTP/3) - is nearing completion, with the specification for &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/&#34;&gt;Proxying IP in HTTP&lt;/a&gt; in IESG review.  With these components in place, the &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-schinazi-masque-proxy/&#34;&gt;original MASQUE concept&lt;/a&gt; - a non-probable relay for client traffic providing privacy guarantees - has been revived, now defined within the new framework and leveraging &lt;a href=&#34;https://www.ietf.org/archive/id/draft-ietf-httpbis-unprompted-auth-02.html&#34;&gt;HTTP Unprompted Authentication&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF116 Conference Report: Tuesday March 28, 2023</title>
      <link>https://guardianproject.info/2023/03/29/ietf116-conference-report-tuesday-march-28-2023/</link>
      <pubDate>Wed, 29 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2023/03/29/ietf116-conference-report-tuesday-march-28-2023/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Two of the &lt;a href=&#34;https://www.ietf.org/how/meetings/116/&#34;&gt;116th IETF meeting&lt;/a&gt; in Yokohama Japan.  For the rundown on Day One, see my &lt;a href=&#34;https://guardianproject.info/2023/03/28/ietf116-conference-report-monday-march-28-2023/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://datatracker.ietf.org/wg/ohai/about/&#34;&gt;OHAI Working Group&lt;/a&gt; has submitted the core draft of &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/&#34;&gt;Oblivious HTTP Application Intermediation&lt;/a&gt; to the RFC Editor for editorial finalization and publication. OHAI is designed to support &lt;em&gt;transational&lt;/em&gt; uses of the HTTP protocol that seek IP address privacy (by means of a relay pair, one associated with the client and one associated with the target resource). The target resource is, thus, said to be &lt;em&gt;oblivious&lt;/em&gt; to the requester&amp;rsquo;s IP address.  While the initially-imagined use case for OHAI was access to the DNS service (with some in the IETF feeling DNS-over-HTTP did not go far enough to protect user privacy), the dominant  use case imagined today is &lt;em&gt;telemetry&lt;/em&gt; - monitoring vendor-, application- or operating system-defined usage parameters on centralized systems.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF116 Conference Report: Monday March 27, 2023</title>
      <link>https://guardianproject.info/2023/03/28/ietf116-conference-report-monday-march-27-2023/</link>
      <pubDate>Tue, 28 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2023/03/28/ietf116-conference-report-monday-march-27-2023/</guid>
      <description>&lt;p&gt;&lt;em&gt;This post begins a daily blog, live from the 116th meeting of the &lt;a href=&#34;https://www.ietf.org/how/meetings/116/&#34;&gt;Internet Engineering Task Force&lt;/a&gt; in Yokohama, Japan, March 25-31, 2023.  We&amp;rsquo;re focusing on standards activities of importance to the Internet Freedom community.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;Since IETF114 (&lt;a href=&#34;https://guardianproject.info/2022/07/28/ietf114-conference-report-thursday-july-28-2022/&#34;&gt;report&lt;/a&gt;), the &lt;a href=&#34;https://datatracker.ietf.org/wg/ppm/about/&#34;&gt;Privacy Preserving Measurement Working Group&lt;/a&gt; has been deliberating over two distinct proposals offering very different technical methodologies for undertaking measurement activities while respecting user privacy. &lt;a href=&#34;https://datatracker.ietf.org/doc/html/draft-dss-star&#34;&gt;STAR&lt;/a&gt; offers an approach called &lt;em&gt;k-anonymity&lt;/em&gt; - reporting a measurement value only if &lt;em&gt;k&lt;/em&gt; or more parties are also reporting the same value. This approach theoretically prevents rare values being used to single-out individuals.  Distributed Aggregation Protocol, &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/&#34;&gt;DAP&lt;/a&gt;, uses an approach that distributes individual measures across a set of aggregators, none of which gets to see all the granular measurement data - the fully-aggregated total only seen by the third-party who requested it (who, in turn, gets to see none of the granular measurements).  At IETF116 we&amp;rsquo;re learning about the operational experience with these technologies, with multiple implementations of both running in different testbeds.  &lt;a href=&#34;https://datatracker.ietf.org/meeting/116/materials/slides-116-ppm-poplarstar-measurements&#34;&gt;Performance analysis&lt;/a&gt; has also been undertaken.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Conference Report: Friday July 29, 2022</title>
      <link>https://guardianproject.info/2022/07/29/ietf114-conference-report-friday-july-29-2022/</link>
      <pubDate>Fri, 29 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/29/ietf114-conference-report-friday-july-29-2022/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Five of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;114th IETF meeting&lt;/a&gt; in Philadelphia USA. For the rundown on Day Four, see my &lt;a href=&#34;https://guardianproject.info/2022/07/28/ietf114-conference-report-thursday-july-28-2022/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;A quiet day today with only the &lt;a href=&#34;https://datatracker.ietf.org/wg/mls/charter/&#34;&gt;Messaging Layer Security&lt;/a&gt; Working Group holding its session. Draft 16 of the &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/&#34;&gt;MLS protocol&lt;/a&gt; completed last-call in mid-July and has been submitted for review after significant technical and editorial feedback from the working group. Are we getting close (again)?  The &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/&#34;&gt;MLS Architecture&lt;/a&gt; document was lightly revised and version 8 submitted for review.  Two new drafts were presented: &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-mahy-mls-content-neg/&#34;&gt;MLS Content Negotiation&lt;/a&gt; and &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-robert-mls-extensions/&#34;&gt;MLS Extensions&lt;/a&gt;. The former has yet to be adopted as a Working Group item, but the latter was adopted during IETF114 (before the MLS session, over the mailing list).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Conference Report: Thursday July 28, 2022</title>
      <link>https://guardianproject.info/2022/07/28/ietf114-conference-report-thursday-july-28-2022/</link>
      <pubDate>Thu, 28 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/28/ietf114-conference-report-thursday-july-28-2022/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Four of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;114th IETF meeting&lt;/a&gt; in Philadelphia USA. For the rundown on Day Three, see my &lt;a href=&#34;https://guardianproject.info/2022/07/27/ietf114-conference-report-wednesday-july-27-2022/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;At IETF112 (online) a formal Birds of a Feather (BoF) session was held on the concept of &lt;a href=&#34;https://datatracker.ietf.org/meeting/112/materials/slides-112-priv-chair-slides-agenda-01&#34;&gt;Privacy Preserving Measurement&lt;/a&gt;.  A Working Group was &lt;a href=&#34;https://datatracker.ietf.org/wg/ppm/about/&#34;&gt;chartered&lt;/a&gt; and, at IETF113 in Vienna, we were treated to an incredibly detailed presentation on &lt;a href=&#34;https://eprint.iacr.org/2021/576.pdf&#34;&gt;Prio&lt;/a&gt;, an academic concept for supporting privacy in the context of Internet-scale measurement. Quickly following that presentation was an IETF proposal for a &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/&#34;&gt;defined protocol&lt;/a&gt; for &lt;em&gt;distributed aggregation&lt;/em&gt; of measurement data, based on Prio&amp;rsquo;s core concepts and using a range of cryptographic and system architecture techniques to separate measurements from the identities of the human users being measured.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Conference Report: Wednesday July 27, 2022</title>
      <link>https://guardianproject.info/2022/07/27/ietf114-conference-report-wednesday-july-27-2022/</link>
      <pubDate>Wed, 27 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/27/ietf114-conference-report-wednesday-july-27-2022/</guid>
      <description>&lt;p&gt;*Day Three of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;114th IETF meeting&lt;/a&gt; in Philadelphia USA. For the rundown on Day Two, see my &lt;a href=&#34;https://guardianproject.info/2022/07/26/ietf114-conference-report-tuesday-july-26-2022/&#34;&gt;daily report&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Interest is starting to consolidate on the need for additional definition for serving media over the QUIC transport layer, particularly for streaming and conferencing applications.  Following an informal gathering at IETF113 in March 2022, a formal Birds of Feather session met today with a draft &lt;a href=&#34;https://datatracker.ietf.org/meeting/114/materials/slides-114-moq-moq-charter-proposal-00&#34;&gt;charter proposal&lt;/a&gt; and two draft documents describing the intended &lt;a href=&#34;https://www.ietf.org/id/draft-gruessing-moq-requirements-02.html&#34;&gt;use cases&lt;/a&gt; and a &lt;a href=&#34;https://www.ietf.org/id/draft-jennings-moq-quicr-proto-01.html&#34;&gt;protocol&lt;/a&gt;. &lt;a href=&#34;https://datatracker.ietf.org/meeting/114/materials/slides-114-moq-if-time-permits-quicr-01&#34;&gt;Here&amp;rsquo;s&lt;/a&gt; a more visual overview.  There was broad concensus (at this well-attended session) as to the need for this work, but a split between one camp that sought a much narrower set of use cases (not wanting to &lt;em&gt;boil the Internet&lt;/em&gt; as it were) and another who wanted to &lt;em&gt;solve this problem once&lt;/em&gt;. This will be addressed as the BoF leaders work towards a vote on chartering the effort.  Either way, this is substantial work ahead.  I mention this here not so much in the realm of privacy as to look towards a future where QUIC&amp;rsquo;s efficiency and scalability benefits might make media-rich services available to those of lesser economic means or with mediocre connectivity.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Conference Report: Tuesday July 26, 2022</title>
      <link>https://guardianproject.info/2022/07/26/ietf114-conference-report-tuesday-july-26-2022/</link>
      <pubDate>Tue, 26 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/26/ietf114-conference-report-tuesday-july-26-2022/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day Two of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;114th IETF meeting&lt;/a&gt; in Philadelphia USA. For the rundown on Day One, see my &lt;a href=&#34;https://guardianproject.info/2022/07/25/ietf114-conference-report-monday-july-25-2022/&#34;&gt;daily report&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;Lucas Pardue, of Cloudflare and co-chair of the QUIC Working Group, gave a not-so-tongue-in-cheek &lt;a href=&#34;https://datatracker.ietf.org/meeting/114/materials/slides-114-anrw-sessa-keynote-00&#34;&gt;talk&lt;/a&gt; about the breakdown of the OSI layering model of the Internet. His focus was on the &lt;em&gt;top&lt;/em&gt; of the stack, illustrating handsomely what QUIC and HTTP/3 have done (unknowingly to most) to our perception of layers.  A key challenge: tools for HTTP/1 are widely available and the protocol and its impacts are widely understood.  HTTP/2 and HTTP/3? Not so much (both are binary, not text-based, protocols).  Yet, here in mid-2022, the world of the Internet is predominantly (91%!) HTTP/2 and HTTP/3 traffic.  Similarly, TLS/1.3 and QUIC represent 87% of traffic. And many of the now-being-standardized protocols for privacy insert several layers of proxy into every transaction. From a &lt;em&gt;sound knowledge&lt;/em&gt; perspective, we seem to have taken a rather quick, and rather deep, step backwards.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Conference Report: Monday July 25, 2022</title>
      <link>https://guardianproject.info/2022/07/25/ietf114-conference-report-monday-july-25-2022/</link>
      <pubDate>Mon, 25 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/25/ietf114-conference-report-monday-july-25-2022/</guid>
      <description>&lt;p&gt;&lt;em&gt;Day One of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;114th IETF meeting&lt;/a&gt; in Philadelphia USA.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;With privacy a key consideration in new protocol design, cryptography has become a major focus of IETF activities.  The Internet Research Task Force (IRTF) has the &lt;a href=&#34;https://irtf.org/cfrg&#34;&gt;Crypto Forum Research Group&lt;/a&gt; where new cryptography schemes are brought forward and vetted for use in IETF protocols.  Well, &lt;em&gt;new&lt;/em&gt; is a misnomer. Much of the mathematics has long been defined, at least at its core, and the work is rather being brought into the IETF context where important engineering considerations apply: use of memory (at rest or in flight), processing required, round-trips required, etc.. Of significance at this meeting, mechanisms for &lt;em&gt;blinding&lt;/em&gt; a digitial signature are in high demand given the prevalence of multi-tiered approaches to privacy (that is, approaches that insert one or more proxies between entities in a transaction).  Something similar is in the works for cryptographic keys. A number of IETF protocol specifications, still in development, are in line to receive these mathematical gems including &lt;a href=&#34;https://datatracker.ietf.org/group/privacypass/about/&#34;&gt;Privacy Pass&lt;/a&gt;, &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-private-access-tokens/&#34;&gt;Private Access Tokens&lt;/a&gt;, &lt;a href=&#34;https://datatracker.ietf.org/wg/ohai/charter/&#34;&gt;Oblivious HTTP Application Intermediation&lt;/a&gt; and others.  An excellent summary of the National Institute for Standards and Technology (NIST) &lt;a href=&#34;https://csrc.nist.gov/publications/detail/nistir/8413/final&#34;&gt;Post-Quantum Cryptography &lt;em&gt;contest&lt;/em&gt;&lt;/a&gt; was also provided. The topic itself, let alone the solutions chosen, is not for the weak-kneed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF114 Hackathon Report: Sunday July 24, 2022</title>
      <link>https://guardianproject.info/2022/07/24/ietf114-hackathon-report-sunday-july-24-2022/</link>
      <pubDate>Sun, 24 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/07/24/ietf114-hackathon-report-sunday-july-24-2022/</guid>
      <description>&lt;p&gt;&lt;em&gt;This post begins a daily blog, live from the 114th meeting of the &lt;a href=&#34;https://www.ietf.org/how/meetings/114/&#34;&gt;Internet Engineering Task Force&lt;/a&gt; in Philadelpha Pennsylvania USA, July 23-29, 2022 (in-person meetings having restarted in March 2022 after the COVID pandemic abated). We&amp;rsquo;re focusing on standards activities of importance to the Internet Freedom community.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://www.ietf.org/how/runningcode/hackathons/114-hackathon/&#34;&gt;Hackathon&lt;/a&gt; event kicks off each IETF event, with projects that run the gamut from early implementations of just-emerging specifications to full multi-vendor interoperability testing of nearly-mature protocols. At this event, I sat in on the &lt;a href=&#34;https://datatracker.ietf.org/wg/masque/about/&#34;&gt;MASQUE&lt;/a&gt; team&amp;rsquo;s effort to commence work on the new &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/&#34;&gt;CONNECT-IP&lt;/a&gt; specification. With the recent completion of two key specifications -  &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/&#34;&gt;CONNECT-UDP&lt;/a&gt; and &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/&#34;&gt;H3 Datagrams&lt;/a&gt; - MASQUE has become IETF&amp;rsquo;s solution for proxying all types of network traffic over QUIC and HTTP/3, including VPN and other privacy-focused scenarios. CONNECT-IP will complete the trio.  But this initial effort didn&amp;rsquo;t go well.  Google and Ericcson (co-authors on the spec) had brought teams who, indeed, implemented the key protocol elements of CONNECT-IP live and in-the-moment but were both stymied setting up testbeds that could deliver raw IP packets for routing by this new code. Wait, you might say, aren&amp;rsquo;t these network engineers?  True, but it was mostly the practicalities that got in the way - only laptops as test machines, working from the open source &lt;a href=&#34;https://github.com/google/quiche&#34;&gt;QUICHE&lt;/a&gt; repository on a machine that also hosts an environment for building production code, even deciding what sort of packets could be used for testing and where to route them. These are the frustrations of a first-ever effort.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Conference Report: Friday March 25, 2022</title>
      <link>https://guardianproject.info/2022/03/28/ietf113-conference-report-friday-march-25-2022/</link>
      <pubDate>Mon, 28 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/28/ietf113-conference-report-friday-march-25-2022/</guid>
      <description>&lt;p&gt;Final day of the 113th IETF meeting, in Vienna Austria.&lt;/p&gt;&#xA;&lt;p&gt;The IETF is looking to make a clear contribution to the problem of hyper-aggressive measurement of user activities on the Internet and the many misuses thereof.  To do so, the IETF recognizes that some measurement is important but that many desirable measurements require data most people consider sensitive.  It also recognizes that aggregated measurements often provide the most value, rather than individual ones.  Yet, today, parties interested in measurement need to collect and store individual records in order to aggregate them, exposing themselves to potential violations of their privacy agreements with users (or governments) and to theft of that data by outsiders.  Instead, IETF is looking at ways this aggregation can be managed in ways that protect user privacy while still providing much of the statistical power needed.  The &lt;a href=&#34;https://datatracker.ietf.org/group/ppm/about/&#34;&gt;Privacy Preserving Measurement Working Group&lt;/a&gt; has formed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Conference Report: Thursday March 24, 2022</title>
      <link>https://guardianproject.info/2022/03/27/ietf113-conference-report-thursday-march-24-2022/</link>
      <pubDate>Sun, 27 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/27/ietf113-conference-report-thursday-march-24-2022/</guid>
      <description>&lt;p&gt;Day four of the 113th IETF meeting, in Vienna Austria.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://datatracker.ietf.org/group/privacypass/about/&#34;&gt;Privacy Pass&lt;/a&gt; - originating at Cloudflare in 2017 as a solution to user frustration with CAPTCHA - has been in full swing as an IETF activity since mid-2020.  Privacy Pass allows a client to solve some form of validity check (a CAPTCHA, a puzzle, a user-pass authentication) to then receive some number of tokens to be used at websites accepting Privacy Pass, thus eliminating the need to do a CAPTCHA at each site.  Sites hosted on large CDNs like Cloudflare benefit (Cloudflare provides the service for them) and users get a more convenient experience.  Users accessing the Internet through Tor are even more positively affected since they are most prone to CAPTCHA.  Privacy Pass is now in Version 3 and working to support a multi-issuer environment to provide another uplift to the user experience (tokens can be validated across issuers).  Just prior to this IETF meeting, a standardized mechanism for exchanging Privacy Pass tokens was adopted by the Working Group - &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/&#34;&gt;The Privacy Pass HTTP Authentication Scheme&lt;/a&gt;. Both request and response mechanisms are provided so that use of (or demand for) the token can be either server- or client-initiated. Going forward, it will be interesting to see if Privacy Pass benefits mostly the web browsing environment or finds its way into applications using HTTP as a substrate for richer styles of interaction.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Conference Report: Wednesday March 23, 2022</title>
      <link>https://guardianproject.info/2022/03/26/ietf113-conference-report-wednesday-march-23-2022/</link>
      <pubDate>Sat, 26 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/26/ietf113-conference-report-wednesday-march-23-2022/</guid>
      <description>&lt;p&gt;Day three of the 113th IETF meeting, in Vienna Austria.&lt;/p&gt;&#xA;&lt;p&gt;Messaging Layer Security (&lt;a href=&#34;https://datatracker.ietf.org/wg/mls/about/&#34;&gt;MLS&lt;/a&gt;) is (finally) closing in on &lt;a href=&#34;https://www.ietf.org/about/glossary/?query=wglc&#34;&gt;Last Call&lt;/a&gt; at protocol Draft 14 and architecture Draft 7 (which will be taken forward together). Sometimes referred to as the &lt;em&gt;TLS for messaging systems&lt;/em&gt;, Messaging Layer Security creates a uniform secure group discussion protocol, scalable to very large groups and providing similarly uniform security guarantees across providers. The near completion of the architecture and protocol drafts, and commencement of interoperability testing has prompted the Working Group to dust off the &lt;a href=&#34;https://datatracker.ietf.org/doc/html/draft-ietf-mls-federation&#34;&gt;Federation draft&lt;/a&gt; as the next object of their affection.  Will I be able to connect my &lt;a href=&#34;https://wire.com/en/&#34;&gt;Wire&lt;/a&gt; client to the &lt;a href=&#34;https://www.messenger.com/&#34;&gt;Facebook Messenger&lt;/a&gt; server? Don&amp;rsquo;t hold your breath, but in the meantime you&amp;rsquo;ll be able to enjoy the manifest benefits of secure group chat (with security guarantees as high as the industry knows how to produce) on your own network.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Conference Report: Tuesday March 22, 2022</title>
      <link>https://guardianproject.info/2022/03/24/ietf113-conference-report-tuesday-march-22-2022/</link>
      <pubDate>Thu, 24 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/24/ietf113-conference-report-tuesday-march-22-2022/</guid>
      <description>&lt;p&gt;Day two of the &lt;a href=&#34;https://www.ietf.org/how/meetings/113/&#34;&gt;113th IETF meeting&lt;/a&gt;, in Vienna Austria.  The crisis in Ukraine is on everyone&amp;rsquo;s mind, lending immediacy to the work of the Global Access to the Internet for All (GAIA) Research Group. While past and continuing work has focused on Internet access for the world&amp;rsquo;s population (especially those disadvantaged by economics, distance, mobility, and social constraints) the situation in Ukraine resulting from military activities give cause for both concern and hope.  While communications access points have been obviously targeted, the inherently decentralized topology of the Internet infrastructure in Ukraine has afforded surprising resiliency, increased by the willingness of nominal competitors to patch the communication systems back together for the good of all.  Few will remember that this resiliency from military attack was the raison d&amp;rsquo;être for ARPANet, predecessor to the Internet.  Perhaps, in this era of increasing centralization (hardware and software), the crisis in Ukraine will give us the impetus to consider changes to the trajectory of consolidation we&amp;rsquo;ve allowed to occur. We&amp;rsquo;ll follow up on this topic tomorrow after the Human Rights Protocol Considerations (HRPC) Research Group who will take up the topic of Regional Internet Blocking.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Conference Report: Monday March 21, 2022</title>
      <link>https://guardianproject.info/2022/03/21/ietf113-conference-report-monday-march-21-2022/</link>
      <pubDate>Mon, 21 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/21/ietf113-conference-report-monday-march-21-2022/</guid>
      <description>&lt;p&gt;It&amp;rsquo;s opening day at the &lt;a href=&#34;https://www.ietf.org/how/meetings/113/&#34;&gt;113th IETF meeting&lt;/a&gt;, the first in-person meeting in two years due to the COVID pandemic and being held in Vienna Austria. We&amp;rsquo;re focusing on standards activities of importance to the Internet Freedom community.&lt;/p&gt;&#xA;&lt;p&gt;New work is brought to the IETF via Birds-of-a-Feature sessions and also each technical area&amp;rsquo;s Dispatch Working Group.  The Application area often sees the most unique and interesting ideas and this meeting was no exception.  The [Open Ethics Initiative] (&lt;a href=&#34;https://openethics.ai/&#34;&gt;https://openethics.ai/&lt;/a&gt;) introduced its idea for an &lt;em&gt;ethics disclosure&lt;/em&gt; or &lt;a href=&#34;https://openethics.ai/oetp/&#34;&gt;transparency protocol&lt;/a&gt; to help promote trust among users and service providers in a way similar to nutrition labelling on foods.  Two &lt;a href=&#34;https://www.ietf.org/archive/id/draft-mahy-dispatch-immi-content-00.html&#34;&gt;new&lt;/a&gt; &lt;a href=&#34;https://www.ietf.org/archive/id/draft-mahy-dispatch-immi-mls-mime-00.html&#34;&gt;drafts&lt;/a&gt; have been written related to the format of data exchange among messaging services. I know what you&amp;rsquo;re thinking: &amp;ldquo;but messaging services don&amp;rsquo;t interoperate&amp;rdquo;.  Exactly. These drafts are a push to get that to happen, initially in the context of the Messaging Layer Security (&lt;a href=&#34;https://datatracker.ietf.org/wg/mls/about/&#34;&gt;MLS&lt;/a&gt;) effort.  Along the same lines, a plea was made to liberate messaging from the confines of the encapsulating (and in some cases proprietary) protocols, to be used as first-class network transactions on their own via the &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-spinella-event-streaming-open-network/&#34;&gt;Event Streaming Open Network&lt;/a&gt;. And, the team doing Encrypted Client Hello (&lt;a href=&#34;https://tools.ietf.org/id/draft-ietf-tls-esni-13.html&#34;&gt;ECH&lt;/a&gt;) introduced an idea to &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/&#34;&gt;liberate ECH&amp;rsquo;s host configuration information from the DNS&lt;/a&gt; to which some folks believe it is inextricably bound.  Well, they didn&amp;rsquo;t present it &lt;em&gt;quite&lt;/em&gt; that way, but&amp;hellip; Liberation was the theme of the event, it seems!&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF113 Hackathon Project</title>
      <link>https://guardianproject.info/2022/03/20/ietf113-hackathon-project/</link>
      <pubDate>Sun, 20 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2022/03/20/ietf113-hackathon-project/</guid>
      <description>&lt;p&gt;&lt;em&gt;This post begins a daily blog, live from IETF113 in Vienna Austria, March 19-25, 2022 (first in-person meeting after six remote-only meetings during the COVID pandemic).&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://www.ietf.org/how/runningcode/hackathons/113-hackathon/&#34;&gt;Hackathon&lt;/a&gt; event kicks off IETF and, at this meeting,  we picked up work originally done by one of our teammates implementing version 5 of &lt;a href=&#34;https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html&#34;&gt;Internet Draft HTTP Transport Authentication&lt;/a&gt;. &lt;em&gt;HTTP Transport Authentication&lt;/em&gt; 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 &lt;em&gt;HTTP Transport Authentication&lt;/em&gt; are resistant to active probing by network adversaries.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF: Year End Review 2021</title>
      <link>https://guardianproject.info/2021/12/23/ietf-year-end-review-2021/</link>
      <pubDate>Thu, 23 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2021/12/23/ietf-year-end-review-2021/</guid>
      <description>&lt;p&gt;In terms of potential impact on Internet Freedom, it’s been a banner year at the Internet Engineering Task Force &lt;a href=&#34;https://ietf.org/&#34;&gt;(IETF)&lt;/a&gt;.  &lt;a href=&#34;https://datatracker.ietf.org/doc/rfc9000/&#34;&gt;QUIC&lt;/a&gt; (featuring the improved privacy and security of &lt;a href=&#34;https://datatracker.ietf.org/doc/html/rfc8446&#34;&gt;TLS1.3&lt;/a&gt;) reached Proposed Standard status, with implementations and rollouts from every major vendor on both server and client, and with multiple &lt;a href=&#34;https://en.wikipedia.org/wiki/QUIC#Source_Code&#34;&gt;open source toolkit options&lt;/a&gt; for developers.  &lt;a href=&#34;https://datatracker.ietf.org/doc/draft-ietf-tls-esni/&#34;&gt;Encrypted Client Hello&lt;/a&gt; for TLS1.3 gained traction via the &lt;a href=&#34;https://defo.ie&#34;&gt;DEfO project&lt;/a&gt; that, through pull requests, makes a huge privacy enhancement easily available to the major security library (OpenSSL) underpinning the Internet’s most important service engines (nginx, apache, lighttpd, haproxy on the server, even curl on the client).  IP address privacy got new attention with a working group formed around Oblivious HTTP Application Intermediation (&lt;a href=&#34;https://datatracker.ietf.org/doc/charter-ietf-ohai/&#34;&gt;OHAI&lt;/a&gt;), as did Privacy-Preserving Measurement (&lt;a href=&#34;https://datatracker.ietf.org/doc/bofreq-privacy-preserving-measurement/&#34;&gt;PPM&lt;/a&gt;) which seeks to drastically reduce the amount of personal information swept up in the pervasive monitoring of all public Internet activity.  Meanwhile, the Internet Research Task Force (&lt;a href=&#34;https://irtf.org&#34;&gt;IRTF&lt;/a&gt;) has focused on developing new cryptographic techniques to serve these rapidly-evolving privacy-focused activities. IRTF also fosters work on truly-global Internet access and, in a sense, serves as the IETF’s conscience through it’s work on the &lt;a href=&#34;https://datatracker.ietf.org/rg/hrpc/about/&#34;&gt;human rights implications of protocol design&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IETF112 - Meeting Update (November 2021)</title>
      <link>https://guardianproject.info/2021/11/24/ietf112-meeting-update-november-2021/</link>
      <pubDate>Wed, 24 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2021/11/24/ietf112-meeting-update-november-2021/</guid>
      <description>&lt;p&gt;The 112th meeting of the Internet Engineering Task Force (IETF) took place November 8-12, 2021 - as a virtual event for the sixth time in succession due to the COVID-19 pandemic. Here’s a summary of the work I found important to the Internet Freedom community.&lt;/p&gt;&#xA;&lt;h2 id=&#34;privacy-preserving-measurement&#34;&gt;Privacy Preserving Measurement&lt;/h2&gt;&#xA;&lt;p&gt;While we often (rightly) focus on unwanted surveillance of targeted individuals by nation-states and other bad actors, the Internet’s surveillance economy presents a major threat to personal privacy and freedom for all users of the Internet, as Mozilla so aptly describes on &lt;a href=&#34;https://wiki.mozilla.org/State_Of_The_Internet/Surveillance_Economy&#34;&gt;this wiki page&lt;/a&gt;. Since IETF significantly boosted its focus on privacy at IETF105 (July 2019, where privacy was the &lt;a href=&#34;https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-privacy-modern-concerns-steven-m-bellovin-00&#34;&gt;plenary topic&lt;/a&gt;), participants at both research and engineering levels have begun to address this problem - initially with research studies and statements of requirements, and then with proposals.  Later we’ll discuss proposals that try to offer more anonymity in the way users access the Internet. But new at this conference was a Birds of a Feather session formed around the idea of &lt;a href=&#34;https://datatracker.ietf.org/doc/bofreq-privacy-preserving-measurement/&#34;&gt;Privacy Preserving Measurement&lt;/a&gt; (PPM) and led by Mozilla’s Eric Rescorla who has collected significant thoughts and technical ideas &lt;a href=&#34;https://educatedguesswork.org/tags/privacy%20preserving%20measurement/&#34;&gt;here&lt;/a&gt;.  This thinking would insert a layer of protection between end users and the data collection infrastructure in a way that would significantly impact the bad (for privacy) practices of current-term measurement tools - over-collection, under-protection and deep-interlinking.  An architecture for PPM was proposed and, as there was significant interest from IETF attendees, a Working Group is being established to undertake the technical effort.  There is a future work effort here to understand how this work overlaps or dove-tails with &lt;a href=&#34;https://cleaninsights.org&#34;&gt;CleanInsights&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The IETF and Internet Freedom</title>
      <link>https://guardianproject.info/2021/10/18/the-ietf-and-internet-freedom/</link>
      <pubDate>Mon, 18 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://guardianproject.info/2021/10/18/the-ietf-and-internet-freedom/</guid>
      <description>&lt;p&gt;It seems useful to clarify the relationship between the near-term work of keeping the Internet open on a daily basis - work that dominates the efforts of the Internet Freedom community - and the long term work of the industry on crafting operational standards for the same network.&lt;/p&gt;&#xA;&lt;p&gt;Those involved in Internet Freedom are typically focused on the “problems of today”, creating solutions using existing technologies offering immediate effect.  Often, it’s hard to tell if Internet standards are helping, hurting, or just in the way.  However, looking back at the (roughly) 15-year history of Internet Freedom work, it’s useful to recognize the many times we’ve said to ourselves “&lt;em&gt;Gosh, I would have done that differently if I’d had a chance to think about it&lt;/em&gt;”.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
