Note takers: Martin Thomson
Mari shared implementation status and a list of wants: more
implementation, test vectors, and lack of auditor interoperation
specification with the KT implementation.
Felix asked about what it means for auditing interoperation.
Mari explains that this is about checking that the log is append only
and that the key head is consistent.
Shivan exercises chair privilege to ask a question about whether Signal
is making changes to the protocol document and if those need to be
brought to the IETF.
Mari took an action to ask Signal about their changes.
Shivan also asked about client implementation.
Brendan mentioned that Signal is tracking changes in the draft since
their original implementation was against an older version of the
specification.
Signal's open source implementation:
https://github.com/signalapp/key-transparency-server
Slides:
https://datatracker.ietf.org/doc/slides-123-keytrans-architecture-and-protocol-document-review/
Brendan notes the ownership rules, which now covers the entity that
makes changes OR the entity that is informed of updates
... and the addition of timestamps to loosen ordering requirements for
correct log operation
... and the potential for auditors to run audits over any span of time;
they don't have to start from time zero (which is impossible if it was
deleted anyway)
... Then gave an overview of operations and modes; the document from a
high level, including some of the advice necessary for effective
operation, as opposed to interoperation
Slides: (as above)
Brendan notes the addition of Third Party Auditing and Management to the
protocol document.
...addition of registry of cipher suites. Specification Required.
Getting more cipher suites will require pushing docs through CFRG and is
out of scope for now.
...overview of the protocol document including tree structure, combined
tree, search functionality, monitor
...changes that will be added before next IETF
...notes that implementations are a little outdated relative to the
current drafts.
Shivan asks about implementations
Felix asks about third party management, which requires that every
update is signed. Is there a different way to manage this process, like
mTLS. Suggests that some flexibility might be appropriate.
Brendan the idea is that the signature goes to the Service Operator, but
goes to the clients that make Search requests. Maybe we could have it
signed differently.
Felix acknowledges, but asks which set of parties are in the threat
model and what needs to be protected. You might drop signatures entirely
in some cases.
Repository: https://github.com/felixlinker/keytrans-verification
ONE SLIDE: no significant results to report
... progress is slow: hard to verify the identified properties, hard to
find time
... no security issues so far, but a bunch of small issues (all should
be addressed in the draft)
Prachi asks about architecture document and whether it needs updates
Brendan notes that there is a need to maintain some amount of state and
what the implications are if state is not retained
Deb asks if Brendan is getting enough input and reviews
Brendan asks that people start reviewing because the documents are
getting more stable