- Welcome, note taker, Note Well, chair updates (Chairs) - 10 mins.
Slides
- Protocol draft discussion (Brendan McMillion) - 60 mins.
Slides
- Contact monitoring and auditing modes (Esha Ghosh) - 15 mins.
Slides
-
AOB and closing (5 mins)
-
Chairs welcome & agenda bashing
-
Protocol draft discussion & presentation (Brendan McMillion - BM)
- draft-keytrans-mcmillion-protocol overview
- Jonathan Hoyland (JH): can you check for non-existence of a key
with the same version?
- BM: follows from how the binary search works
- Bengo Goering (BG): question about search path consistency
- JH (from floor) & BM: ... answer about how the search works
- BM continues presentation
- Yaron Sheffer (YS): do you want to ensure that the server is not
cheating and isn't giving different answer to different clients?
- BM: the user can hold on to the last root hash and use it to
ensure consistency over time, also gossip with other clients to
ensure consistency
- YS: what is the minimum effort needed to ensure consistency?
- BM: unclear
- Deb: solicit reviews from the WG!
-
Esha Ghosh (EG): presentation on client monitoring and 3rd party
auditing (part of the arch draft)
- Felix Linker (FL): doesn't the client need to remember the key
history?
- EG: client don't need to carry state but the user will need to
remember some things about their updates
- FL: client state could help to automate this?
- EG: best if we can support stateless clients
- Ben Schwarz (BS): client need state to keep their key?
- EG: should be able to detect lost key state
- BS & EG continues discussion about the need for client state
- EG: security isn't compromised when state is lost - wo state you
can at least have detectability
- Watson Ladd (WG): question the real-world usefulness for
stateless detectability
- EG: ...
- Dennis Jacksom (DJ): there are usability issues that aren't
covered by this representation. need to look at the actual
usecases.
- EG: agree
- JH: what is the usecase?
- EG: i lost my phone and somebody changed a key on my behalf
- EG: continues presentation - cost of covering both modes,
comparative analysis
- FL: asks question about the v-factor from the slides... what
does this mean?
- EG: explain difference between v & t
- BM: what persistent state exactly don't client need?
- EG: no need for a signed tree head or a key
- WL: why are the costs different?
- EG: the data structures are different
- FL: re BM question: what keys did you mean
- EG: the clients key
- EG: continues presentation on datastructure
- ... some clarifying discussion
- JH: you need to keep a hold on the tree head?
- FL: inaudible...
- JH: as long as you are only going to the transparency server it
can lie about my peers (?
- Dennis Jackson (DJ): you need to talk to somebody who isn't the
attacker to detect an attack
- EG: continues presentation on 3rd party auditing mode
- YS: question about the impact of the centralized architecture on
the threat model - how do you avoid getting lied to by the
server?
- DJ: agree..
- FL: agree ... (mostly inaudible)
- Thibault Maunier (TM): integrity isn't a goal but consistency is
- EG: continues presentation (client monitoring mode slide)
- EG: question to WG: should we support both modes?
- FL: doesn't the current draft already support auditor monitor?
- EG: yes but not optimally and not wo keeping state
- FL & EG: discussion - FL argues that the current draft already
supports 3rd party auditors well enough. EG: claims key
searchers would be more efficient
- WL & EG: clarifying discussion about the difference between the
two proposals wrt comparative search costs
- BM & EG: optikc will be less efficient for some other modes than
3rd party auditing - a tradeoff
- Shivan Sahib (SS) - chair: is there interest in these draft(s)
from the WG?
- HannesT (HT): both proposals seem close to each other - can the
difference be quantified in absolut numbers?
- EG: will link to papers with some research
- SS: any deployments?
- EG: similar to what whatsapp deployed
- FL: believes that the differences are not critically different
- EG & FL continues discussion about weather the proposals are
really different
- BM: propose an offline discussion between the two proposals
- SS: chairs will facilitate
-
wrapup and done