Return-Path: X-Original-To: keytrans@mail2.ietf.org Delivered-To: keytrans@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3B44F12134F81 for ; Thu, 30 Jul 2026 11:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785436068; bh=feDI4bird6a9Ag4OlvJQZgNp4OsyFobxcG64GrtexDQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=IIt5x4r1OActqUNAuBXZsX9MLk21Bz8WKHnKNxnPYLwlN+e2NSbnyMUaCNXckl5u8 C+4cl0dLXuOdetRtjEW2kR++vhkvwAlc3tnv7AgrloxrsgDJ0ZpDLMGArYSXOAOME6 IFuturq2lkQ4NxeALg78b6GGoPTO5ffOsritkTnY= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOZ_dsAcLGLq for ; Thu, 30 Jul 2026 11:27:47 -0700 (PDT) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7B5B812134F7A for ; Thu, 30 Jul 2026 11:27:47 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-81e9f7491ffso2436237b3.0 for ; Thu, 30 Jul 2026 11:27:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785436067; cv=none; d=google.com; s=arc-20260327; b=pCFUadxwptdf+67gwo8wuquwcvg/ZArDuRNDoYwsWt3wkvDixmwHoS6IgKzN6FgAWM U8Irrs2XXdeHj3ZuP3IKD2AQBtA7NvuIbHDy69aXPA8xGY9sVeaeuMgxqKlnN14pZeNg JIh5VvSut17x1bUGs1PN4t0QH3lY9wN5beBja4oBDuyiFb0Wa07PtWPZuK0luWK0NdNz DJwGbcx5yVX50Bd4j8tsaGa6JsDwWJLKWOC+jCSJVkeNujYo2DxozTlZe97kOzOAtbaz NgXrIXlT4imnUpWxuo0cH6OM00/ZQqprnAmh0PcHMFcndvDPSACwhpfwa3l/9+lEKMAQ UiFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=oxMTwfSaIjvnfbtlqgmrq3RFCIwcaRIsY2xtTSKtmrw=; fh=pvJSMrfrsjxl5JDGAFCL8qp08ghyS1JuVKsiTJYixRQ=; b=M41dZzPQlP+rFvYwoD4+d7sHwxNp1uRmCq7f1qRqr1/iHpxN+rWSkYsmS3Gk8ZrIP+ pSkqz076SHzdLm5i3hUBC8ZBqlSjKnNxb3EaMRxRw6MdR9oBNOpB1gUR8odhmNSarEqr iozJAK2Wb03IGD3lF3PPD1XfVQBCcaBN5+j6iPgjxdiyYqw5nQc5FUlLvnQHVxt+3w9k qqlNn/0BPx4jKtsS1j/N9p69ylUCi578k0GIWj4Wbh6CD/c+7U2KF0dNPayxIdgdgIdV 33k+e6bLbTbOttFi57ZSjWrre+OuQj1muohBJDaM9IpME/38wHAPxlIUqczvMI26lk2P YQTQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785436067; x=1786040867; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=oxMTwfSaIjvnfbtlqgmrq3RFCIwcaRIsY2xtTSKtmrw=; b=h84WZlhKN9NOnJOJVr7O4fwwJfyBinpcTi+Gf8xCA86nNa12/G9zYbyR85CuvURDqX IoAYarI9rs2kqFhqHiaDhyDhb+WMKZ3XICiUembOB2NC774IHNO+hLAYqMTDo4wKpgJ+ jx8lUWJ/+JBz/sf7gzPw+qI6bHcU2nxhjgD+ViKGbBIx+XYydCI1+6tszFxP9sqUWqiD 0xiIks04KjuXWiXH2KH9i49UzhwxNZVEUsNMBiyawuvjkX5L508zhVDduxxykIzxOa+w pIvjE9io3ehiHDxzDLJgxjqc0AAaNxM4If10RnLam/0QJ5iFR5y0v4mB50oNVFVoXZlZ P6Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785436067; x=1786040867; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=oxMTwfSaIjvnfbtlqgmrq3RFCIwcaRIsY2xtTSKtmrw=; b=Vz6m7TaXLBr/OaYI4Mgo1y2xyLKhQ92pBR1Gd2G9N+4+sSsLzrf5keZ+26k4Sws9wL QsppJG8xi+y8KuZeUYWQYUY+mxuMiMx3xDems7lICIF7AmL21HRO87oVquJl0b8SSyPb myk7vHSwOUwJbX1ozyAPHFDcBAwFnt7EKJczveI0SS9Gp5UTKZHom+xedwnaKPekTSKI /hBD8zH0+ZtquQtT0Jyz6l2H9Zkk2Ugrf3r0kJ1czhi/wLcrdlt381tOmqKMeZCTYG1M CUSofUFHnBf+QoV9QQ2f4rrR9aheZTdJzyfWV1dYW5T9vuVeXdgpYCu3EeSsZlwI2w+r SoVw== X-Forwarded-Encrypted: i=1; AHgh+RpPENIDGiHGRQdE/6ZN4WZ7Hu867wDgCrnLdK0sZneLIl5Hzy5LUyGO0Nk0DQGcN9jZlBg0qneOXA==@ietf.org X-Gm-Message-State: AOJu0YwrZlAyAaYb1aAwn0QEuRsI5akBKz50erW1l/ObspEwh9n7MG+X NWrXLNjbNi60qSf2lmRxKXZir2FloXsrtFzpR2ka5SelgARWafoRYhh4Pil137xaFqkKEcaq2uO kT8B6/WGieyWqO3D08X//ZnOBucbxY74= X-Gm-Gg: AR+sD114kLqH7cYwE1t+Xhn+8u0Wu7NV66NRp4zl4tRV244dLwU4GybZDY2+RWkr2Rq v5/aVYszc3E/Tp52hg3I+X1fkNg3zbdskni6s4oJiXaeQ08mHSVWbGi0yJe/EGbIvSk+23jHUod pg+9e29v4qriRTV9s659TrLpFswEj9XJcXdBY+VW81ScEB+ueZBhuBPUIPThuKvuAxa7IU2zCV5 uIH256yoMZn7KM64aEnctycn1trReLqUUbq7IznubMzfuRAYQFlLy7O3vOSsFIoZK5PagcwmOPY KST9E4QoRhCFj4mRQHC8aJvnjV83EYaJMZdlD4COJZRSjinC9BdAqr3ci6BpWI2mggdldBuu5IU rTx/QwBqvPYypAZIXQ5MZs8JvHOsY5E6zsqY= X-Received: by 2002:a05:690c:ed1:b0:7e8:a091:6c4b with SMTP id 00721157ae682-81fb892d652mr29004367b3.24.1785436066799; Thu, 30 Jul 2026 11:27:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Felix Linker Date: Thu, 30 Jul 2026 20:27:36 +0200 X-Gm-Features: AUfX_mwI69xSwdTKVtIR3ESsp9sweB-1x0xEjnRPF5Hd8VB-uMwQPnPmIT5TFYI Message-ID: To: Orie Content-Type: multipart/alternative; boundary="00000000000087e5ef0657d83a6b" Message-ID-Hash: WK2JAA5XT5YM6TAHALTDKTZXH3DIHGBM X-Message-ID-Hash: WK2JAA5XT5YM6TAHALTDKTZXH3DIHGBM X-MailFrom: linkerfelix@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Guy Fischman , Prachi Jain , keytrans@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BKeytrans=5D_Re=3A_Keytrans=40IETF_126_=3A_Call_for_agenda_topic?= =?utf-8?q?s?= List-Id: Key Transparency Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000087e5ef0657d83a6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What would be the benefit of going that path? Cheers, Felix Am Do., 30. Juli 2026 um 20:05 Uhr schrieb Orie : > 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=E2=80=AFPM Guy Fischman 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 eas= ier. >> 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 ded= up >> rules ("only added the first time," "omitted when the user is expecte= d to >> have retained it") that currently make the expected count a function = of >> client state. >> >> -Guy >> >> On Tue, Jul 28, 2026 at 2:34=E2=80=AFPM Orie 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=E2=80=AFAM Felix Linker >>> 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 c= ourse >>>> 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 t= he VRF >>>> output and the commitment. The reconstruction algorithm can then si= mply 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 bin= ary >>>> ladder, then initiate leafs from the prefix search results, then fi= ll in >>>> node values. >>>> - I implemented this new wire format for testing purposes, and >>>> my code for constructing prefix trees indeed becomes much simple= r: >>>> https://github.com/felixlinker/keytrans-verification/blob/ca4157= ae8aaaae0b0e5b4b4e0e9d6d08524786a1/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/3c4bb8= 3d7dbcf47a4091d54653a5b6a2dcc84a8f/pkg/proofs/proofs.go#L102 >>>> and this is the code to construct the prefix tree: >>>> https://github.com/felixlinker/keytrans-verification/blob/3c4bb8= 3d7dbcf47a4091d54653a5b6a2dcc84a8f/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 say= s: "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 draf= t 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 b= e 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 neede= d. >>>> >>>> >>>> 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 verif= y >>>>> 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 o= f >>>>> 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 implementat= ion of >>>>> a prefix and log tree is tested, but only "against itself," i.e., I c= heck >>>>> 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 th= e >>>>> client. My life would be much simpler if the change in wire format we= re >>>>> part of the draft, and I find there are certain parts of the draft wh= ich >>>>> 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 >>> >> --00000000000087e5ef0657d83a6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What would be the benefit of going that path?

