# TIGRESS @IETF114 {#tigress-ietf114} 2022-07-27 Chairs: Leif Johansson and Prachi Jain Minutes is only mic discussion, no text on the slides **Admin stuff** * Note Well statement * [Meeting material][1] * [draft-secure-credential-transfer][2] ## Problem statement: Casey Astiz, Alex Pelletier, Dmitry Vinokurov {#problem-statement-casey-astiz-alex-pelletier-dmitry-vinokurov} -Jim Fenton: Can instead use a public key with the provider? -Alex: Transfer protocol, not just authorization -Dmitry: Trying to cover multiple keying types -Also have more granular control -Daniel Kahn Gilmore: Who owns the information on the parties involved -Alex: Credential authority; could be use -Leif: Please understand what the scope is, not alternative solutions -Daniel: Will this allow me to be the credential authority? -Alex: Yes -Casey: It is up to the OEM to deal with the manufacturer to allow -Sam Weiler: Wants permissionless for users -How does this relate to FIDO -Dmitry: Distinguish credential transfer from permission -Use open standards to show the authorization -Casey: Would have to go away from the privacy requirements to get that -Michael B: Implies that the relay server is needed -Dmitry: Yes, required \` \`Could also use S3 buckets -Eric Rescorla: This presentation is a view of the charter -Why not have replay attacks? -Dmitry: Don't want the same credential to be given to other people without the intention of the send -Eric: Once the receiver receives a key, they can do what they want with this -Alex: Get a better user experience -Eric: Is the assumption that the credential lives in a trusted hardware chip -Matt Byington: Wants the ability to specify a single person -Receiver can pass that along the key; goal is that only one receiver can get the key -Eric: What is the threat model for the transfer -Leif: Does the WG need a separate requirements / threat model draft? -Wayne Chang: Does the model assume a pre-shared secret key? -Dmitry: Yes and no -Maybe attach the key to the URL if the transport is trusted -Wayne: Is an authorization model possible? -Alex: Yes -Peter Thomassen: Assume there is an opaque credential -How does go beyond any other secret message? -Dmitry: Share the encrypted content, no pre-shared secrets -Just credential transfer between two actors -Ian Williams: Trust between sender, recipient, and relay -Does the relay have to agree? -Dmitry: Yes, it needs to have its trust established -Need shared root of trust -Recipient does not need to trust the relay less; can use verification codes -Covered by device attestation step -Can also add trust between recipient and relay -Nick Sha: Recipient will have to choose the relay server \` \`Will be a list of trusted relay server -Eric: Assumption is that channel cannot move an arbitrary amount of data -Assumption is that sender is not trusted by the credential provider -Cullen Jennings: What are the constraints? -Want to use any channel, like 100 characters or less, even a written URL -Viktor Dukhovni: Is there thought of spamming or phishing? -What about the mostly-naive user? Can the sender be spoofed? -Dmitry: Content has to be trusted by the relay server -There will be a preview shown to the recipient -Alex: Not yet covered -Casey: Can delete the mailbox before the recipient has provisioned -Can also be revoked -Naming is hard; do I know who I am sharing with? -Nick: Out of scope -Matt: Sender doesn't have confidence of the identity of the receiver ## Proposed solution: Dmitry {#proposed-solution-dmitry} -Viktor: Looks a lot like GSSAPI in HTTP -Uses the same state machine -Dmitry: Haven't looked -Eric: If over a small channel with limited length, how many bytes are left? -Dmitry: Enforced by the standards at the time of provisioning -Eric: If the channel has a wide capacity, what is left in the protocol -Matt: Would not need a relay -Eric: This seems like a weak sauce version of WebDAV -Why are we creating another messaging system -Richard Barnes: Is the receiver doing just a GET request, or do they need special logic? -Matt: Need a special logic? -Eric: Is this a messaging protocol for one purpose? -Dmitry: It is a protocol for fulfilling the specific problem -Richard: Similar to a file transfer protocol over a limited channel -Discussed in DISPATCH on Monday -Could I use this to send other types of messages? -Dmitry: Needs just to move tokens with the relay to not be able to see contents \` \`Also focused on mobile devices, that have many limitations \` \`Included push notifications -Cullen: Is push notifications part of the spec? -Alex: Still thinking about it, required for mobile devices -Rohan Mahy: Lots of requirements that weren't in the first presentation -People are asking requirements questions -No real description of the requirements, including subtle ones -Some people might add new requirements -Casey: Always found something that was missing -Dmitry: Balance between security and usability -Chris Lemmons: What relationship have with the sender or receiver? -Casey: Sender has tight relationship with relay server -Dmitry: Sender has to trust the relay server to hold messages -Chris: The relay server needs to know the sender so they can limit storage -Nick: The only restriction is what the relay server is willing to put on -If the sender and receivers are OK with the restrictions, they can use what they want -Casey: Can configure mailboxes to be small -Richard: This is an OK starting point for this work, might be useful to other IETF work -Eric: What is the attestation being used? -Nick: Very general attestation; could be a key pair -Up to the relay to decide what it allows, doesn't need to use attestation -The choice of the relay server is up to the implementer -Eric: This is probably part of the security requirements -This could create a new locus for tracking -Creates a graph of who shares with each other -Dmitry: It's up to the credential manager -That is out of scope for this protocol -Peter: How will work on the recipient's device? -Does the receiver also have the app? Or can it fire up the browser? -Circular trust -Dmitry: Sender needs app that knows the relay server and how to pass the URL -Receiver might integrate with other messaging -Sender can have attestation to increase trust -Casey: If receiver doesn't have a matching app, the URL could cause retrieving app -Peter: Maybe make it clear in the URL that this is a credential getter -Peter: Don't use "mailbox", wrong term -Chris: For a given type of credential from a particular authority -Could a relay that is not authorized be used? -Dmitry: Has to have a level of trust between credential creator and sender -Device attestation is optional -Chris: How does the CA influence the relay server that the sender chooses? -Nick: It does not matter -Chris: No policy reason not to use my own relay server other than confusion on the receiver -When you receive this URL, how does my software know this is a credential? -Nick: It is a parameter in the URL -Paul Hoffman: Seems like there needs to be a lot of requirements -Roman: Get the requirements down, we'll later figure out where they can be put -Maybe separate document, maybe in the protocol document -Eric: Really wants requirements so can help see what might not work -Cullen: Show one possible deployment, show where the IETF parts are used -Viktor: Anti-replay seems to be done by relay -Can create downstream relay that does its own replay -Casey: The credential authority sees the use and prevents reuse -Nick: In CCC, also is an immobilizer token to use the credential ## Finishing topics {#finishing-topics} -Should the WG adopt the current draft as starting point for work -Change control would be passed to the WG -(Done with Meetecho tool) -Raise hand: 17 -Do not raise hand: 23 -No consensus not adopt -Feels that there consensus for a separate requirements document [1]: https://datatracker.ietf.org/meeting/114/session/tigress [2]: https://www.ietf.org/archive/id/draft-secure-credential-transfer-04.html