Internet Engineering Task Force Interim Meetings, 31 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-PRIVACYPASS-20220131-1700

Description

PRIVACYPASS meeting session at IETF
2022/01/31 1700

https://datatracker.ietf.org/meeting//proceedings/

A

It looks like we have two.

B

And did you did you see the main slides there too.

C

Some reason it's not listed under meeting materials, but if you.

D

C

uh One of the five power buttons.

B

Yeah yeah we're trying to do it, but since you're sharing we can't see what it is.

C

Okay, I'll take that down, so you can just try yeah.

B

All right, just one of you, want to give us permission to try, or do you see it. Chris.

E

No, I'm waiting for one of the chairs to approve your request. Yep same.

A

All right now, I.

C

Don't see a request, oh, I see a grant yep cool, oh.

A

There it is okay,.

B

I see it technical slides got it all right.

F

I'll I'll stop sharing now.

B

But it looks good.

A

All right ben, you want to kick us off.

C

Well, okay, let's see it's uh is there a clock in the here somewhere?

C

Well, it's uh it's only one minute after the hour, so I think we can give folks a little bit more time to to come in I'll uh we're going to continue mentioning that we will need an official minute taker before we can start. The session uh minute takers are are only required to note relevant and important points from the discussion. A full transcript is not required or expected.

G

Quick question ben yeah is this: uh being? Is this recorded, it does say, recording just making sure that it is.

A

Recorded, I don't know that we have any control over the recording.

G

Well, it says it's being recorded, which I think is a good thing- I'm not getting against it, but I want to make sure that it is being recorded made available because I'm looking at the number of participants and it's 17.

C

Yeah and it'll be good.

G

For thanks for reminding us.

C

Of that uh yes, so another reason you that that being a minute taker is not terribly difficult, is that the full contents of the meeting are actually being recorded. So the only thing we're asking for a minute taker to write down are the substantive conclusions reached by the working group in the course of discussion. Anybody who wants the full details can always go directly to the recording.

C

Okay, I think that uh that people have have more or less finished trickling in.

C

So I want to remind everybody that this is an ietf session. It is covered by the ietf note. Well that covers both things like patents and ipr related to any discussions or activity in the working group and to the code of conduct, which requires us all to be professional and respectful in our communications here I'll I'll avoid trying to summarize the full details of the ietf note well, but if you're not familiar with it, please do familiarize yourself with it before participating in the working group.

C

As mentioned, we do need a minute taker before we can begin the discussion in earnest.

C

So if anybody would like to volunteer to to record some minutes, please do let us know the note taking tool is: uh is right up on the top of your meet echo screen, it's the fourth button from the left at the very top. I believe so it's very easy to jump in and make some notes.

C

We would appreciate it.

B

Jabber, if you finkel.

C

Okay: okay, thank you very much.

C

uh Thank you to matthew finkel for volunteering to take some notes. Anybody else who has a moment to to help out is welcome to do so in the collaborative note-taking tool.

C

If you do need to go to the microphone and don't want to or are technically unable to use the voice features in meet echo. Please just type your question into the chat, with a request for it to be brought to the microphone and one of the chairs will handle that for you and when you are coming to the microphone, please help out matthew finkel by stating your name so that so that we know who is speaking.

C

Let's get started, this is our proposed agenda. We have 90 minutes for this session.

C

We have three presentations, I think in each case, we will try to take only clarifying questions during the during the presentation and then have a few minutes for a more general discussion before coming back to the next set of slides and, finally, an open discussion at after all of these presentations to consider how we should take action as a as a group based on the new proposals and and changes that have been brought before the working group.

C

I think we're ready to get started with our first presentation, so I'm going to turn my slides off and approve chris wood for slides.

C

uh Chris wood and john iengar, it's all yours.

E

All right thanks, um so I'm gonna talk, I guess about half of the architecture. I'm gonna hand it over to john to do the rest, uh so there's gonna be an awkward split in the middle. uh So apologies for that, but you know we can work through it.

E

um Okay, anyways, uh so this whole set of presentations is the result of uh a couple of us going back to the drawing board and looking at you know what is the state of privacy pass in terms of the architecture in terms of the protocols um and how can we sort of move it forward to something?

E

That's you know feasible to implement feasible to deploy, um while still satisfying uh the the use cases in the charter um and all the you know the existing like w3c considerations and whatnot, um uh and upon like revisiting the architecture um we found that it didn't quite capture uh the the intent of the you know, the the overall desired ecosystem and we're going to kind of lead you, through our thought process that led to this new proposal, the architecture document, and so hopefully, at the end of this, it becomes clear why this new reframing of the architecture is, I think, more appropriate, given the the scope of this particular group and what we're here to to achieve.

E

So with that said, um let's jump in I'm going to motivate the architecture by just reminding everyone sort of what the interaction for privacy pass is right. Now, so let's say you have a client and a server who are interacting with one another.

E

The client is specifically talking to the server or interacting with the server to get some particular resource on the web, say an image in this particular case, um but the server upon you know getting this request from the client uh decides to to challenge the client, because it looks suspicious, you know, comes from an ip address, that it doesn't trust or has a poor reputation, as was the case with tor. The original motivating uh use case for privacy pass or whatever other reasons the server might have to challenge the client.

E

The client upon getting this challenge will solve it for some definition of solve and generate a proof based on the challenge and sort of generically, using the word proof here to just talk about. You know something that was done to satisfy the challenge uh that the server just sent and sends along to the server.

E

If the server's happy with this, as in you know that the proof checks out for that corresponding challenge, the server happily does whatever you know. The client requests in this particular case um getting the picture of the doc.

E

The interesting piece of privacy pass is really this middle. This middle section, this challenge and proof interaction.

E

Now, if you go back to again the original motivating use case for privacy pass, it was that the challenge was expressed in terms of a captcha. You know: can you solve this capture? That was what the question that the the server asked the client and the client would.

E

You know, engage the user to solve the capture, click on buses, sidewalks whatever, and then the solution to the captcha, which was the proof, was sent from the client to the server and the server would just check that you know it was valid for that particular instance of the captcha, but there's really nothing that says that the actual proof that the client sends has to be a solution to a captcha, and this was the you know the key insight of privacy pass.

