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

[Orie <[e-mail]>]

If we believe a large number of implementers will support 2 wire formats,
and we want both formats to be well-supported without making the
primary spec difficult to read...
Or if we think that it's 2 today, but it might grow to 5 soon... and we
want to set up the system to support that growth.

Obviously the more incompatible wire formats we define the worse the
interop.

However, if there is significant interest in more than 1 wire format,
splitting them out can better align the set of RFCs an implementer needs to
read with the relevance of each RFC to their implementation.

OS


On Thu, Jul 30, 2026 at 1:27 PM Felix Linker <[e-mail]> wrote:

> What would be the benefit of going that path?
>
> Cheers,
> Felix
>
> Am Do., 30. Juli 2026 um 20:05 Uhr schrieb Orie <[e-mail]>:
>
>> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <
>>>>> [e-mail]>:
>>>>>
>>>>>> 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 <
>>>>>> [e-mail]>:
>>>>>>
>>>>>>> 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 -- [e-mail]
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>
>>>>>> --
>>>>> Keytrans mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>> --
>>>> Keytrans mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>