Draft: draft-ietf-quic-qlog-main-schema

Commentary: Adding high - level discussion of privacy and security considerations operators should take into account . This will walk a fine line between being too high - level / vague and trying to do too much in a qlog document that should be done in a more general IETF document that discusses these issues for all possible log formats , not just qlog . 
 This is a solid start . I think it treads the line well about what should be discussed in the scope of qlog . There might be a small discussion about whether we should mention so many QUIC things in the main schema , rather than in the qlog schema , but at the moment I 'd fall on the side of leaving them here . 
 I have now processed all of your comments , with 2 that probably deserve an extra look . The overall structure is more consistent now , and concrete QUIC / TLS / HTTP mentions are now clear as examples of data types , rather than specific data fields in qlog themselves . I think this is ready for broader review ( and as we discussed yesterday , a first merge into the main doc if it can be approved by the editors here ) . The main missing part is a proper reference to a recent differential privacy survey / discussion which I still need to research ( suggestions welcome ! ) . I will also add a section to the event documents that references back to this soon . 
 Thank you for the review and extensive comments . In discussion with and because we really wanted to have -something- about this in the new drafts , I 've merged this first version of the text , including fixes for your smaller but not larger remarks , with the intent of there being continued discussion going forward . To that end , I will create 2 new issues , one for your high - level review about general structure , and one for the " user consent " remark to further track these points for future versions . Thanks again ! 
 This is a lot of text . I like the enumeration of the types of risk , but I fear that the extrapolation from there is both incomplete and a little long - winded . The focus on anonymization is not one that I would emphasize . I know that Christian has toyed with the concept , but that was idle speculation , not anything rigorous . In the end , this text should be very clear that qlog files present a privacy risk to those participating in the connection . They should therefore be treated accordingly . Any notion that these files might be sanitized in a way that might remove that risk should be changed to focus more on defense in depth . That is , look at access control and retention limits as primary means of protection , not anonymization . I would instead structure this roughly as follows : brief introductory piece . articulation of the types of privacy risk that might be presented by capture , storage , and use of qlog data . This part is fairly lengthy and could probably be a subsection . description of the operational implications and potential actions that might be taken first from a security standpoint , then for privacy remediation . qlog files that are records of interactions with peers are data that those peers ( or users ) potentially have rights over ( I like this point , so make it prominently , but do not refer to laws ; do not refer to the GDPR especially ) . a. Access controls required to enable qlog or to expand the information that is captured . a. Access controls required to access stored qlog files . a. Limits to retention of qlog files . a. Finally , observe that limiting what is captured or anonymization might be possible , but that this could either be insufficient from a privacy perspective , reduce the usefulness of the data , or ( highly likely ) both . It 's easy to focus on the point about not being able to link qlog data with people . But it 's safer to treat that as an open research problem than invite implementations and deployments to indulge in amateur research on the topic . Looks good now , thanks !
Paragraph (version B):
Protocols such as TLS RFC8446 and QUIC RFC9000 provide varying
degrees of secure protection for the wire image RFC8546.  There is
inevitably tension between security and observability, when logging
can reveal aspects of the wire image, that would ordinarily be
protected.  This tension equally applies to any privacy
considerations that build on security properties, especially if data
can be correlated across data sources.
Paragraph (version B):
qlog operators and implementers should be mindful of the security and
privacy risks inherent in handling qlog data.  This includes but is
not limited to logging, storing, or using the data.  Data might be
considered as non-sensitive, potentially-sensitive, or sensitive;
applying the considerations in this section may produce different
risks depending on the nature of the data itself, or its handling.
However, in many cases the largest risk factors arise from data that
can be considered as potenially-sensitive or sensitive.
Paragraph (version B):
IP addresses and transport protocol port numbers, which can be
used to uniquely identify individual connections, endpoints, and
potentially users.
Paragraph (version B):
Session, Connection, or User identifiers which can be used to
correlate nominally separate contexts.  For example, QUIC
Connection IDs can be used to identify and track users across
geographical networks RFC9000).
Paragraph (version B):
Stored State which can be used to correlate individual connections
or sessions over time.  Examples include QUIC address validation
and retry tokens, TLS session tickets, and HTTP cookies.
Paragraph (version B):
Decryption keys, passwords, and tokens which can be used with
other data sources (e.g., captures of encrypted packets) to
correlate qlog data to a specific connection or user or leak
additional information.  Examples include TLS decryption keys and
HTTP-level API access or authorization tokens.
Paragraph (version B):
Data that can be used to correlate qlogs to other data sources
(e.g., captures of encrypted packets).  Examples include high-
resolution event timestamps or inter-event timings, event counts,
packet and frame sizes.
Paragraph (version B):
Full or partial encrypted raw packet and frame payloads, which can
be used with other data sources (e.g., captures of encrypted
packets) to correlate qlog data to a specific connection or
session.
Paragraph (version B):
Full or partial plaintext raw packet and frame payloads (e.g.,
HTTP Field values, HTTP response data, TLS SNI field values),
which can contain directly sensitive information.
Paragraph (version B):
The simplest and most extreme form of protection against abuse of
this information is the complete deletion of a given field, which is
equivalent to not logging the field(s) in question.  While deletion
completely protects the data in the deleted fields from the risk of
compromise, it also reduces the utility of the dataset as a whole.
As such, a balance should be found between logging these fields and
the potential risks inherent in their (involuntary) disclosure.  This
balance depends on the use case at hand (e.g., research datasets
might have different requirements to live operational
troubleshooting).  Capturing the minimal amount of data required for
a specific purpose can help to minimize the risks associated with
data usage. qlog implementations that provide fine-grained control
over the inclusion of data fields, ideally on a per-use-case or per-
connection basis, improve the ability to minimize data.
Paragraph (version B):
Any data that is determined to be necessary for a use case at hand
could be logged or captured.  As per RFC6973, operators must be aware
that such data will be at risk of compromise.  As such, measures
should be taken to firstly reduce the risk of compromise and secondly
reduce the risk of abuse of compromised data.  While a full
discussion of both aspects is out of scope for this document, the
following paragraphs discuss high-level considerations that can be
applied to qlog data.
Paragraph (version B):
To reduce the risk of compromise, operators can take measures such
as: limiting the length of time that data is stored, encrypting data
in transit and at rest, limiting access rights to the data, and
auditing data usage practices. qlog deployments that provide
integrated options for automated or manual data deletion and
(aggressive) aggregation, improve the ability to minimize the risk of
compromise.
Paragraph (version B):
To reduce the risk of data abuse after compromise, data can be
anonymized, pseudonymized, otherwise permutated/replaced, truncated,
(re-)encrypted, or aggregated.  A partial discussion of applicable
techniques (especially for IP address information) can be found in
DNS-PRIVACY.  Operators should, however, be aware that many of these
techniques have been shown to be insufficient to safeguard user
privacy and/or to protect user identity, especially if a qlog data
set is large or easily correlated against other data sources.
Paragraph (version B):
Finally, qlog operators should consider the interplay between their
use case needs and end user rights or preferences.  While active user
participation (as indicated by RFC6973) on a per-qlog basis is
difficult, as logs are often captured out-of-band to the main user
interaction and intent, general user expectations should be taken
into account. qlog deployments that provide mechanisms to integrate
the capture, storage and removal of qlogs with more general, often
pre-existing, user preference and privacy control systems, improve
the ability to protect data sensitive or confidential to the end
user.  In qlog, these data are typically (but not exclusively)
contained in fields of the RawInfo type (see raw-info). qlog users
should thus be particularly hesitant to include these fields for all
but the most stringent use cases.