E

Rather it could be proof that the the client had previously solved the captcha, like I interacted with the server before I got some proof at that. That point in time that I solved a particular captcha and so at some point in the future. If I get challenged again, I just re. I represent that proof to to the server we're not representing present, that through proof to the server and if the server trusts the particular proof um everything checks out, but you can generalize this a bit more.

E

It doesn't have to be a captcha that the server asks the client to solve. It can be, you know, any type of property that the server wishes the client to attest to. So capture is just one example of that. It could also be you know: do you have a valid account for for this particular application?

E

Do you have a valid device that you're using to access this particular resource and any combination of properties? Really that makes sense for the server's particular application and the client upon getting asked to attest to these particular properties, or this particular property can present that proof to the server and the server can check it based on you know whatever and then do whatever the client wants.

E

So, let's uh now sort of break down what happens when a client attests to some particular property and then presents a proof to the server. Let's imagine there was a separate function for uh that. The client interacted with for testing to a particular property and then kind of kind of getting proof that it did this attestation, so in the interaction before the server would challenge the client to attest to some particular property.

E

Client would then go talk to what we call an issuer. It would do the attestation with the issuer.

E

And then the issuer would present proof of attestation. The client would then relay right along happily to the server and if the server trusts this particular function this this issuance function, then this is indistinguishable from the case we had before, where the server was like the one doing the attestation and generating the proof and then checking the proof later on.

E

If you have this trust relationship between server and the issuance functionality, the the the the resulting system is effectively the same, but we can decompose this even further.

E

Imagine now you took the attestation piece of this and you you made it explicit and pulled it out of the issuer, and so in the interaction that we had before the server would challenge the client to test some property client would do this attestation to some a tester.

E

The tester then would, on behalf of the client, ask for a proof and the issuer, assuming that it trusts this particular tester would generate proof. A tester would forward that proof to the client and then the client would present that proof to the server and so now the trust relationship sort of looks like this. The server trusts the issuer to present to to generate proofs the issuer trusts the particular tester to do attestation of the client, and then this this arrangement, we argue, is basically the same as the original.

E

You know, interaction where everything was collapsed together and indeed that's what the privacy pass. Architecture was written or that's the way it was written. It was written such that everything in red was the same box. It was referred to generically as an issuer, but really we can. We can split out these functionalities into separate, separate functions.

E

It's separate functions that exist on the same box or separate functions that are run by separate members of the ecosystem, and that's that's the the the new sort of reframing that we're we're proposing for the architecture document and with that said, I'm going to now uh do the awkward transition over to janna to to describe more about the different variants of this.

E

So I'm going to stop, sharing and then and then be quiet. Well, I was going to ask you if you could just continue.

G

uh Sharing, but that's I I could, but it's it's probably.

G

All right can we get to slide 14, okay, there. We are okay, end of awkward transition. Thank you, chris. We made it as awkward as possible. Hopefully that woke you up from your well. Whatever time zone you are in um so uh continuing just left off. Basically um the idea, the important idea here- and this speaks also the question that's uh npd is asking punjab. The idea here is that separating this separating these functions- and we want you to think about these as functions that are that are part of the architecture anyway.

G

Separating them out gives us degrees of freedom. Now, of course, the degrees of freedom are useless. If you can't do something with them and we'll talk about that later.

G

But but this allows us to be allows us to instantiate multiple different variants, so to speak or instantiations of privacy paths bear in mind that we don't need them all to be separate entities like, for example, in in the existing privacy pass architecture you could think of the issuer, as uh the architecture is the first one which is like a combined origin at a certain issuer where everything is the same same entity. The client speaks to the origin, and the origin also happens to be the attester and the issuer at the same time.

G

So that is one instantiation of this architecture that is possible.

G

You can also have a second instantiation where you have separate origin and a combined issuer slash a tester where the client speaks to the origin and then gets a challenge and then goes off to this other entity, which is the attac surplus issuer and uh uh and and gets this um uh gets the gets, the proof that it takes back to the origin and, finally, all separate entities as well. um This is this is separate again separating of the architecture. Yes, it does make.

G

It seem a bit more complex, but it does give us uh benefits, because we are able to do some things here, that we can't otherwise do and we'll get to that in the details. um But I'm going to talk about uh just architecture at the moment, npd again we will. We will get to that, especially the rate limiting document speaks to the all separate case, because that is one instantiation of the architecture that you need to be able to do um rate limiting anonymously for for clients.

G

So you will see that, in the rate limited example, but, generally speaking, we believe that the that this, that the separation allows us to to to build more use cases within privacy bus, so uh the protocol structure for this architecture is split into two, and these are described in the architecture document.

G

The first one is the redemption protocol. Then the redemption protocol is simply where the client is able to redeem proof with the origin, and this is a consistent uh protocol for, uh for all of the use cases that we can do with this. That's the goal is to sort of have one redemption protocol, no matter what the use case uh so that the client origin interaction remains exactly the same.

G

The extensibility in this architecture comes from being able to have multiple issuance protocols, because the issuance protocol effectively says hey, I'm going to issue you a proof for a particular property that uh that the client has to attest to, and that defines the issuance protocol to some extent and the particular details of that would depend on the use case. So for different use cases we might have different types of issuance protocols, and this is this is an exchange that we can extend. We can replace it for new deployment models so again.

G

The idea here is to keep the redemption protocol the same for all use cases, but have different issuance protocols for different use cases.

G

Stepping back uh the big picture here is that the architecture now the new proposed architecture at least uh argues that some function attests to a property that is associated with a client such as a captcha or something else.

G

The issuers are the ones that uh that look at what the address is attesting to, and then they produce a proof or a token that is bound to that property and the redeemer then consumes the stroke right or the origin consumes. This token, that is generated by the issuer, so those are the functionally those are the those are the pieces that we believe are part of uh the the architecture here. So to the question of, why do we want to rework the architecture?

G

I've said this in, in other words already, but generally speaking, the high level picture here is that the current architecture tightly couples these two pieces that we're trying to separate out and separating the issuance and redemption parts allows us to have new deployment models that are uh that are that are possible now and that that we'd like to be able to build to, but are not really possible, with the existing privacy plus architecture.

G

