Internet DRAFT - draft-appelcline-hashed-elision
draft-appelcline-hashed-elision
Network Working Group S. Appelcline
Internet-Draft W. McNally
Intended status: Informational C. Allen
Expires: 4 August 2024 Blockchain Commons
1 February 2024
Deterministic Hashed Data Elision: Problem Statement and Areas of Work
draft-appelcline-hashed-elision-00
Abstract
This document discusses the privacy and human rights benefits of data
minimization via the methodology of hashed data elision and how it
can help protocols to fulfill the guidelines of RFC 6973: Privacy
Considerations for Internet Protocols and RFC 8280: Research into
Human Rights Protocol Considerations. Additional details discuss how
the extant Gordian Envelope draft can provide further benefits in
these categories.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-appelcline-hashed-elision/.
Source for this draft and an issue tracker can be found at
https://github.com/BlockchainCommons/WIPs-IETF-draft-hashed-elision.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 August 2024.
Appelcline, et al. Expires 4 August 2024 [Page 1]
Internet-Draft HashedElision February 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Correlation, Secondary Use, and Disclosure All Threaten
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Data Minimization through Anonymity or Pseudonymity is
Insufficient . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Simplistic Data Minimization Can Hinder Other Humans Rights
Solutions . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Any Data Can Be Too Much Data . . . . . . . . . . . . . . 4
3. Areas of Work . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Core Areas of Work . . . . . . . . . . . . . . . . . . . 5
3.1.1. Support Data Minimization . . . . . . . . . . . . . . 5
3.1.2. Incorporate Deterministic Hashing . . . . . . . . . . 6
3.1.3. Enable Inclusion Proofs . . . . . . . . . . . . . . . 6
3.1.4. Facilitate Herd Privacy . . . . . . . . . . . . . . . 7
3.2. Optional Areas of Work . . . . . . . . . . . . . . . . . 8
3.2.1. Extend Support to Encryption & Compression . . . . . 8
3.2.2. Address Additional Human Rights Threats . . . . . . . 8
3.2.3. Keep It Simple . . . . . . . . . . . . . . . . . . . 9
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Appelcline, et al. Expires 4 August 2024 [Page 2]
Internet-Draft HashedElision February 2024
1. Introduction
IETF released guidelines for privacy considerations in 2013 with
[RFC6973] and then expanded upon that with human-rights
considerations in 2017 with [RFC8280]. Both RFCs provide thoughtful
ideas for how privacy can be improved in internet protocols, and how
that can support human rights on the internet.
However, as generalized guidelines these RFCs don’t provide the
specifics that might be required to incorporate these guidelines into
new protocols. This leads to privacy threats such as correlation,
secondary use, and unnecessary disclosure of data. This document
suggests more specific areas of work based in part on the Data
Minimization suggestions of §6.1 of RFC 6973, and expands them to
also support some of the Human Rights Guidelines outlined in §6.2 of
RFC 8280. It does so through the advancement of a hashed data
elision methodology, which allows for the optional removal of data
while maintaining hashes of that data to ensure data integrity.
2. Problem Statement
2.1. Correlation, Secondary Use, and Disclosure All Threaten Privacy
Digital data transmission often operates on an all-or-nothing basis:
sharing data means full disclosure. There is no standard methodology
for minimizing data nor for eliding parts of a data packet. Releases
large packets of data, much of it unnecessary, can threaten privacy
in multiple ways:
* Correlation can combine data from different sources,
unintentionally revealing comprehensive individual data that is
often significantly more than was intended. This is highlighted
as a problem in S.5.2.1 of RFC 6973.
* Secondary Use permits data acquirers to repurpose it beyond its
original intent. This is highlighted as a problem in S.5.2.3 of
RFC 6973.
* Disclosure of any sort can reveal more data than was required for
a use, and that extra data can then create prejudice or otherwise
disadvantage the individual whose data has been disclosed. This
is highlighted as a problem in S.5.2.4 of RFC 6973.
Methodologies for minimizing the amount of data shared at any one
time can reduce all of these privacy dangers.
Appelcline, et al. Expires 4 August 2024 [Page 3]
Internet-Draft HashedElision February 2024
2.2. Data Minimization through Anonymity or Pseudonymity is
Insufficient
§6.1 of RFC 6973 lists anonymity and pseudonymity as two
methodologies for creating Data Minimization. This means removing
uniquely identifying data and/or reducing the amount of personal data
that is transmitted.
Though anonymity and pseudonymity are minimal requirements for
improving the privacy of digital data, they are insufficient, as data
that is pseudoanonymous or anonymous still has the danger of being
correlated. To best address privacy requires reducing the amount of
all data found in any disclosure to the bare minimum required for a
specific disclosure.
2.3. Simplistic Data Minimization Can Hinder Other Humans Rights
Solutions
Data minimization focuses on cutting out unnecessary content that is
not required for a specific task. Though Data Minimization is a
general requirement to improve privacy, doing so in a simplistic
manner is not sufficient.
This is because simplistic Data Minimization excises everything about
data, which can cause problems for the Integrity and potentially the
Authenticity of the original data set. These are needed per the
Guidelines for Human Rights, as outlined in §6.2.16 and §6.2.17 of
RFC 8280.
A better solution for Data Minimization would not ignore other Human
Rights needs as it improves privacy. Hashed data elision, which
preserves hashes for data that has been cut, can provide such a
solution.
2.4. Any Data Can Be Too Much Data
A more nuanced Data Minimization system can solve many problems.
However, there are also situations where a party doesn’t need to know
any specific data, but instead requires proof that a general data
precept is true. The traditional example is proof whether someone is
21 or older, for buying alcohol in the United States. With Data
Minimization, the person's precise age would still be provided, even
though all that's actually needed is an affirmation that the person
was born more than 21 years ago.
Appelcline, et al. Expires 4 August 2024 [Page 4]
Internet-Draft HashedElision February 2024
In these cases, privacy threats can be reduced even more by providing
no data, simply the proof that a general precept is true. This can
offer very strong protection against Correlation (§5.2.1 of RFC 6973)
and obviously minimizes Disclosure (§5.2.4 of RFC 6973).
Though some systems such as BBS+ Signatures and other Zero Knowledge
Proofs system can support superior anti-correlation with “proof of
knowledge of the undisclosed signature”, a more simple salted and
hashed data elision often can provide easier solutions for many
classes of “inclusion” proofs.
3. Areas of Work
3.1. Core Areas of Work
This section tries to identify and structure areas of work to address
the aforementioned problems by turning the guidelines of RFC 6973 and
RFC 8280 into more precise specifications or requirements. It
focuses on hashed data elision as a core area of work, but in a
section on optional areas of work discusses more specific
advancements that can further support RFC 6973 and especially RFC
8280.
3.1.1. Support Data Minimization
As suggested by RFC 6973, Data Minimization is a prime methodology
for improving privacy and reducing problems such as Correlation,
Secondary Use, and Disclosure.
To support Data Minimization, a specification MUST:
1. Allow for the elision of some content from a larger package of
data.
2. Allow for the holder of that data to do that elision, rather than
restricting it to only issuers.
Elision is the obvious requirement for Data Minimization: it's the
removal of data. The question of who can elide data becomes more
important when data is signed as a means of authentication, such as
in credentials. In these situations, elision is traditionally
restricted to the issuer of the credential, which effectively denies
the holder from doing so. To support Data Minimization requires the
holder to be able to do so as well, while maintaining any signatures.
Appelcline, et al. Expires 4 August 2024 [Page 5]
Internet-Draft HashedElision February 2024
3.1.2. Incorporate Deterministic Hashing
As noted in §2.3, above, simplistic Data Minimization can cause other
human rights problems such as a lack of Authenticity or Integrity
checking. This can be resolved in a specification by requiring a
fingerprint that can be used to verify elided data.
To incorporate deterministic hashing, a specification MUST:
1. Allow elided data to be verified with a fingerprint.
2. Ensure that the fingerprint is unidirectional, so that the
fingerprint can prove the existence of the data, but the data
cannot be derived from the fingerprint.
3. Maintain the validity of authenticity checks by requirements that
any signatures be made across the fingerprint not the original
data.
A fingerprint that is generated through a hash function such as
SHA-256 or a newer function such as BLAKE3 will generally meet the
first two requirements.
The third requirement is designed to support the requirements for
Data Minimization in §3.1.1, above. If data is hashed, but any
signature is applied to the hash rather than the original data, then
a holder can choose to elide the data or not, as they see fit, but
the signature still remains valid. This is the strong core of
deterministic hashed data elision, harmonizing Data Minimization and
data integretity.
3.1.3. Enable Inclusion Proofs
Because data does not always need to be shared to provide the
verification required by a validator, support of data proofs can
provide additional privacy and human rights benefits.
To enable inclusion proofs, a specification MUST:
1. Allow for the revelation of specific fingerprints.
2. Support the easy creation of an inclusion proof that demonstrate
how specific data can be hashed to create that specific
fingerprint.
3. Enable any holder to create that inclusion proof, not just an
issuer.
Appelcline, et al. Expires 4 August 2024 [Page 6]
Internet-Draft HashedElision February 2024
Through this methodology, a holder can create a proof for a specific
bit of data, such as their residence in a specific country or state,
demonstrate that proof’s creation, and show that it matches the hash
of elided data. However, the holder does so only if and when they
wish: only the hash is ever public known, the data is never known
unless the holder produces a proof. Usually, the proof is only
offered to an entity who is verifying a specific data element,
effectively turning it from a data revelation method to a data
verification method. This provides strong Data Minimization that is
holder controlled.
Though other methodologies exist for proving the content of data,
such as Zero-Knowledge Proofs and BBS+ Signatures, inclusion proofs
based on hashes provide a much easier solution that is pragmatically
more likely to be implemented and thus is more accessible and useable
today.
3.1.4. Facilitate Herd Privacy
Support for inclusion proofs can also allow for the use of herd
privacy, where data about a specific user is contained within a much
larger hash of data, which can be widely published without danger.
This puts all the agency for data revelation in an individual user’s
hand and does it without any need to “phone home”, meaning that not
even the original publisher of the data would know when that data
were being checked.
To facilitate herd privacy, a specification MUST:
1. Use a branching structure for data storage such as a Merkle Tree
where hashes can be further hashed together at high levels in a
well-known, regularized way.
2. Allow for the publication of top-level or high-level hashes.
3. Enable individual holders to independently, without aid or
assistance, reveal paths that connect their individual data up to
the top-level or high-level hash through any number of branches.
4. Build that structure in such a way that a minimum of other hashes
are revealed when a user reveals a path to their own data; or
else ensure that any other hashes revealed are worthless without
knowledge of secret data, such as a salt.
5. Otherwise support the creation of inclusion proofs for proving an
individual holder's low-level individual data without the
individual needing to contact the publisher of the data in any
way.
Appelcline, et al. Expires 4 August 2024 [Page 7]
Internet-Draft HashedElision February 2024
Herd privacy provides further benefits to privacy because a
credential publisher can publish data without ever having contact
with credential holders, and those holders can then choose to reveal
that data, or not, all without any knowledge of the publisher.
Requirements #1-4 suggest one way to do so using hashed elision and
merkle trees such that other information can’t be guessed from the
revelation of hashes, but the requirement #5 says that other
methodologies would be acceptable provided they meet the core needs
of a herd privacy system.
3.2. Optional Areas of Work
Using hashed data elision as a foundation would improve the privacy
of almost any IETF protocol.
The Gordian Envelope Internet-Draft [GordianEnvelope] is one example
of a specification that supports hashed data elision. It could be
used to enable all of the Core Areas of Work. It also goes further,
incorporating additional functionality that can provide better
support for RFC 6973 and RFC 8280 through additional features,
including the following.
3.2.1. Extend Support to Encryption & Compression
A hashed data elision system can be expanded to support both
encryption and compression functions, as encrypted and compressed
data can also be represented by their hashes without revealing any
information about the original data.
Incorporating encryption into a data specification offers the highest
level of privacy and of Data Minimization possible, as data can only
be viewed by select individual with the decryption key. This is
especially important for Confidentiality, which is referenced in
§6.2.15 of RFC 8280.
Hashing encrypted data also improves Authenticity, per §6.2.17 of RFC
8280. As with other sorts of elided data, signatures will remain
valid even following compression, provided the signatures are applied
to the data hash, not the original data.
3.2.2. Address Additional Human Rights Threats
As currently detailed, the Gordian Envelope Internet-Draft also
supports several other Guidelines for Human Rights Considerations
that are listed in §6.2 of RFC 8280:
Appelcline, et al. Expires 4 August 2024 [Page 8]
Internet-Draft HashedElision February 2024
* Privacy (S.6.2.2). Besides the obvious privacy benefits of Data
Minimization, Gordian Envelope also can improve privacy through
optional usage of integrated metadata, which can be used to
document the sensitivity of contents, retention limits, etc.
* Accessibility (S.6.2.11). Integrated metadata can also be used to
ensure accessibility and internationalization of data through
inclusions of references with a variety of localizations.
* Censorship Resistance (S.6.2.6). Gordian Envelope is built to
support SCIDs, or self-certifying identifiers, which can be used
to avoid reuse of existing identifiers that might be associated
with persons or content.
* Open Standards (S.6.2.7). As an Internet Draft, Gordian Envelope
represents an open standard. It can support interoperable
exchange of data, which is vital for human rights.
* Heterogeneity Support (S.6.2.8), Adaptability (S.6.2.18). Gordian
Envelope builds its data format on triples: assertions of
subjects, predicates, and objects. This format can easily be
adapted to a wide variety of data formatting styles.
* Localization (S.6.2.12), Decentralization (S.6.2.13). As an open
standard that solely utilizes other open standards such as well-
known hashing and encryption algorithms, Gordian Envelope is built
to avoid decentralization. This is further supported by Gordian
Envelope's Heterogeneity Support, its Adaptability, and its
Reliability.
* Reliability (S.6.2.14), Integrity (S.6.2.16). Gordian Envelope is
built on CBOR, which means that data is self-describing. It is
also hashed. This improves its Reliability and Integrity, while
the self-description also makes data stored in Gordian Envelope
more interoperable, and thus less subject to centralization.
3.2.3. Keep It Simple
Support for privacy and for human rights has another requirement: it
needs to be kept simple so that it finds actual use.
Gordian Envelope is a fundamentally simple data format that only
achieves complexity through iterative structure design.
Appelcline, et al. Expires 4 August 2024 [Page 9]
Internet-Draft HashedElision February 2024
4. Privacy Considerations
As outlined, the general concept of hashed data elision and the
specific design of Gordian Envelope provide a wide variety of privacy
advancements. They offer strong support for Data Minimization and
other guidelines found in RFC 6973 and RFC 8280.
The biggest remaining privacy concern is of accidental correlation
that can arise if different parties have different versions of the
same data, which has been elided in different ways. This is
currently seen as an acceptable side-effect of an elision system that
allows for Authenticity and Integrity in the system, and can be
offset by careful creation of Envelope structures, such as gathering
small groups of data into distinct, elided branches.
However, the question also remains open as to whether there might be
more expansive and more automated solutions.
5. Security Considerations
Hashed data elision is intended to strengthen communication security,
primarily by enhancing confidentiality (through elision) while also
maintaining data integrity (through hashing). Supporting this with a
signature system that signs hashes rather than original data also
allows for peer entity authentication, creating a strong foundation
for overall communication security.
However, that security depends on the strength of hashing algorithms
and encryption/signature algorithms. Strong, unbroken hashes and
encryption schemes are required. Potential threats to hashes and
encryption such as quantum computing would result in threats to any
hashed data elision system.
6. IANA Considerations
This document has no IANA actions. Gordian Envelope has already been
assigned CBOR tag #200 by IANA.
7. Informative References
[GordianEnvelope]
McNally, W. and C. Allen, "The Gordian Envelope Structured
Data Format", Work in Progress, Internet-Draft, draft-
mcnally-envelope-05, 20 August 2023,
<https://datatracker.ietf.org/doc/html/draft-mcnally-
envelope-05>.
Appelcline, et al. Expires 4 August 2024 [Page 10]
Internet-Draft HashedElision February 2024
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
October 2017, <https://www.rfc-editor.org/rfc/rfc8280>.
Appendix A. Acknowledgments
The authors are grateful for the support of the CBOR working group in
discussions of Gordian Envelope and general guidance within the IETF.
Authors' Addresses
Shannon Appelcline
Blockchain Commons
Email: shannon.appelcline@gmail.com
Wolf McNally
Blockchain Commons
Email: wolf@wolfmcnally.com
Christopher Allen
Blockchain Commons
Email: christophera@lifewithalacrity.com
Appelcline, et al. Expires 4 August 2024 [Page 11]