[Keytrans] Re: Keytrans@IETF 126 : Call for agenda topics

Felix Linker <linkerfelix@gmail.com> Thu, 30 July 2026 18:27 UTC

MIME-Version: 1.0
References: <CAA1-vB0H9ytS8Af-E7rL3-2XjDFKKiP5AgXL=NVJSvCzc+5VQQ@mail.gmail.com> <CAPeSryro49=BNuocgU+ULDh0W++4VuHpywivxicdu5GQFAyHjQ@mail.gmail.com> <CAPeSrypab7TR1=CwAfGiJVWH3Sy+D6d=93vmq69BQVyoa1-evg@mail.gmail.com> <CAMzqgozkOYVAw8P0G=Q-MwBHEDgjm8TRgDUWvm3Mr-SFn+unvw@mail.gmail.com> <CAKbydOUo9tXhFR31f-p2QGwQNGKk2uwrBxiEaHJyUk6pUsYr6w@mail.gmail.com> <CAMzqgowD4RpAwEj0mnxsv9zVQSk2Mq=DSnBesAcFinKk2ZWULg@mail.gmail.com>
In-Reply-To: <CAMzqgowD4RpAwEj0mnxsv9zVQSk2Mq=DSnBesAcFinKk2ZWULg@mail.gmail.com>
From: Felix Linker <linkerfelix@gmail.com>
Date: Thu, 30 Jul 2026 20:27:36 +0200
Message-ID: <CAPeSryrfM=17Hd8VXSK4581Xt17xfhGWePeod20sE+-QGrM8Mw@mail.gmail.com>
To: Orie <orie@or13.io>
Content-Type: multipart/alternative; boundary="00000000000087e5ef0657d83a6b"
Message-ID-Hash: WK2JAA5XT5YM6TAHALTDKTZXH3DIHGBM
CC: Guy Fischman <gfischman@gmail.com>, Prachi Jain <prachi.jain1288@gmail.com>, keytrans@ietf.org
Precedence: list
Subject: [Keytrans] Re: Keytrans@IETF 126 : Call for agenda topics
Archived-At: <https://mailarchive.ietf.org/arch/msg/keytrans/mBuNlay5wll7KLHSjosmsKeeXXY>

What would be the benefit of going that path?

Cheers,
Felix

Am Do., 30. Juli 2026 um 20:05 Uhr schrieb Orie <orie@or13.io>:

