SECRET BOF

10 Thursday 2022

Chairs: Leif & Sean
Scribes: Sean, Francesca

Agenda: Here
Minutes: Here
Recording: Here

Administrivia

Slides

SECRET Proponet Slides

Slides

• Richard Barnes asked a clarifying question about what kinds of credentials are in scope
• Michael Richardsson: does these credentials conform to some standard? sender/reciever/relying party
• Richard Barnes: revocation in scope?
• Erik Rescorla: another scoping questions. Does the protocol need to specify the entitlements?
• Casey: No, that’s not what this WG would doing - it could just be a payload.
• Matt: The ISO definition includes an entitelment credential that includes a bag of attributes including time, speed, etc - really whatever is defined.
• Matt: there is also the idea of local and remote. Local, in the case of car, is you. Remote, in the case of hotel, is hotel owner.
• Richard: Even in the local case, I do all the work and put in the transfer protcol.
• ekr: Can you expand on that requirement?
• Demitry: Good question. We might receive a lot of person info. We don’t know what’s stored by the solution, but we need to make our best effort to not store that information. Say I want to share with MAtt the solution shall not know who is going to redeem that share. The way I pass that is indepenent from the way the voucher system is stored.
• mcr: I keep hearing private I think you mean access.
• Demitry: yes we’re not sharing privates
• Chris W: How does the sender do a cancelation if the sender is offline?
• Demitry: we don’t want both sender and reciever to online at the same time.

Discussion

• rlb for Partick Tarpey: Does the sender get a notification that the receiver has access?
• Matt: That’s a good question.
• Mattias: Depends on the use case. For cars, the manufacture is in the loop. They are also in the loop for revocation of the attestation.
• rlb: I think my question was simpler. I knonw when I have done the sending operation. Can I know whether the credential was used.
• Alex: We have been thinking …
• Casey: I was going to add that just receiving the cred information doesn’t mean that the receipient has used the cred yet.
• rlb: so it’s not just that the bits got sent.
• Matthias: there is a push and a pull model. Hotel is pull and car is push.
• ekr: what responsibilities are in scope and which are not? I give rlb my car keys for a month and then I revoke it in two weeks. We don’t have to worry about those.
• matt: yes
• ekr: when it is flight and Toyota will take care of stopping it.
• matt: there is one that’s also in the middle. there are three flights needed … he describes them.
• rlb: on one hand we intended sending to an intended recipient, but we don’t want the transfer service to know who the recipient is.
• Matt: explains how it might work
• ekr: Why does the mailbox has to be secret?
• Matt: mailbox is reliquishing secret data so that shold only the person that has the private. Allows the transfer service to DDoS prevention. Helps ensure the sender’s input only gets to the receipient.
• ekr: I think this in the opposite way. What’s the trust model against the relay server. Need to provide some thinking about protecting the system.
• ekr: If the properties is that there is no bidning to the …
• Mattias: I think the relay server has very little security properties. The most important to release the credentials just once to one recipient. After that can’t copy the credentials. The encryption is a secure channel, but the one who has the key can decrypt. Mainly for privacy but not really security. How the key gets to the right party - difficult one you go cross platform.
• Stefan: Who will select thre relay server?
• Matt: The sender would be selecting the relay server. TYpically be a relay server that manufactureed the device.
• rlb: flexibility around who is the relay service adds to the identity question.
• rlb: are the some negotiation about what is supported?
• Demtiry: We were thinking about this a lot. What happens if my friend sends it to me and I’m on a laptop that doesn’t have the secure element … need to forward it to the device that does.
• ekr - nince to have for the record to have some kind of list of who are the players?
• Nick -we are int
• Matt: apple
• JK: name is not great. security area seems more appropriate based on the amount of comment.
• leif: where this lands is for the ADs.
• rlb: agree name is not great. can get the right sec folks in an apps area.
• rlb: do we have the right folks? Nick mentioned CCC. Are device vendors are here too. Credential folks?
• Francesca: As AD, the ADs are talking and synchinng and are aware it’s cross-area. If it’s in Sec it will get an Apps AD and vice versa.
• Ben: what Francesca said ;) I would respond to JK by saying we’re talking about security requirements.

Do we understand the problem: 26 yes/1 no
Is the problem space worth solving in the IETF? 19 yes/0 no
Who is willing to edit drafts? 8 yes/8 no
Who is willing to review the I-Ds? 14 yes/2 no
Who is will to review the I-Ds as an ART person? 5 yes/3 no
Who is willing to reviw the I-Ds as an SEC person? 8 yes/1 no

Charter Discussion

mcr: we are delegating credentials
stfcd: out-of-scope needs work, also need to udnerstand the security of the credential?
leif: are they out of scope?
matt: we can clarify the language a bit
ekr: we don’t need to understand in detail, but the underlying assumptions should be noted.
rlb: agreed to that. It would be good to say this is not a tunnel protocol between two devices.
Ben: in the chat: do we want to talk about person or user agent?
ekr: last two privacy goals need to be rephrased to be more protocol-specific. On the solution: there needs to be more context about a round-trip. Will submit PR.

spt: seems close enough that work this on the mailing list.