Skip to main content

Minutes IETF120: keytrans: Fri 22:30
minutes-120-keytrans-202407262230-00

Meeting Minutes Key Transparency (keytrans) WG
Date and time 2024-07-26 22:30
Title Minutes IETF120: keytrans: Fri 22:30
State Active
Other versions markdown
Last updated 2024-07-30

minutes-120-keytrans-202407262230-00

KEYTRANS WG Agenda at IETF 120

Agenda (90 mins)

  • 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