um The the new issue, as I said, the new architecture, uh leaves redemption on change, leaves redemption as it is for not reduction as it is, but creates a dimension protocol that remains the same for various uh uh use cases, but you deal with them uh by changing the issuance protocol.

G

uh This makes attestation explicit as an architectural piece, but it is only you know. It is explicit as a as a instantiation as an entity only in particular deployments, not in all, depending on your deployment. You might want to instantiate it separately or combine it as I showed earlier.

G

So. Finally, our proposal here is to define the architecture in terms of these functional roles, the uh the flexibility that this offers obviously comes with some complexity in understanding the different roles, but really we believe that it is.

G

It is uh separating these roles if they were hidden anyway and the degree of freedom that it offers us allows us to express some use cases in privacy paths that we weren't able to, and it defines the protocols in terms of the redemption and the issuance protocols- and we have a pr here that describes this architectural change that we like to merge into the architecture document.

G

That's all I've got checks. Do you want to do questions now? We've got five more minutes left in the presentation.

C

Yeah, this would be a good time for any questions.

A

C

The draft about sorry about this um proposed change to the draft.

G

Chris should come up to the mic.

C

So hi, uh not as chair uh in this new in these diagrams, you, you have four entities and three communication links which of these links are standardized or standards relevant and which of them are essentially by private agreement.

G

um So the hard uh uh I'm gonna understand, maybe uh tommy you can jump in um the the the the protocols are standards they're, all standardized. Like I mean all of these three entities are effectively can be separate, completely separate organizations and therefore the protocols between them will need to be standardized, and that's that's uh in the different protocol documents that we have tommy. Do you want to add something.

B

B

Yeah, I think the answer is it's a little nuanced, um so then I would say between the client and the server.

B

I think you should be really standardized and I'll be talking about kind of that challenging phase.

B

I think that's kind of the most important be very because you were imagining that this is mainly a client talking to a web or some other server, that it doesn't have a prior relationship with, because otherwise it wouldn't need anonymous attestation validity, so that one, I think, needs completely standardized.

B

On the other side, I think it gets a little bit um more flexible depending on the situation, so you know, I would argue that even in the existing architecture, um the actual attestation step of solving the captcha, you know that part itself was not standardized. um The thing that the client does to the attester to say I am legitimate, and even if it is standardized, I don't think that's something.

B

That's within scope for privacy pass itself, we're not defining how you do captcha we're not defining how you do device association or account login or whatever else it is so there's kind of like some step in there. That is unique to how the client talks to the thing that lets it get tokens, and that is specifically not standardized in this group, um but uh you know, as we will go into in the third presentation around issuance protocols.

B

The way you actually get a token. You know that needs to be standardized and that's what already existed for the issuance protocol. Saying: hey, here's, how you use a pop-rf or here's, how you need to get a publicly verifiable token, and so there's there's a bit of standardization on the issuance protocol.

B

But I think it's expected that, no matter how you deploy it with the tester and issue were combined or separated.

B

There is some bit of like additional things that need to be added to the exchange that are not in the base. Privacy pass spec that actually prove that this is a legitimate client. Does that make sense.

C

That's certainly helpful thanks.

C

Let's move on to the next presentation.

B

All right um was my audio still choppy. I saw that in the jabber.

C

It seems to have improved.

B

Okay- that's that's great all right!

B

So now we're going to go into the two halves of the protocol that we talked about and I'm going to start by talking about this challenging redemption phase. Oh, and could the chairs restart the timer? Actually because I'm getting the red flashing lights that I'm almost done great, all right so going back to that diagram?

B

This is just focusing on what is this interaction between a client and what I'm calling an origin here, because I'm thinking of this in the web server context, but this could be any server that the client talks to that it wants to be able to provide anonymous tokens towards and as we were just talking about with ben.

B

I think this is the key part to be nicely standardized nicely extensible, because this is the case where you're talking to someone who you don't have a previous trust relationship with.

B

And as I had in the title here, there are two halves of this that we think of and we're calling it challenge and redemption, and the broad shapes not talking about any particular protocol here is that in a challenge the client is telling some server hey. I want to do or access something, and the origin is like prove that you're able to access this you know give me a token to prove that you're, not a bot or to prove that you have an account or something, and then the redemption phase is.

B

When the client comes back and says hey, I do have a token or proof or whatever it is, and the origin says great go ahead if that works, or it says no. That was not enough.

B

And not the um both of these are not always required, so the redemption half, no matter how you slice things, I think, is a fundamental part of any token scheme we have. We actually need to spend the token, um and so the token redemption is whenever the client presents a token to gain access and within privacy pass.

B

These tokens are anonymous, but they are essentially an anonymous way to say I did something, and I got this token issued to me. You should trust me.

B

And then the challenge half is optional, but often is useful and some of the things that the challenge adds as value is that it allows the server to indicate in the first place that it supports tokens or privacy pass and that it wants them from a client.

B

It's an opportunity for a server or origin to indicate the types of tokens um that it wants like. What you know is this publicly verifiable? Is it using this algorithm or not, and it also can indicate who this origin trusts to issue tokens like? What keys is it going to validate against?

B

And the last thing it does is that it does allow for interactive tokens, and this is something that I don't believe was captured previously in the protocols.

B

But there are cases where you may not want to have a big bag of tokens that were previously cached, but origin may have a higher bar and say I want you to prove right now that you're able to get a new token issued to you.

B

All right, so what what was missing in the landscape we had before, um because you know previously, as people have been testing with privacy pass, these functions have been running, but the previous design really relied on the javascript apis as defined in w3c.

B

It relied on them to actually drive this challenge and redemption functionality.

B

There is an http api document that we have, but it doesn't really give you the full scope here to be able to run this whole protocol.

B

There wasn't any clear way that we could support new token types. So previously it was only defined to do poprf, but we know that the working group does want to be able to support publicly publicly verifiable tokens as well.

B

So what we're proposing here is that you know if you look at this interaction model of oh, I have a challenge when a client tries to access a resource, and then I want to be able to provide a token and authentication. It really really fits cleanly into an http authentication method and defining that within this group, we believe will allow for a really nice standard definition that could have explicit support for different types of tokens. So we can have this be extensible and have it evolve, and this would work cleanly with the javascript apis.