Cheers,
Felix

Am Do., 30. Juli = 2026 um 20:05=C2=A0Uhr schrieb Orie <ori= e@or13.io>:
We could also consider keeping the wire format out of t= he main spec, and defer it to separate=C2=A0drafts.

SCITT did somet= hing similar for Merkle tree algorithms where the trees ended up not being = interoperable.
SCITT Architecture -> COSE Receipts (RFC9162) -> Sp= ecific Tree Algorithms (CCF, MMR)

If we went this approach, we would= need each wire format document to describe=C2=A0the requirements for inter= op.

OS

On Thu, Jul 30, 2026 at 12:09=E2=80=AFPM Guy Fischman <gfischman@gmail.com> wrote:
Sadly I wasn't able to attend the call. Here are my thoug= hts on the points Felix raised:
  • It's true that mandating TLS= makes iterop=C2=A0easier (and makes it possible=C2=A0using only the spec),= though I would claim only slightly easier. It also comes with some non-neg= ligible costs, notably:
    • TLS extensibility has to be designe= d into the structure. Protobuf gives it by default. The protocol has churne= d wire surface=C2=A0through revisions and isn't yet final.
    • Stra= nding existing deployments or requiring a translation layer - Signal uses p= rotobuf, and Whatsapp does too (but based on pre-KT SEEMless).
    • It&#= 39;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 mandat= ing TLS.
    • -> On balance I would lean toward keeping the current a= gnostic stance.
  • Simplifying PrefixProof - Agree. I believe thi= s would reduce proof sizes along with simplifying.
  • Agree, and to ma= ke a bit more concrete -=C2=A0don't specify the order, rather eliminate= the dependence on it. Carry the log entry position alongside each timestam= p, prefix proof, and prefix root. Eight bytes per entry, and the whole clas= s 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=E2=80=AFPM Orie <= orie@or13.io> wrot= e:
Hi,

I support making TLS mandatory.
I don't have enough i= nfo on the other points raised to be helpful.

Regards,

OS
On T= ue, Jul 28, 2026 at 6:31=E2=80=AFAM Felix Linker <linkerfelix@gmail.com> wrote:
=
Hi everyone,

As there = was little time for discussion at the end of the meeting, I wanted=C2=A0to = 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=C2=A0to freely c= hoose the wire format. I would make TLS mandatory. If people want to use a = different wire format, they of course still can, but fixing=C2=A0TLS 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 has= h value (can be omitted=C2=A0for an empty leaf) or store the VRF output and= the commitment. The reconstruction algorithm can then simply do a DFS sear= ch over the prefix tree and initialize it along the way. With the current w= ire 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 suggest describing= the wire format more explicitly. For example, Section 12.3, specifying the= combined tree proof, only says: "The timestamps field contains the ti= mestamps 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." Su= ch language makes the draft hard to implement because one now needs to cons= ider the entire document to understand how to parse the data structure. I t= hink this one will be quite hard to address. I cannot come up with the righ= t 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 wh= at the rest thinks!

Best,
Felix

Am Do., 16. Juli 2026 um 10:14=C2=A0Uhr schrieb Felix Linker <<= a href=3D"mailto:linkerfelix@gmail.com" target=3D"_blank">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 greates= t version queries.

The code for that can be found = here:=C2=A0h= ttps://github.com/felixlinker/keytrans-verification/blob/felixlinker/client= -state/pkg/client/client.go#L98 Development currently happens on that b= ranch.

I could not test whether the client works y= et because I'm not aware of a server implementation that generates sear= ch responses for search requests. Maybe my understanding here is wrong, I a= sked 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 invari= ants.

We also prove that our go implementation is = memory safe. We haven't gone much further than that in our mechanized p= roofs 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 t= hat first.

The asterisk that I mentioned above is = that I took the liberty to change the server response format slightly so th= at proofs are easier to parse. I could, at the meeting, present my experien= ce 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 t= he draft which are hard to implement and get right.

Best,
Felix


Am Di., 14. Juli 2026 um 16:50= =C2=A0Uhr schrieb Prachi Jain <prachi.jain1288@gmail.com>:
Hello KEYTRANS en= thusiasts,=C2=A0

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.=C2=A0


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