Key Transparency
charter-ietf-keytrans-01

[Ballot comment]
I do not believe that the current technical charter requirements can all be met. Especially the "near zero user interaction", combined with the (now more implicit but still present) requirement of "only in-band communication" cannot guarantee that the service provider is not MITM'ing every participant in a group, even if we assume all the Merkle tree magic works as expected with respect to the transparency and privacy requirements of the charter.

Having another automated trusted third party in the loop, while not a guarantee, might increase key transparency a little bit, so I won't block the current charter.

[Ballot comment]
Thanks for addressing my previous BLOCK comment at:
https://mailarchive.ietf.org/arch/msg/keytrans/EV1jPbWfWdmMFK3t5bQdME7xuW0/

Other non-blocking comments kept from previous ballot.

What is `typical end-user devices` in the charter ? Does it stop at smartphone or going beyond to IoT wearable devices ?

`download the public keys of themselves` hummm if an entity has its private key, does it also have the association public key ? Or am I missing something ? Are more explanations required to understand why end-users would download their public keys (and how can they trust that the download was not cheated)

[Ballot comment]
I support Lars' comments :)

I have a similar issue as Eric on whether a protocol can be made where clients can check the group view for consistency if all communications go via the Provider that is being tested for honesty. My questions at least lead to a clear statement on this. Now it is up to the WG to make it happen I guess :)

[Ballot comment]
This looks good to me.

However, I think it would be great if we can explain what the end to end (e2e) communication service means here. is this something p2p setup? does this e2e allow say proxied communication? what about the privacy pass kind of architecture? should any of the network nodes on the path between the e2e communication be involved or aware of keytrans (I hope not)? etc. So, a description of e2e communication service will be helpful here to understand the context and scope of this work.

[Ballot comment]
# Internet AD comments for charter-ietf-keytrans-00-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

### Program of Work

* Specifying -> Specify, and
  Standardizing -> Standardize

  might read more naturally

[Ballot comment]
-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Paragraph 15
> The solution the WG defines is expected to:
>
> * Allow an end-user to search and download the public keys of themselves or for
> other end-users; and enable a process for updating their public key with the
> authentication service of the communication service provider
>
> * Allow end-users to verify on an ongoing basis that they have a globally
> consistent view of which public keys have been associated with which accounts,
> including their own.
>
> * Allow end-users to perform this verification of a globally consistent view
> via an out-of-band mechanism for small groups, or use an anonymous check with
> the communication service provider in-band for larger groups.
>
> Out of scope for the WG is to:
>
> * Enable interoperability between end-to-end encrypted services as full
> interoperability of an application would require alignment at many different
> layers beyond security
>
> * Develop an end-to-end encryption protocol for user messages.


I'd appreciate if the scope of the WG could be made clearer. The way I
currently read it, any solution is OK that covers the first three
bullet items (under "The solution the WG defines is expected to") as
long as it does not overlap with either of the two items listed
under "out of scope". That still leaves an awfully large design
space. Could this be rephrased to talk about only those properties a
solution needs to have and say that anything else (rather than just
two items) are out of scope?

Paragraph 18
> The WG may standardize integrations of this verifiability mechanism with other
> protocols (where the exact security guarantees provided will depend on the
> underlying encryption)


Should that work not rather happen in the WGs that own these other
protocols?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 14
> tion would require alignment at many different layers beyond security * Devel
>                                ^^^^^^^^^^^^^^
Consider using "many".

[Ballot block]
Interesting WG aiming to solve a real problem.

But, there is blocking factor (trivial to fix): the lack of intended status for the work items in `The WG is expected to:`...

[Ballot comment]
Other comments

What is `typical end-user devices` in the charter ? Does it stop at smartphone or going beyond to IoT wearable devices ?

`download the public keys of themselves` hummm if an entity has its private key, does it also have the association public key ? Or am I missing something ? Are more explanations required to understand why end-users would download their public keys (and how can they trust that the download was not cheated)