B

There would need to be some updates to actually what those javascript apis do, but they could just drive http authentication very easily, but it also allows us to do this in non-javascript and non-web contexts and in the discussions we've been having with people, um you know beyond just web interactions.

B

There are a lot of interactions of apps or other um non-web scenarios that would really benefit from being able to use privacy pass, and it also has the benefit of having something we could define within the working group that can work standalone and then also be built on by the w3c.

B

So the authors are proposing that um this work that we're defining here can essentially replace the ht http api document that we have and broaden it into this authentication method scheme.

B

um So the different features in this scheme are, it defines an iono registry of token types and these token types define what issuance protocol you want to use, um and this is indicated within the challenge and the redemption phase.

B

um Chris will talk later about the different types, but you know essentially it'd be like oh there's, the pop rf there's a publicly verifiable option, etc.

B

It also can indicate the issuer name and essentially say. Oh, this is who I trust, or I can have multiple names of you- can get tokens from any of these people, and it can also provide hints for the keys to use to make it faster for clients to get tokens without having to fetch some config from the side and then also has allows for some optional features, which we think are very useful.

B

One I already mentioned is an interactive token. Essentially the challenge can come with a one-time nonce, so that um an origin can prove that the client was able to fetch a new token kind of in line, and this can avoid certain farming attacks.

B

And then you can also just include within the elements that are assigned on the token, the actual origin name, and this uh can prevent cross-origin spending or attacks where you're trying to fingerprint what users have been going to or one origin draining tokens that were meant to be better used on another origin.

B

As an optional thing, you can add in all right. So what is this? Oh yeah? um The other thing we want to focus on here is: we believe that it's really important if we want privacy pass to be widely used and adopted throughout the web and other servers that it needs to be really really easy for origins to adopt.

B

When you look at the overall system for privacy pass, you know there is some complexity, but I think we believe that that complexity belongs more on the side of issuance and how do clients prove what they have, but on the side of just presenting a token to a origin, it should be really really simple for that origin to do so that many many websites and origins can just adopt this and replace captchas or replace other things they have.

B

So as part of this, the origins don't need to do any complex crypto. They just need to verify tokens for publicly verifiable types like rsa blind signatures. That's really really simple. To do um privately, verifiable tokens um do require the origin to have an issue or key or make a request to the issuer. um That's what we have with the poprf, but um it's not too much to do in that case, but an origin can always choose to prefer the publicly verifiable type as well and interactive.

B

Tokens can also mitigate some concerns that origins had around farming and double spending and tracking that state, if you're, using interactive tokens, you're shifting the state that's required on the origin from maintaining. Oh here's all of the redeemed tokens that I've had and making sure that no one's double spent to instead just having a nonce, uh that's associated with a single um http session with the client, and you just need to remember how many nonces did I give out what were they and that can be um much much more bounded.

B

uh So the actual protocol details here we're just proposing a private token um http authentication scheme. That includes a challenge and a key that goes along with the challenge.

B

The challenge is a structure that defines what token type it is, so it tells you what issuance protocol to use it has a required issuer name and it has an optional nonce and an optional origin name that can be covered by this.

B

So if the redemption nonce is present, then you need to get a fresh token every time. If it's not present, you can use a cached token, like you traditionally would with privacy pass today.

B

If you have an origin name present, really, that just is something that gets signed, and so, if, um if the origin name is present, you need a token that's specific to this origin, and you can't do cross-origin spending, but you can still cache it. Otherwise, if that's missing it's just a generic token that can be used on any origin that supports cross-origin tokens.

B

And the redemption side is also very simple. You just provide the token, along with the scheme that includes the same token type from one of the challenges. It includes a client generated. Nonce that's essentially makes the token unique.

B

It includes a hash of the original challenge and that's what make sure that it covers the original challenge nonce or the origin name.

B

It contains um the key id of the key that signs the token and then has an authenticator, which would be a blob, that's specific to the particular issuance method that can be the blind, rsa signature. It can be the pop or pop rf output or something else as we come up with better options into the future.

B

um And so you know as long as you're, using a valid issuance protocol, this does meet kind of the architectural requirement that this is unlinkable redemption.

B

You can't link any two tokens back to the same client and so overall, the proposal here would be to essentially adopt this document or replace the content of the existing http api document, with this definition of the http auth scheme and then move any of the http interactions with issuers into an issuance protocol document, because we believe that can be iterated upon or swapped out for different issuance protocols in the future and then the other piece of work we would need to do if we did this is you know, update some of the w3c api interaction.

B

It doesn't necessarily need to change the api surface, just what it drives to have. It drive this http off method. Well, and that's all I have on this: do we have any clarifying questions.

A

Joe, so, basically you you're between the uh kind of this redemption protocol. um You still have a link. There is a linkage between the issuer protocol and that you need to get a particular type of token and exactly what the client does to prove that, in that opaque blob is um depends on on that what happens during issuance, but the rest of the, but that kind of the protocol shape is the same no matter what that's kind of the idea.

B

That that's right um and you know the idea- is you know today we already have you know we've already defined p or prf. We want to bring in something like rsa plan signatures for public verifiability, so we need to wait to tell between those but even going forward. I think there their desires to have lighter weight, publicly verifiable tokens and it'd be nice to be able to use a common, challenging redemption method and just have a bit to indicate oh yeah. I also support this new.

B

Token type that can do a blind signature. That's publicly verifiable we're going to support that as well, and so it allows us to evolve without having to rewrite origins completely. Every time.

B

H

C

All right ben, that's what not his chair uh so in in previous uh in previous iterations. One of the questions that has come up is about the privacy implications of timing based linkability for these kinds of interactive issuance situations. So my first question is: what do you? What do you think of that? What do you think of the the concern that a uh that, if an origin can tell me exactly when to request a new token that the the timing of that uh identifies the user.

B

Yeah um I mean I think that certainly is that that can be a concern we've. The authors have discussed that as well.

B

Generally, you know that that's the type of thing that will be more mitigated for higher volume um sites, essentially cases where, if you have you know millions of people always getting tokens, then you're not going to be able use the timing attack there.

B

I think it kind of folds. You know if I have very very few people getting tokens with the place. um Even if I don't have a timing attack, you're, probably able to guess pretty well who I am.