> We could also consider keeping the wire format out of the main spec, and
> defer it to separate drafts.
>
> SCITT did something similar for Merkle tree algorithms where the trees
> ended up not being interoperable.
> SCITT Architecture -> COSE Receipts (RFC9162) -> Specific Tree Algorithms
> (CCF, MMR)
>
> If we went this approach, we would need each wire format document to
> describe the requirements for interop.
>
> OS
>
> On Thu, Jul 30, 2026 at 12:09 PM Guy Fischman <gfischman@gmail.com> wrote:
>
>> Sadly I wasn't able to attend the call. Here are my thoughts on the
>> points Felix raised:
>>
>>    - It's true that mandating TLS makes iterop easier (and makes it
>>    possible using only the spec), though I would claim only slightly easier.
>>    It also comes with some non-negligible costs, notably:
>>    - TLS extensibility has to be designed into the structure. Protobuf
>>       gives it by default. The protocol has churned wire surface through
>>       revisions and isn't yet final.
>>       - Stranding existing deployments or requiring a translation layer
>>       - Signal uses protobuf, and Whatsapp does too (but based on pre-KT
>>       SEEMless).
>>       - It's contrary to the architecture's
>>       "reuse-your-existing-transport" design, which may slow adoption.
>>       - On the other side of making interop easier - gRPC reflection,
>>       that I was able to implement due to the transport-agnostic stance,
>>       facilitates interop, and would be lost by mandating TLS.
>>       - -> On balance I would lean toward keeping the current agnostic
>>       stance.
>>    - Simplifying PrefixProof - Agree. I believe this would reduce proof
>>    sizes along with simplifying.
>>    - Agree, and to make a bit more concrete - don't specify the order,
>>    rather eliminate the dependence on it. Carry the log entry position
>>    alongside each timestamp, prefix proof, and prefix root. Eight bytes per
>>    entry, and the whole class of ambiguity disappears, including the dedup
>>    rules ("only added the first time," "omitted when the user is expected to
>>    have retained it") that currently make the expected count a function of
>>    client state.
>>
>> -Guy
>>
>> On Tue, Jul 28, 2026 at 2:34 PM Orie <orie@or13.io> wrote:
>>
>>> Hi,
>>>
>>> I support making TLS mandatory.
>>> I don't have enough info on the other points raised to be helpful.
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> On Tue, Jul 28, 2026 at 6:31 AM Felix Linker <linkerfelix@gmail.com>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> As there was little time for discussion at the end of the meeting, I
>>>> wanted to raise my three suggestions for the protocol document on list and
>>>> here what other people say. Here they are:
>>>>
>>>>    - We should make one wire format mandatory. Currently, the draft
>>>>    allows implementers to freely choose the wire format. I would make TLS
>>>>    mandatory. If people want to use a different wire format, they of course
>>>>    still can, but fixing TLS allows us to at least hope that different
>>>>    implementations interoperate.
>>>>    - I suggest simplifying the PrefixProof structure as follows:
>>>>    Represent prefix trees as a list of leafs with their depth. Either store
>>>>    the node's hash value (can be omitted for an empty leaf) or store the VRF
>>>>    output and the commitment. The reconstruction algorithm can then simply do
>>>>    a DFS search over the prefix tree and initialize it along the way. With the
>>>>    current wire format, one must merge prefix trees first with the binary
>>>>    ladder, then initiate leafs from the prefix search results, then fill in
>>>>    node values.
>>>>       - I implemented this new wire format for testing purposes, and
>>>>       my code for constructing prefix trees indeed becomes much simpler:
>>>>       https://github.com/felixlinker/keytrans-verification/blob/ca4157ae8aaaae0b0e5b4b4e0e9d6d08524786a1/pkg/trees/prefix/prefix.go#L471
>>>>       - Previously, this was the code to first merge binary ladder
>>>>       results into the prefix tree:
>>>>       https://github.com/felixlinker/keytrans-verification/blob/3c4bb83d7dbcf47a4091d54653a5b6a2dcc84a8f/pkg/proofs/proofs.go#L102
>>>>       and this is the code to construct the prefix tree:
>>>>       https://github.com/felixlinker/keytrans-verification/blob/3c4bb83d7dbcf47a4091d54653a5b6a2dcc84a8f/pkg/trees/prefix/prefix.go#L536
>>>>    - I suggest describing the wire format more explicitly. For
>>>>    example, Section 12.3, specifying the combined tree proof, only says: "The
>>>>    timestamps field contains the timestamps of specific log entries [...].
>>>>    There is no explicit indication as to which log entry the elements
>>>>    correspond to, as they are provided in the order that the algorithm the
>>>>    user is executing would request them." Such language makes the draft hard
>>>>    to implement because one now needs to consider the entire document to
>>>>    understand how to parse the data structure. I think this one will be quite
>>>>    hard to address. I cannot come up with the right language right now,
>>>>    because I'm not sure what actually holds about, e.g., the combined tree
>>>>    proof in all cases. But maybe that's a sign that such text is needed.
>>>>
>>>>
>>>> Curious to hear what the rest thinks!
>>>>
>>>> Best,
>>>> Felix
>>>>
>>>> Am Do., 16. Juli 2026 um 10:14 Uhr schrieb Felix Linker <
>>>> linkerfelix@gmail.com>:
>>>>
>>>>> Hi Prachi and fellow keytrans enthusiasts,
>>>>>
>>>>> We made progress implementing a client. The client is still very much
>>>>> WIP, but I believe (with an asterisk) that it should be able to verify
>>>>> greatest version queries.
>>>>>
>>>>> The code for that can be found here:
>>>>> https://github.com/felixlinker/keytrans-verification/blob/felixlinker/client-state/pkg/client/client.go#L98
>>>>> Development currently happens on that branch.
>>>>>
>>>>> I could not test whether the client works yet because I'm not aware of
>>>>> a server implementation that generates search responses for search
>>>>> requests. Maybe my understanding here is wrong, I asked both Guy and
>>>>> Brendan for this. Would be great to have test vectors. My implementation of
>>>>> a prefix and log tree is tested, but only "against itself," i.e., I check
>>>>> that my implementation satisfies certain invariants.
>>>>>
>>>>> We also prove that our go implementation is memory safe. We haven't
>>>>> gone much further than that in our mechanized proofs because I would first
>>>>> like to test whether the client implementation actually works. It is much
>>>>> cheaper to test than to prove, so I want to do that first.
>>>>>
>>>>> The asterisk that I mentioned above is that I took the liberty to
>>>>> change the server response format slightly so that proofs are easier to
>>>>> parse. I could, at the meeting, present my experience implementing the
>>>>> client. My life would be much simpler if the change in wire format were
>>>>> part of the draft, and I find there are certain parts of the draft which
>>>>> are hard to implement and get right.
>>>>>
>>>>> Best,
>>>>> Felix
>>>>>
>>>>>
>>>>> Am Di., 14. Juli 2026 um 16:50 Uhr schrieb Prachi Jain <
>>>>> prachi.jain1288@gmail.com>:
>>>>>
>>>>>> Hello KEYTRANS enthusiasts,
>>>>>>
>>>>>> Please share any topics, discussion items, or anything else you'd
>>>>>> like to cover during our time at IETF 126. We have an hour allocated to us.
>>>>>>
>>>>>>
>>>>>> -Chairs
>>>>>> --
>>>>>> Keytrans mailing list -- keytrans@ietf.org
>>>>>> To unsubscribe send an email to keytrans-leave@ietf.org
>>>>>>
>>>>> --
>>>> Keytrans mailing list -- keytrans@ietf.org
>>>> To unsubscribe send an email to keytrans-leave@ietf.org
>>>>
>>> --
>>> Keytrans mailing list -- keytrans@ietf.org
>>> To unsubscribe send an email to keytrans-leave@ietf.org
>>>
>>

[Keytrans] Keytrans@IETF 126 : Call for agenda to… Prachi Jain
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Prachi Jain
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Orie
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Guy Fischman
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Orie
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Orie
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Andrew Gallagher
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Guy Fischman
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Konrad Kohbrok
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Brendan McMillion
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Brendan McMillion
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Felix Linker
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Guy Fischman
[Keytrans] Re: Keytrans@IETF 126 : Call for agend… Prachi Jain