Re: qlog schema
Phillip Hallam-Baker <phill@hallambaker.com> Wed, 16 December 2020 18:14 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0A3A0A9C for <quic@ietfa.amsl.com>; Wed, 16 Dec 2020 10:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJo2syjCcLaT for <quic@ietfa.amsl.com>; Wed, 16 Dec 2020 10:14:44 -0800 (PST)
Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF8A3A0AA0 for <quic@ietf.org>; Wed, 16 Dec 2020 10:14:44 -0800 (PST)
Received: by mail-yb1-f178.google.com with SMTP id u203so23311220ybb.2 for <quic@ietf.org>; Wed, 16 Dec 2020 10:14:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GcFwjeN1I1VX9UjUT/T8xpXT8VEsrKK7mKQn6lGATxo=; b=Rxoii1A8j/BCSzuUVEKfRDtyaET+3560TKzN1TOyxxYHV5wIqSX8c8kwItHEBlRB/z jjNXFD/K3wPsSrLqFzHoN9CArACjdBAJWvP5o4il+afj5YCZhl/SfXNG/wPkYC9tjj+o l23S2qycaW3mnek9meLVmFhjWVmvzenvC8S67mQlo8Pmj56o3Aowz9RXoWqOILj4yup8 cKZICTgfnBWqFALZ6U3STGbVrVlT8BdYydwpvOeI+dkJFCvJ3TfiULC/v8hCnKZs177u G7UtB4jXrSjDqbUCQLz46sZV0byfiPTxXX8Adn2zBFFDpjcnIxMp+zP59ag74IaKJpf+ C2oA==
X-Gm-Message-State: AOAM532nC8eLDeiayyPmDkjyfGJBCzuGy2xs1e6+QZKIzYnqR1qT41Ft dJ5TeSiS8dyeSHvMv0ESm20ooMa2cI1XfIs0ZKU=
X-Google-Smtp-Source: ABdhPJyDyvvN1JnrEF0ffRZbnKEu7QvU1t01YfSHrdnnlfjbh273CdYV/Kig82jmZtVzTsZdcx0pvt9mjlIBSMq9OYE=
X-Received: by 2002:a25:7145:: with SMTP id m66mr21023288ybc.172.1608142483451; Wed, 16 Dec 2020 10:14:43 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxQxO-WnczYUJoaEJe4ObiY3_CWCqYC+iw+twzYRZwDBaQ@mail.gmail.com>
In-Reply-To: <CAM4esxQxO-WnczYUJoaEJe4ObiY3_CWCqYC+iw+twzYRZwDBaQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 16 Dec 2020 13:14:34 -0500
Message-ID: <CAMm+LwgP15iT-ex9BBdhBJQE+dSmF=Uv2zER4gmibFwF+L51_w@mail.gmail.com>
Subject: Re: qlog schema
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Robin MARX <robin.marx@uhasselt.be>, Magnus Westerlund <magnus.westerlund@ericsson.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000079716005b698d9df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/VlzkUywpsRsbmEzEeyJiI5BtgSA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 18:14:46 -0000
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 <martin.h.duke@gmail.com> 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 >
- qlog schema Martin Duke
- Re: qlog schema Phillip Hallam-Baker
- Re: qlog schema Robin MARX