B

It also plays into a little bit the um the interactions that we have on the issuance protocol and the role of if we do separate out a tester that a client who is coordinating within a tester. Let's say you know my ios device talks to a server that can do device attestation. It could say, hey um you know. No one else is using this issue or it seems like maybe you're being fingerprinted here, as opposed to saying oh yeah.

B

I know that millions of people are actually going and hitting this all the time uh you have a big enough anonymity set, but yeah it's something to definitely continue discussing.

C

Yeah, I think that's that's interesting. I you know, I would point out that if you have an issuer with somewhere in the vicinity of, let's say a hundred thousand active users, uh you know if those users all get a fresh batch of tokens once a day, then uh they have an anonymity set size of a hundred thousand. But if they are in this interactive mode, then they essentially are fully identifiable uh because issuance presumably takes much less than one second.

C

B

C

B

Depends how you do it now.

C

uh So anyway, I would. I would like to see, certainly um some very clear analysis on that, and especially from the client's perspective, um you know. Are all these tokens do all these tokens have the same privacy implications and do we want to you know, do we really.

D

C

And do we really want to provide a so it we've talked before about, for example, public metadata as something that can affect the privacy uh protection value of a token, but that's something that's very clear and measurable to the client. So it can. It can do its own accounting for whether it wants to support that algorithm. For example, yeah.

C

I think that we need a little bit of thought into what the client's local policy is supposed to look like around these around, especially this interactive question, whether it can essentially budget for the amount of privacy loss that implies or whether it actually is kind of unknowable to the client.

B

Yeah I I agree that that's that'd be a good thing to add into here.

C

Thanks, uh I also wanted to um specifically ask about the knots: um is that not somehow, blinded before it reaches the issuer,.

B

The yes chris can talk about that a bit in the issuance protocol. I think okay thanks yeah chris did you have a comment.

E

uh Yeah I just um ben was asking for some analysis, um but then what I, what I think I just heard sort of come out of that conversation was that language around you know what the client doesn't know with respect to like how many other clients are happen to be using this issue or at what time um is something that would be good to add.

E

So uh ben. I'm not sure like what analysis you had in mind um beyond sort of just noting these considerations of the interactive um protocol variants.

F

C

So so I should be clear, you know it's. I I have I'm concerned that these interactive variants don't effectively provide significant privacy that if we consider all of the other metadata visible to the other parties, that clients are actually effectively uniquely identifiable, even at quite large scales.

C

I would so. I would like to see on the analysis side can we, you know, make a convincing argument that the clients are strongly protected and and uh show the sort of scale that's required there and.

B

C

And also, can we talk about um about what we think clients should do to to keep themselves well protected.

B

E

I can okay, um so my my immediate reaction to that is that um this is somewhat like. You know the leaky goat problem um that we we kind of face in ech like we are. We are designing the protocol such that it's like cryptographically unlikable between issuance and redemption, and yes, if there's additional metadata, that's leaked particularly around like the time stamps of these events um that you, you could stitch things together after the fact, um but that seems uh sort of separate or or external to the the protocol.

E

That's sort of being defined here, one of the nice things about the redemption protocol that I don't recall you mentioning tommy, is that the the the clients uh have some leeway in terms of when they respond to a particular challenge.

E

um In fact, the hp header that comes that carries the challenge has like a max age attribute and the client can use that if it wanted to to like delay things to do all sorts of you know, randomizing things I'm using air quotes, but you can't see it to sort of hide the the the time stamp to some extent um or to make it less correlated with what the origin sees.

E

So um I I I don't consider this to be a deal breaker uh any more than I would consider like leakage from ip addresses to be a deal breaker for ech.

C

Thanks uh that sounds like an example of something that should definitely be be documented and again analyzed in terms of like how much delay is. Is the recommended value? How should the client just make that decision right.

E

um I I don't want, I don't know if you can add recommendations here, though, that's kind of my point, like the clients, are in a position where they don't know how many other clients are interacting with a particular issue or- and they don't know like what the value is. I think noting. The considerations here is very much appropriate, but trying to offer recommendations for local client policy um seems like an intractable problem to solve.

B

Yeah, sorry, I know we're over time. I just want to chime in one more answer here so.

B

I I think this is another case where the architecture thinking about a tester and issuer roles separately actually does help. So not only does, is it possible that you know a tester could help clients know about the scale, but I think, more importantly, when you talk about a timing attack, we need to think about. You know what is the information that is vulnerable and could be used to correlate information back to the client right.

B

So you know yeah, if you think about a case where I talk to my origin over tor and I'm having my ip address, but I talked to the issuer and I had to reveal something to it.

B

Like my actual ip address or my account or something that's more identifying, then yeah, that's really bad um to have that linked back.

B

But if we have deployments where the actual issuer that's handing out the tokens is, you know more distanced from the client such that it never sees the client ip the client's going through it another a tester or something else, even if they do have some um ability to you know, guess with a small enough set that oh, yes, this is the same token as that other one.

B

They may not um actually learn much, because the issuer may not know anything about the client um so that that's another way that clients could get some protection here and that's it.

E

E

uh Okay, thanks tommy um and thanks for the questions, uh so I'm gonna now pivot over and talk about the the issuance protocol that works uh in conjunction with the redemption protocol um and it sort of complements it in a way to produce tokens that satisfy a particular challenge from the from the uh origin.

E

um So this again is the the scenario here. You have the origin that interacts with the client to send a challenge and the client then, on the side, runs. This is protocol to produce a matching token.

E

You can sort of view like the interface to the issuance protocol, like so input from the origin. Again is just a public key. That's used to verify the particular token uh so in the case of the people here, if it would be the public key, the case of uh like blind rsa for the publicly verifiable variant, it would be the public key for binder, say and then the challenge which is like this.

E

This token challenge structure that tommy was uh had on the slide earlier um and then the output from this is a just an encoded token that the client then sends back to the origin.

E

So basic issuance is really quite simple: um I'm going to walk through sort of the cryptographic steps that like drive it. uh This is something that was in the existing protocol document um uh or steps of this were sort of in the existing protocol document, but we modified it to accommodate and integrate with the existing redemption protocol or with the proposed redemption protocol rather so anyways.

