Skip to content

Commit

Permalink
Script updating archive at 2023-09-21T00:18:42Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Sep 21, 2023
1 parent 38a328d commit 43da4c2
Showing 1 changed file with 144 additions and 7 deletions.
151 changes: 144 additions & 7 deletions archive.json
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2023-09-19T00:19:08.464141+00:00",
"timestamp": "2023-09-21T00:18:40.091169+00:00",
"repo": "chris-wood/draft-group-privacypass-k-check",
"labels": [
{
Expand Down Expand Up @@ -317,18 +317,47 @@
{
"number": 14,
"id": "I_kwDOJv72Bc5xTu1a",
"title": "Increasing K reduces privacy under timing correlation",
"title": "Increasing K creates a privacy risk when timing correlations are present",
"url": "https://github.com/chris-wood/draft-group-privacypass-k-check/issues/14",
"state": "OPEN",
"author": "bemasc",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "K-Check is designed to improve in privacy as K (or the threshold `t`) increases. However, if a timing correlation is present (e.g., the client fetches an OHTTP config immediately before using it), increasing K actually reduces privacy, because any single colluding mirror can reveal the client IP to the gateway. Adding more mirrors increases the likelihood that one of them is malicious.\r\n\r\nIf timing attacks are present in the use case, I think the optimal value of K is likely to be 1.\r\n\r\nIn some use cases, timing correlations are present for some requests (e.g., the first request issued when the configuration is not locally in cache) but not others. In these cases, it might make sense to perform a single check (K=1) initially, and then perform more checks asynchronously (according to some randomized schedule) to catch if the initial mirror was colluding and served a targeted resource.\r\n\r\nThese issues can be avoided by tunneling K-Check through a trusted proxy, but if a trusted proxy exists then it can run the Mirror Protocol itself and K > 1 is unnecessary (see #16).",
"body": "K-Check is designed to improve in ~privacy~ resistance to active attack as K (or the threshold `t`) increases. However, if a timing correlation is present (e.g., the client fetches an OHTTP config immediately before using it), increasing K ~actually reduces privacy~ increases vulnerability to a passive attack on the user's privacy, because any single colluding mirror can reveal the client IP to the gateway. Adding more mirrors increases the likelihood that one of them is malicious.\r\n\r\nIf timing attacks are present in the use case, I think the optimal value of K is likely to be 1.\r\n\r\nIn some use cases, timing correlations are present for some requests (e.g., the first request issued when the configuration is not locally in cache) but not others. In these cases, it might make sense to perform a single check (K=1) initially, and then perform more checks asynchronously (according to some randomized schedule) to catch if the initial mirror was colluding and served a targeted resource.\r\n\r\nThese issues can be avoided by tunneling K-Check through a trusted proxy, but if a trusted proxy exists then it can run the Mirror Protocol itself and K > 1 is unnecessary (see #16).",
"createdAt": "2023-09-18T13:53:09Z",
"updatedAt": "2023-09-18T14:36:03Z",
"updatedAt": "2023-09-20T19:50:33Z",
"closedAt": null,
"comments": []
"comments": [
{
"author": "chris-wood",
"authorAssociation": "OWNER",
"body": "> K-Check is designed to improve in privacy as K (or the threshold t) increases\r\n\r\nI don't think this is a goal of K-Check. Increasing K is meant to increase confidence in consistency of the answer -- it has nothing to do with privacy. Does the draft say otherwise? If so, we should probably fix that.",
"createdAt": "2023-09-19T21:45:15Z",
"updatedAt": "2023-09-19T21:45:15Z"
},
{
"author": "bemasc",
"authorAssociation": "NONE",
"body": "I've adjusted the issue description to be more precise, and avoid assuming that privacy is the only reason to pursue consistency.",
"createdAt": "2023-09-20T18:45:38Z",
"updatedAt": "2023-09-20T18:45:38Z"
},
{
"author": "chris-wood",
"authorAssociation": "OWNER",
"body": "I'm not sure I understand this newly phrased issue. The \"attack\" is still described as one on privacy (\"increasing K actually reduces privacy increases vulnerability to a passive attack on the user's privacy\"). I appreciate thinking about the draft, but it would be more helpful if this was something concrete.",
"createdAt": "2023-09-20T18:52:21Z",
"updatedAt": "2023-09-20T18:52:21Z"
},
{
"author": "bemasc",
"authorAssociation": "NONE",
"body": "OK, I'll try to make it concrete. A hypothetical example:\r\n\r\nI am the moderator of a subreddit. I'm trying to maintain my privacy, so my login handle is not identifying. Once every day or two, I publish a comment in the subreddit using OHTTP through a trustworthy Relay.\r\n\r\nA hostile actor would like to know my IP address. Reddit doesn't know, and the Relay won't share. However, Reddit's gateway config expires after 60 minutes, so almost every time I post an update, my client app needs to refresh its consistency check first. That requires pinging K different mirrors, asking for Reddit's gateway config. Let's say K=10.\r\n\r\nIt turns out that one of those 10 mirrors is compromised by the hostile actor. By correlating requests for the gateway config with my post timestamps, it can identify the IP address that always asked for this resource immediately before my posts appeared. That's my IP address.\r\n\r\nThe risk of one mirror being compromised increases in proportion to K. Similar proportional risks apply to correlation attacks using passive network monitoring, which become more likely as your requests traverse more paths.",
"createdAt": "2023-09-20T19:50:33Z",
"updatedAt": "2023-09-20T19:50:33Z"
}
]
},
{
"number": 15,
Expand Down Expand Up @@ -366,9 +395,24 @@
"labels": [],
"body": "The K-Check protocol is described as an abstract, general-purpose consistency protocol, and in that context it makes sense for K to be a free parameter. However, in specific use cases there may be particular values of K that make sense. If the client's privacy protection is already subject to a Single Point of Failure, then the optimal value for K is 1, i.e. a mirror operated by the SPOF.\r\n\r\nFor example, in OHTTP, increasing K does not provide increased privacy protection, because a malicious Relay can break the privacy guarantee even if consistency is preserved. Increasing K can even reduce privacy protection (see #14, #15).\r\n\r\nAccordingly, the draft should note some cases where K=1 is recommended.",
"createdAt": "2023-09-18T14:33:44Z",
"updatedAt": "2023-09-18T14:33:44Z",
"updatedAt": "2023-09-20T19:07:21Z",
"closedAt": null,
"comments": []
"comments": [
{
"author": "chris-wood",
"authorAssociation": "OWNER",
"body": "I understand the motivation for this, but I'm not confident we can make generally applicable recommendations. At best, it seems like we might be able to provide examples where certain values of K = 1. OHTTP is an obvious case for that. Would that work?\r\n\r\nSeparately, to make sure we're on the same page, does this issue assume that K is chosen for privacy reasons?",
"createdAt": "2023-09-19T21:50:34Z",
"updatedAt": "2023-09-19T21:50:34Z"
},
{
"author": "bemasc",
"authorAssociation": "NONE",
"body": "I do think there is a generally applicable recommendation here. I've written it up in #17.",
"createdAt": "2023-09-20T19:07:20Z",
"updatedAt": "2023-09-20T19:07:20Z"
}
]
}
],
"pulls": [
Expand Down Expand Up @@ -889,6 +933,99 @@
"mergeCommit": null,
"comments": [],
"reviews": []
},
{
"number": 17,
"id": "PR_kwDOJv72Bc5a0JNd",
"title": "Add a section discussing K=1 cases",
"url": "https://github.com/chris-wood/draft-group-privacypass-k-check/pull/17",
"state": "OPEN",
"author": "bemasc",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "Closes #16",
"createdAt": "2023-09-20T19:05:25Z",
"updatedAt": "2023-09-20T19:27:55Z",
"baseRepository": "chris-wood/draft-group-privacypass-k-check",
"baseRefName": "main",
"baseRefOid": "57dd72defef1180f256bde8a29171b365366dce3",
"headRepository": "bemasc/draft-group-privacypass-k-check",
"headRefName": "patch-1",
"headRefOid": "f9af101eca38940783b329db3b5411edc52e8332",
"closedAt": null,
"mergedAt": null,
"mergedBy": null,
"mergeCommit": null,
"comments": [],
"reviews": [
{
"id": "PRR_kwDOJv72Bc5hiG7h",
"commit": {
"abbreviatedOid": "8c94e29"
},
"author": "chris-wood",
"authorAssociation": "OWNER",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-09-20T19:11:18Z",
"updatedAt": "2023-09-20T19:11:18Z",
"comments": [
{
"originalPosition": 20,
"body": "Again, how does increasing K impair _security_?",
"createdAt": "2023-09-20T19:11:18Z",
"updatedAt": "2023-09-20T19:11:18Z"
}
]
},
{
"id": "PRR_kwDOJv72Bc5hiG-g",
"commit": {
"abbreviatedOid": "8c94e29"
},
"author": "chris-wood",
"authorAssociation": "OWNER",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-09-20T19:11:25Z",
"updatedAt": "2023-09-20T19:11:25Z",
"comments": [
{
"originalPosition": 15,
"body": "```suggestion\r\nPrivacy Pass it is typically the Attester.\r\n```",
"createdAt": "2023-09-20T19:11:25Z",
"updatedAt": "2023-09-20T19:11:25Z"
}
]
},
{
"id": "PRR_kwDOJv72Bc5hiJmt",
"commit": {
"abbreviatedOid": "f9af101"
},
"author": "bemasc",
"authorAssociation": "NONE",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-09-20T19:19:06Z",
"updatedAt": "2023-09-20T19:27:55Z",
"comments": [
{
"originalPosition": 15,
"body": "OK, I've changed this to \"... is often the Attester\". (\"Typically\" seems too strong, given the joint Issuer-Attester and other models.)",
"createdAt": "2023-09-20T19:19:06Z",
"updatedAt": "2023-09-20T19:27:55Z"
},
{
"originalPosition": 20,
"body": "In this text, I only mean that K=1 doesn't make security worse. That said, I think increasing K does impair security in this situation, where we have an integrated mirror whose good behavior is already a requirement:\r\n\r\n* In a threshold model,`t > 1` makes the client more vulnerable to denial of service attacks.\r\n* The other mirrors are untrusted, so any risk of collusion attacks (i.e., attacks on consistency) is additional risk here (unless the integrated mirror is on the list and `t == K`, in which case outages/DoS are more likely).",
"createdAt": "2023-09-20T19:26:21Z",
"updatedAt": "2023-09-20T19:27:55Z"
}
]
}
]
}
]
}

0 comments on commit 43da4c2

Please sign in to comment.