TIGRESS WG Agenda at IETF 117

• Thursday, 27 July 2023 at 17:00 - 18:00 PDT

0) Note Well, Minute Taker, Jabber Scribe

Note takers: Pam Dingle

1) Agenda Bash

No changes to the proposed agenda

2) Discussion on recently adopted WG docs

• no open issues on docs - doesn't mean there aren't actually issues,
  please give feedback
• volunteers to read drafts: David (DW) Waite

• Eric (Apple) - requirement that sender/reciever are not present at
  the same time, but don't want to tie them together, how does that
  work?

  • goal is not to tie sender/receiver over multiple transactions

• Next steps: exploring design directions

a) draft-tigress-requirements (https://datatracker.ietf.org/doc/draft-tigress-requirements/)

b) draft-lassey-tigress-threat-model (https://www.ietf.org/archive/id/draft-lassey-tigress-threat-model-02.html)

3) Discussion by authors on protocol draft

https://www.ietf.org/archive/id/draft-secure-credential-transfer-04.html

• Yogesh: a couple of viable candidates- one is the HTTP extension.
  Good time to revisit that solution. 2nd approach - webDAV. Reactions
  were varied
• performed an analysis - this could work with minor tweaks but a deep
  dive is needed
• Roundtrips requirement: idea is that enough information is needed
  from both participants that there has to be a back-and-forth. Are
  new resources created, the same ones modified? How can the
  participants take turns?
• ECR: if everybody here wants a new thing, but it isn't the best
  thing you are probably still farther ahead. Question is, what is the
  energy level of the group? Is anybody advocating for webDAV that is
  also going to implement?
• Brad L - it is worth exploring, then comparing.
• ECR: Can think of ways to do this: files indexed by numbers, eg
  mesgs from alice to bob are odd, from bob to alice are even etc.
  Whether using WebDAV or not, the more like a drop box this is, the
  happier we will be.
• Eric: not sure I want my door locks to have more webDAV. Reasoning
  about what is the shape of what we build is valuable. Then you can
  look at each implementation option to see the delta. Understanding
  conceptual thing this is analogous to could have great value, eg:
  drop box.
• Yogesh - agree the drop box is a good analogy. Goal here is to
  discover whether vanilla webDAV can work, but clearly that can't. Do
  we want to go down the rabbit hole just because we are obsessed with
  webDAV?
• Eric - worth looking at what is the delta rather than jumping away
  from webDAV without going to the "other" answer automatically
• Kaliya: question - when you say credential do you mean password? Is
  this like the encrypted data vault work, using obj capabilities to
  access cloud repositories?
• Yogesh - credential is loaded term, here a credential is a set of
  cryptographic tools that grant access to some property (and some
  metadata). If I get a key to my hotel room but it isn't valid until
  3pm, for example this could be the basis for additional access
  control
• ECR: (question & following discussion is opaque to the scribe,
  sorry)
• conversation about locking vs. deletion of credential during
  transfer
• Eric: if I am sender A and i send to receiver A, if random attacker
  can access that, that is bad. Theft, interference, incompetence,
  tampering, that will be an issue
• Yogesh - the problem is that webDAV defines access control
  mechanisms that are more open than we want.
• Eric - in my mind, webDAV - not about does the thing we build on top
  of satisfy all the req'ments, just is it a place we can start.
  Details that create question marks may be worth doing the exercise
  to address. Access ctrl vs locking is something we can identify, but
  wouldn't be the end-all be-all. Looks like you have sufficiently
  identified the issue, so we are good.
• Leif - to summarize, this comes down as "operational considerations"
  • doesn't necessarily mean webDAV has to change, maybe it just gets
    profiled down. Not a problem if something like webDAV has to be
    profiled

• Yogesh - trying to know what is easy and what needs more work.
  another requirement for webDAV is connection integrity

  • need to ensure injection isn't possible

• 3rd requirement: non-correlation. prevention of correlating users
  between exchanges, prevention of mapping social graphs

  • found areas without answers - how, if authentication is needed,
    the server won't be stored?

• Aaron: lot of parallels to other work (eg in OAuth WG). These
  requirements have been discussed there and so you should be able to
  leverage existing building blocks. WebDAV seems not to fit perfectly
  but there could be other options. tomorrow's OAuth meeting may be
  useful, verifiable credentials will be discussed and this may be
  helpful.

• Prachi requested Aaron to review, Aaron agreed.

• ECR: asking about access control in webDAV

  • wrestling with the web model. Treat this like a read-write
    transaction on a resource, your issues go away entirely. Will
    send something to the list

• Eric: step 1 is establishing it is "mine" so I can come back. I
  leave a space open for "slot #2", once slot 2 is filled, then that's
  it. After that, the establishing token and the token in slot 2 are
  the only participants that can interact.

• Speaker #2: Understand solution isn't perfect, but privacy is
  preserved
• Aaron: Capability URLS are not necessarily best security practice
  (EKR disagrees). problem with capability URLs is it is same string
  used by sender/reciever. Have fundamental problems, and many groups
  are working on solutions. Could be a solution that doesn't rely on
  the URL being the only thing protecting the credential stream.
• Eric: let's not rathole on details, but talk about what are the
  building blocks
• Yogesh: mechanisms will change - what we are trying to build is
  based on intention to share a credential
• Speaker #2: still want attestation
• John B: what does support for WebAuthn mean? Hybrid transport exists
  now where a piece of key material is exchanged that could accomplish
  this.
• Brad: what are you attesting?

4) Next steps and closing remarks by chairs

• Leif: suggest a good next step: we have multiple options - can we
  get some quick strawmen? No need for fancy writeups, just something
  to critique and judge. Can we tease out the details?
  • Will need to schedule at least one interim before Prague. Nice
    to see this interest turn into concrete thoughts sent to the
    mailing list.
  • Prachi - got new volunteers - yay! Please reach out.