E

The first thing the client does uh upon receiving this challenge is it generates a fresh nonce of its own separately from whether or not the challenge carried a redemption hunts, um and then it produces a context, uh string or struck context value which is effectively a hash of the challenge and then, from that point on all it does is run basically the pio prf or the blind signature protocol over the pair of nods and context values.

E

So what I've written here is sort of notation, that's specific to my blind signature protocol, specifically using the function blind with the public key of the issuer, um and uh uh but like you can you can imagine it being sort of any any sort of suitable issuance protocol that that matches that shape, um where the the inputs here are nodes in context are private.

E

They remain private from the issuer during the issuance flow and the output um uh that the the client sees is a like a valid signature or an authenticator, as was described earlier over this private input.

E

Okay, so generates a nonce computes the context and then starts the blind signature protocol as per the blind signature protocol after computes. It's blind or request in this particular case sends that over to the issuer, perhaps going through the tester if necessary, for this particular deployment doesn't need to be, though yeah sure, then, is an oracle for computing blind signatures over arbitrary requests.

E

So it gets in a request, computes, a blind signature and then immediately sends the response back to the client and the client simply finalizes the protocol to compute the authenticator, um pretty straightforward, very simple um and, as I was saying earlier, I've written this in terms of the blind signature scheme. But this is uh in the basic issuance proposal that we have up. uh This is also implementable as a blind signature um or as a popuf. Sorry.

E

One of the things that we've introduced with the the new issuance protocol scheme is uh this: the notion of a token protocol or an issuance protocol type um and a corresponding registry to match where the registry sort of defines the parameters of the the issuance protocol or a parameter might be whether or not it's publicly verifiable.

E

um That is, you know. Can you verify without having an authenticator without having to interact with a particular uh issuer? Does it have uh support for public metadata? That is input or data that is revealed necessarily to the issuer and computing its? You know it's it's half of the protocol, um or does it support private metadata?

E

None of the proposed schemes uh in the registry right now do support private metadata, but there are some existing proposals um from folks at google for um building anonymous issuance protocols with private metadata bits, individual bits um uh we could we could. You know, extend this registry to denote like how many bits of metadata is are supported. um uh So you know, bike shedding here is necessary, um but but we feel like these.

E

These are sort of reasonable dimensions and reasonable parameters for issuance protocols and, of course, uh the size of the authenticator, um because that sort of defines the the structure of the token that comes out of the other end.

E

So right now in the basic issuance pr, we have uh two token or two issuance protocols, sort of uh just described uh that are in line with the redemption protocol, first of which is based on the popuf work from the the corresponding cfrd draft instantiated with p384 and shot 384.

E

The this particular curve was uh chosen because we didn't want to deal with the static diffie-hellman problem, uh so we just bumped up the the the curve a little bit too to address that, and then we have blind rsa, which addresses the publicly verifiable component of the charter um and is a drop in replacement effectively for the pop ref, um as described on the previous slide, and we can, you know, certainly consider um adding new issuance protocols to this registry as needed.

E

So we could add the the html protocols to support the private metadata bits, either the ones that are privately verifiable or publicly verifiable.

E

There are proposals for each and I don't know if there are cfrg drafts yet, but that's all that would be needed to sort of plug in here. We could also consider adding blind bls. There is an existing cfrg draft for this, and work is underway to add blind support to that particular environment.

E

An important note point to note here is that these issuance protocols are only two messages. Are one round trip between client and issuer. There are constructions that are more than one round trip that require three or four messages, depending on the shape. um Those would be compatible with the issuance protocol, as or with the architecture, as described like the number of round. Trips is not really a constraint in terms of you know the the architecture, um because it's it's it's you know implementation details uh specific to the issuance protocol, um so I didn't.

E

I didn't list anyone's any of those here, uh because there's there's concerns around. You know how you would deploy that this sort of thing um this this this type of issuance protocol with more than one round trip in a stateless way um or in a way that's safe. uh That has to deal with the state that the the issuer maintains per per client, um but it, but it is certainly possible.

E

So there's a couple considerations um uh that I wanted to note that the first is that the existing sort of, uh like I said, the existing sort of issuance protocols that we specified assume that the issue were stateless. So it's one round trip for issuance protocols, but we could certainly move to um uh protocols that support multiple round trips as necessary.

E

um Nothing. Nothing prohibits that. Another thing to note is that um the the way that the issuer is uh interacted with and in particular the apis that are exposed uh by the issuer in order to interact with it, are compatible with any deployment, specific key consistency mechanism that would be desired for an application.

E

So you can imagine like a service that pulls down issuer keys and throws them in a log somewhere, and then clients check that log. Whatever is appropriate for a particular use case or for an application.

E

The point is that the all the keys that the issuer might use are discoverable and via a well-known api, and then you can build things on top of that that api to build consistency into the system, how that is done is out of scope. There is a there's, an individual draft, that sort of describes different ways to address key consistency in the ecosystem, um but we don't think uh that's like that needs to be included in the these drafts more so that they need to accommodate uh any of these particular mechanisms if needed.

E

For a particular use case, yeah ben go ahead.

C

Clarify question: you said uh that key consistency is out of scope. Are you noting that, as out of scope for a particular draft or for the working group.

E

I think for the for these particular issuance protocols like the issuance protocol, should not address how to deal with issuance or issuance key uh consistency. Rather, it should enable other work to address that if as as needed, so I I don't recall what the charter says in this particular topic. If it says that we need to address uh key consistency, that's cool we could. We could certainly write a separate draft that deals with it, um based on the issuance that's described here, yep.

E

Okay, um uh so uh in the architecture document we describe various uh ideal security properties that we'd like for the insurance protocol. The most obvious one is this notion of unforgeability.

E

Where clients, you know, can't just forge tokens without having interacted with the issuer, um and so all the issuance protocols, as specified in the registry right now support this particular property, and indeed this is a requirement to go in that registry.

E

um They also require that the uh this notion of what we call issue and secrets see issuance secrecy, and the description here is not the most clear but issue and secrecy basically means that any of the input that is uh provided to the to the blind signature protocol or the the issuance protocol generally is not revealed in any way to the issuer.

E

