Re: qlog schema

Robin MARX <> Mon, 21 December 2020 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A55D23A121C for <>; Mon, 21 Dec 2020 08:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSbu995Y1-QH for <>; Mon, 21 Dec 2020 08:18:23 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0624F3A121B for <>; Mon, 21 Dec 2020 08:18:22 -0800 (PST)
Received: by with SMTP id d26so11592362wrb.12 for <>; Mon, 21 Dec 2020 08:18:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6nrEnjhMBWfx72g4m3StVUXey0sDXCC1AXWGlE5mc4Y=; b=AiT7NIfFNKQlH+flRPKfOM6lPE94rWOoJFSyyPnpO1zhPpJi7Hv6hINKyjDhpgkHnm yjmbVnO9h66gcmS1IsnHr+VU3sU8E6L5CnEu9jkvRlzXgcv2G7mgTanN95Kd2D58VF9N K7DyC7k0l9OkxZqGAMyA08Ele/eANMQ9nPqXQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6nrEnjhMBWfx72g4m3StVUXey0sDXCC1AXWGlE5mc4Y=; b=WhbjMxOWrRMbeJVsgO5Fjzn3I2mYLfTX8qlQiXLcGs+WKMSWczD4wfkcrM4yHeqTsP x/KlfbZUZYu2173Gcun70Tx/4EqIBucCTSq16sQ38BDifTG+h6ZLQ4pu1prTu0+qgTV4 wGdUXwLhzSfvByRtV6vOHQGH7DdK8OKWCQ9Ky345hW5h0ZpraYx6tfnLl8BWuML+Rwdi g7Nasl914nAgUidLOvjkdBdfSpBc2D6CzL1/vPtYhW8zxVtguRDDEXDzCyhbwRdL6Tkl 8041pU5Y9ZCqgQqaXyN7thX24cZiz7unVfoKeanUCt5f84U0goylqFUtidzUYM2NTf/9 c9DQ==
X-Gm-Message-State: AOAM531YU8oZelkBp/fiICrXXZlGu1kw3oZwc2RrtmL52BUbPbvayXbk kfCJUqzLHt5EeeX1ObF43vkBMe9BSdGYpZaNnJxtPQ==
X-Google-Smtp-Source: ABdhPJxheohVJYJv6YBwfWCObE6m7B6Pp/oR+H8fIcdeW4byKk8wNOqtdgJsc4hV3uDkr2QpZWVyWybKIc/7e4bqmE0=
X-Received: by 2002:a05:6000:143:: with SMTP id r3mr19423294wrx.331.1608567500759; Mon, 21 Dec 2020 08:18:20 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robin MARX <>
Date: Mon, 21 Dec 2020 17:18:07 +0100
Message-ID: <>
Subject: Re: qlog schema
To: Phillip Hallam-Baker <>
Cc: Martin Duke <>, Magnus Westerlund <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000007af95005b6fbce4e"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Dec 2020 16:18:26 -0000

 Hello Martin and others,

Good to hear there is a clear opinion on how to move forward with qlog
within the IETF, thank you for the effort.
I'm also happy it can remain in the QUIC wg for the time being.
I will as proposed register a HotRFC session for IETF 110 to hopefully get
some outside involvement.

I agree we shouldn't define a file format but rather a binding to
JSON/NDJSON/other (binary) formats. This is what I've tried to do so far
with the qlog main schema.
I'm not entirely sure myself we should consider encryption/authentication
of the logs as part of this endeavour, but of course that's something that
can be discussed in a wider group once qlog is adopted.

The plan for now is to continue development of qlog in the existing github
repo at until the documents are
I suspect we'd cut a new draft-03 right before that.
I would encourage interested people not to wait until then, but to already
engage with the work there in the meantime.

With best regards,

On Wed, 16 Dec 2020 at 19:14, Phillip Hallam-Baker <>

> This is a good step. As one of the authors of the W3C log format, I think
> it would have been much better to have a discussion of the log features as
> part of the protocol design. There was no interest and which is why there
> isn't even a proper spec. Basically, this is like SNMP and MIBs, you want
> the MIBs to be developed by the groups developing the protocols.
> I would however urge that this be presented as an effort to create a
> schema doe log file entries with bindings to JSON and NDJSON rather than a
> log file format itself.
> It is about time that we had a cryptographic log file format that supports
> modern features such as incremental encryption and authentication. The
> power of one way sequences has been established by BlockChain. That is not
> a framing mechanism I would want to use for a log file but it shows the
> principle.
> Separating out the protocol specific schema from the framing allows
> independent development of each. And yes, I do happen to have an
> implementation of a log file format with cryptographic enhancements. And it
> can do things like allow rapid location of a specific record range within
> the log file, etc.
> Why would you want to encrypt your logs? Well, it is a question of HIPPA
> and GDPR for some. But more generally, what a service can't read, a service
> can't breach. If Mallet gets into my cloud, she is going to find it a lot
> harder to sabotage my systems undetected if she can't read the log files
> and they are in any case protected using Merkle trees. At that point, all
> she can really do is to delete large chunks of log but that will leave
> traces.
> Given what happened this week, given the serious breaches that will be
> announced next month, demand for encrypted logs is going to come quickly
> when it comes.
> The other reason to encrypt your logs is it provides you with the basis
> for an encrypted persistence store with ACID properties.
> But that is all in the future. For the time being, the best plan is to
> develop one example of a decent log file using the JSON data model. If
> there is interest in doing a cryptographic format, that would obviously be
> a separate WG. That would focus on the format itself using HTTP/QUIC as the
> paradigm from which the general case is developed.
> On Wed, Dec 16, 2020 at 12:34 PM Martin Duke <>
> wrote:
>> Hi Robin,
>> Congrats on your defense! I hope to watch it soon.
>> We had a chat about qlog at the IESG. The consensus there appears to be
>> that we should plan to move forward in quicwg with both drafts rather than
>> seek another venue. However, it would be valuable for you to request a
>> HotRFC slot to encourage the parallel development of qlog-based standards
>> in other working groups.
>> If that's agreeable to you, feel free to proceed.
>> Martin


Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05