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
• draft-secure-credential-transfer

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

-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

-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