So if you recall from the diagram really, we had this nonce and we had this context. Both of them are unconditionally secret, even against an all-powerful attacker um uh who has like endless compute and endless memory whatever, um and this is necessary for the privacy and particularly the unlinkability guarantees that uh we have between issuance redemption.

E

Okay, so the proposal that we have at hand is to basically take what was currently described in the protocol document, which had bits and pieces of this. So it did have you know the deep some language around how to integrate with the pop rf. um It did have some. You know details about how to do redemption, but nothing that was, you know, implementable and interoperable.

E

um The proposals take is to take the the basic issuance protocol details and built upon the proposed redemption protocol and make that uh sort of the the working group document protocol document um uh and there's a number of reasons to do so. uh A uh it satisfies a perhaps should sort of these differently, but a it satisfies uh that the two uh are two requirements in the charter that we have public and private verifiability.

E

um It does integrate cleanly with the the redemption protocol that tommy presented um and it sort of uh addresses this this question of extensibility that has been floating around, for you know at least a year now I think um we were sort of tossing around different ways to address extensibility. Is it in like the the wire format, messages that are sent between client and issuer? Is it like?

E

How do you, how do you change the crypto and blah blah blah, but the the current proposal, where you wrap up all of the sort of issue and specific details under a token type and then introduce new types as necessary to uh extend the system with new or extend issuance protocol with new features, uh like rate limiting, as kind of we'll describe later, if there's time um it's a very clean way to sort of address this, with minimal complexity on the on the origin and on the issuer side.

E

Specifically, if you don't want to support any of these extensions, you just don't implement that. For that token type protocol, very simple.

E

Okay, um before we go to the questions the working group slide, I wanted to pause here and see if there's any questions.

E

Okay, if not uh I'll, move forward, then um so we uh just to kind of wrap up. um There's a there's, a couple uh high-level questions we have for the group, um first of which you know are the we want to know. If the the document proposals have presented specifically for the architecture document, the uh challenge and redemption protocol document and then the the basic issuance protocol document. Are they clear um it's the sort of scope and um does the scope make sense?

E

um uh Are the uh are the abstractions right or considerations right and so on?

E

um And then second, we want to know, or we want to try to assess if there's consensus, to move in this direction, which specifically means updating the privacy pass architecture document based on the proposal at the beginning, as well as the protocol document based on the the basic issuance protocol that I just walked through, as well as considering adoption of the new um authentication scheme that that describes the challenge redemption protocol that tommy went through, and uh so I'm gonna stop sharing and I'm gonna turn it over actually I'll keep sharing, but I'll turn it over to the chairs.

E

So I think this is where discussion happens.

C

Hi ben schwartz as chair, I would really appreciate hearing comments on these questions from the authors of the current adopted drafts. So, if you're an author or if you're a co-author on a current adopted draft, I would really appreciate it if you would come to the mic and give us your thoughts thanks.

H

um Hopefully you can hear me yeah. I.

G

H

uh Restructure of the graph seems reasonable. I think, there's a few issues to work out like what information we put in the architecture. Dock, like the uh interactive timing, um I think moving to the http instead of the current atp api method, I think works well. I think there's going to be some questions about like cases where you need to trigger issuance redemption in ways that you don't necessarily have that like first leg, but I think that's all things we can edit within that specification overall seems reasonable.

C

F

Hey um yeah alex davidson brave, um so personally, as an author of the both the architecture and political drafts, I think these proposals are clear and and also moving forward in this direction makes sense.

F

um I think the one the one concern I have is around uh as people have brought up previously these interactive challenges and and how we parameterize the privacy in the client privacy in those cases, because I think it could radically alter the anonymity set sites for those clients and that's something we we tried to parametrize before um and if, if it's decided that we don't want to do that, then um then then that might be maybe reasonable, but I think the current parameterizations we have then are kind of redundant. In that case,.

C

Thanks alex chris.

E

uh I just wanted to say that I I support the new direction if that wasn't already obvious.

C

Thank you sophia,.

D

uh Sofia from cloudflare um yeah, I just wanted to say as well that I support the new directions and it seemed to be some really small open questions, but I think we can discuss that further and yeah. Thank you for uh pushing forward all of this new direction.

C

Thank you, uh it seems like we've ha all the comments we've heard have generally been positive and supportive of both updating these drafts and of adopting the new authorization draft.

C

Does anybody want to provide an opinion going? The other way.

C

uh Okay, it seems like there isn't anybody speaking against these these things um I uh I haven't had a chance to confer with my co-chair, I I would like to propose the following. It seems to me that the updates to the existing drafts can uh can move forward without any further review by the working group. Of course, the contents of those drafts will will be subject to many rounds of further review before it can exit the working group and the new draft.

C

uh I think uh it's. It seems to me that that the that the group needs some time to um to do a formal review for this before we do a call for adoption. So I uh I don't think I don't think we're ready to um to trigger a call for adoption in this meeting, but uh I think we can do that very quickly. If, uh if the draft is sent out to the list and people have a chance to to read it, then I think a call for adoption would be appropriate uh joe.

C

What do you think.

A

I think yeah, I agree um the uh I think it's a fair thing to move forward with uh with the changes and hold up on the adoption of the draft until we get kind of those things a little bit more settled and and socialized in the group. But I think um we're pretty uh pretty good here.

C

B

All right, uh yeah, thank you, uh so I think the order would be um because we haven't formally published the auth scheme as an id, partly because it was referring to uh github prs that weren't merged. So I imagine if we can merge those other pr's, then I can once that's done kind of get something with the right references published, send that to the list and then we can discuss, and I think it sounds like the main open question that people have around that is interactive and how is that safe? And when is that safe?

B

um I totally think that's what we should focus on going forward for the discussion. um I want to hear to what degree people think you know fully delving into that is required before adoption, or do we just kind of have a placeholder there of this.

D

B

Where you do it and we need to agree as a working group when it's safe.

C

Thanks tommy davidskenazi.

I

Davis ganazzi, google- um I was just had a process question for the chairs, because uh I've personally read the proposal and I think it's definitely worth doing as a working group. uh If you're saying that we're not ready for adoption, what are we looking for? Obviously, we wouldn't decide in the room, but I'm not seeing any blockers to like start the call that will trigger people to actually read it.

