Hey Felix, CIL.

On Thu, Jul 30, 2026 at 8:26 PM Felix Linker <linkerfelix@gmail.com> wrote:

> Hey guy,
>
> Some questions/comments inline.
>
> Quick general note: I don't actually care which wire format we use. TLS is
> a natural choice as the draft already uses that framework.
>
> Cheers,
> Felix
>
> Am Do., 30. Juli 2026 um 19:09 Uhr schrieb Guy Fischman <
> gfischman@gmail.com>:
>
>> 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.
>>
>> What is TLS extensibility?
>
 Read as "With TLS, extensibility has to be designed into the structure."
The extension point would need to be defined in the spec.

>
>>    - Stranding existing deployments or requiring a translation layer -
>>       Signal uses protobuf, and Whatsapp does too (but based on pre-KT SEEMless).
>>
>> I don't see the argument of stranding existing deployments. Even after
> agreeing on a default wire format, existing deployments can stick to their
> wire format. The only downside I see is that such deployments would miss
> free interoperability with new implementations that happen to use the same
> wire format. Debatable how likely that is.
>
That's what I mean by stranding.


>
> If we don't agree on any wire format, we risk requiring n^2
> interoperability layers.
>
Not n^2 since every node doesn't need to interop with every other (e.g.
server to server). Each consumer needs a layer for each log it consumes.
But it is more than with a specified transport.


> Also, couldn't you handle KT messages inside Signal/WhatsApp as opaque and
> just give the heap of bits to the KT library that you're using? I suspect
> the part of your codebase that handles KT will be mostly distinct from the
> parts of your codebase that handle other aspects.
>
I'm not saying it's impossible, only that it adds a layer of complexity and
thus a hurdle to adoption. I also suspect there is a TOCTOU-type risk in
what I understand you're suggesting, if the part of the codebase enforcing
an ACL on the basis of KT isn't itself reading the KT structure. I haven't
given this enough thought to land on a strong opinion of how big this risk
is.


>
>>    - 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.
>>
>> Can you elaborate? I quickly googled gRPC reflection, but couldn't make
> enough sense of it.
>
It's a service the server exposes that serves its own protobuf schema at
runtime, so a client runs grpcurl -describe and discovers every RPC and
message shape without ever obtaining a .proto out of band

>
>>    - -> 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
>>>
>>