C

So, as tommy pointed out, the draft formally doesn't exist yet so there we can't actually start a call for adoption until the draft exists, but I think I I think joe has more thoughts on this so I'll hand it over to him.

A

Yeah- and I I think also there's a little bit of an ordering dependency that we need to get the architecture draft updated before you can even update the off scheme and before you know, so that the references work out and all that. So I think that's kind of the the way the flow needs to be. But I I could be wrong.

I

I I would love, there's a comment, but I it seems like we can move forward on architecture without having all the drafts there, but um I see chris in the queue I'll leave my time. Thanks for clarifying.

E

Yeah, I just want to ask a clarifying question, so we can certainly merge the architecture. That's fine, um but uh ben also said that we could also move forward on the protocol document update. um However, importantly, that depends on the redemption protocol document existing um uh so um in in merging that change into the protocol document. Sort of assumes that this this authentic, this new redemption protocol uh will be a thing.

E

So um should we hold off on merging the protocol document change until there was there's been a consensus, call on the authentication document, or I just I'm not sure what to do.

A

Does does the protocol document rely on the detai on the specific details of the redemption document, or is it um or is it just you you we need to have? We need to say that there's this thing that's going to exist and where uh that that it's you know, I mean we're going to be in a chicken and egg problem and I think I'd.

E

Like to update.

A

The existing documents and like okay, there's going to be some.

G

A

Know dependency that you know, one of them is going to depend on a draft, that's yet to be adopted, but it seems like you could still evaluate some of the privacy protocol and you can definitely evaluate the architectural changes somewhat independently of what exactly the odd scheme is.

E

um I I think we can, uh with a slight change of hand, just sort of uh remove the dependency on uh in the pro the protocol document on the the redemption protocol and just say, like we get this challenge uh from from space or you know from carrier pigeon whatever.

E

um That would be fine, um so that would work.

C

B

Yeah, I I agree with chris that we could yeah. I think, it'd be good to merge the protocol bits and just say, maybe even just reference like, for example, it could be something like the mechanism described here, but not normatively depend on it. Yet just say you know there is an issuance token type. There is some challenge blob and you need to send this back somewhere, but then we could always update it later to make it concrete.

C

G

I was just gonna propose that we treat at least the redemption protocol on the architecture documents as one bundle.

G

So uh if you have any concerns about um dependency and so on, because this is an adoption call right and ultimately, unless there's a good reason to separate them out unless somebody's arguing that they ought to be separated out, could we just treat it as a bundle and see where that goes? First.

C

uh So, to be clear, are you proposing that none of these changes land until until we've had a chance to do a formal, complete, a formal adoption call for the authorization scheme? I guess.

G

I'm suggesting that we see if there is pushback on that right like if we try to do the architecture and the um we can always split it off and say: okay. Well, we can do this piece separately. If there is push back on it, but it does not. Then we avoid the whole conversation around um dependencies and issues like that.

B

John I'd rather not try to go down the road, because I mean the reason we haven't.

G

B

The scheme yet is we have nothing to reference. Yet that's in data tracker, so we'd have to come up with entirely new data tracker documents for everything.

C

C

A

This kind of protocol with the the attestation protocol, which is um uh you know it's not specifically, you know a topic of this. uh You know we're not going to define the attestation protocol here, but it seems like there are certain properties that it has to have be able to carry certain sorts of information, and so that's something that how well have we defined that yet in the architecture document.

A

Chris or jenna is that.

E

uh Sorry, can you repeat that question.

A

We have a set of requirements for the attestation protocol.

E

No that's uh and uh we're trying to keep that as much as possible out of scope. um It's a as tommy was sort of describing or john I was describing earlier. um That's a that's a deployment, specific uh question uh between client and trusted testers um that that will vary depending on the use case.

B

I mean, but it does have the section to describe you know what in in broad strokes it does. So. I think, right joe. Your point is good that it need to be clear of.

B

What the kind of minimum bar for what it does is. um They can also vary depending on the specific type of issuance or deployment you're doing.

B

Sometimes it's going to be higher bar, and sometimes it's not going to be right.

A

C

So, uh in terms of of direction moving forward, I want to just double check with uh with janna: um do you uh do you still think a sort of two-phase uh movement here is appropriate uh or uh or do you feel like we're, we're probably better off trying to uh wait until until we've done a call for adoption before making any of these changes.

G

I think chris might have a plan, I'm gonna. Let him respond.

E

Okay, uh sorry, this is, this is getting more complicated. There probably needs to be so um uh here's my proposal. uh We can. uh We will, uh with the proposals of the redemption, uh the auth scheme document, we'll add some text and considerations around the sort of timing, attacks uh or correlation that was brought up earlier. We will publish that in the data tracker.

E

It will merge the eprs outstanding against the architecture protocol documents which do cite this draft and publish new versions of both of those, and then I think we can ask for an adoption call of the http authentication.

C

Draft okay: does anyone want to express concerns with that plan.

C

Okay, hearing none. I think we have a path forward.

C

We have a few minutes remaining. Are there any other slides that the presenters wanted to cover.

E

um There are more slides um there is not enough time to go through them, uh so I think we should just uh postpone that content for another time.

C

C

Joe any closing thoughts.

A

Not specifically, I think I like this way forward and we can schedule potentially another time, although I think we're getting close to the um I know, ietf time, I guess it's still a ways away. We can schedule another interim to go over additional material if that makes sense.

C

B

Hey um uh regarding another meeting, we could probably just wait until 113, um particularly if we do the adoption call in between uh the reason I got in queue is one. Other thing I wanted to mention for people is that the various authors and people working on the new proposal have also been doing implementations and interop testing. um So chris has a implementation. I think that's open source as well on github that people could try out and test against that uses the http auth method and the issuance protocol.

B

So you can see how that looks as code. I've done an implementation for ios and mac os as well that I've tested- and I believe, some of the others are working on that. So, if you're interested on trying this stuff out, we can also chat on the list or in github or whatever um so just wanted to say. You know we're committed to actually having running code here.

C

C

Okay, thanks for coming everybody. That concludes our meeting of the privacy pass working group. We'll see you all at the next one and thank you again to matthew finkel for being our notetaker.

A

A