Script updating archive at 2023-11-19T01:16:58Z. [ci skip]

cfrg · Nov 19, 2023 · f0ea357 · f0ea357
1 parent 6afdb8a
commit f0ea357
Showing 1 changed file with 36 additions and 3 deletions.
diff --git a/archive.json b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2023-11-16T01:12:07.918453+00:00",
+  "timestamp": "2023-11-19T01:16:26.309953+00:00",
   "repo": "cfrg/draft-irtf-cfrg-opaque",
   "labels": [
     {
@@ -9047,7 +9047,7 @@
       "labels": [],
       "body": "the section `Password Salt and Storage Implications` says the following:\r\n\r\n> Some applications may require learning the client's password for enforcing password rules. Doing so invalidates this important security property of OPAQUE and is NOT RECOMMENDED.\r\n\r\ni agree that this is not a good thing, and also should not be recommended, but maybe caveat this, with \"depending on threat model, for example internal corporate deployments are possible exceptions were enforcement of strong password policies is mandated by regulation\"\r\n\r\n> Applications should move such checks to the client.\r\n\r\n\"malicious\" clients can easily ignore password rules, and the server will never know about this. This can be a problem when corporate rules mandate strong passwords, but users want to circumvent this for whatever reason (mostly lazyness?) - this is well known rule in application security that the server should never trust any input validation by the client.\r\n\r\n> Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change.\r\n\r\ni wonder how this would work, can someone enlighten me?",
       "createdAt": "2023-10-22T00:57:17Z",
-      "updatedAt": "2023-11-06T19:16:23Z",
+      "updatedAt": "2023-11-18T19:56:12Z",
       "closedAt": null,
       "comments": [
         {
@@ -9077,6 +9077,13 @@
           "body": "Regarding the enforcement of strong password policies because it is mandated by regulation: I agree that this is to some extent in conflict with OPAQUE, because it fundamentally does not allow the server to perform these password checks server-side. In fact, I feel like if it is absolutely required for these server-side checks to be done on the password, then OPAQUE should not be used. Therefore, I feel like the wording should stay as-is, without the caveat.\r\n\r\n(However, in practice, I feel like doing client-side checks should still suffice. Perhaps this is dependent on the regulation, but I feel like if a client is specifically trying to get around client-side checks to make a weaker password, then this is the client's fault, not the server's. But that's just my opinion of course :) )\r\n\r\nSome other comments:\r\n1. Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change. This would work by essentially simulating the login mechanism using the old record with the server and checking if it succeeds. Note that it requires the client to be honest and report the success, which in my opinion is sufficient, but perhaps if there are regulations which mandate this to be foolproof, would not suffice.\r\n2. I am not sure I am understanding, but the MAC will indeed change if the password is re-used upon re-registration. This is because, at the very least envelope_nonce gets sampled randomly. To be clear, upon re-registration, we should be completely clearing the old record, and re-running all of the procedures for envelope creation from scratch. Ok, fair enough, if the client chooses to remember these nonces and re-use them during re-registration, then they would be leaking information to the server about this. But again this is an instance of a client shooting themselves in the foot.",
           "createdAt": "2023-11-06T19:16:22Z",
           "updatedAt": "2023-11-06T19:16:22Z"
+        },
+        {
+          "author": "stef",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "> Regarding the enforcement of strong password policies because it is mandated by regulation: I agree that this is to some extent in conflict with OPAQUE, \r\n> because it fundamentally does not allow the server to perform these password checks server-side.\r\n\r\nuhm, but the original paper provides exactly such a registration function and mentions it even that the password strength can be checked using this approach. to say \"fundamentally does not allow\" is in direct contradiction with the original paper.\r\n\r\n> In fact, I feel like if it is absolutely required for these server-side checks to be done on the password, then OPAQUE should not be used. Therefore, I feel like the wording should stay as-is, without the caveat.\r\n\r\ni think even if the one-shot registration of the paper is implemented, and the password is exposed once to the server, the other benefits and security guarantees of opaque make it still the best solution otherwise.\r\n\r\nso i would like to insist to have this wording changed and acknowledged that there are other use-cases.\r\n\r\n",
+          "createdAt": "2023-11-18T19:56:11Z",
+          "updatedAt": "2023-11-18T19:56:11Z"
         }
       ]
     }
@@ -33759,7 +33766,7 @@
       "labels": [],
       "body": "Adding the following sentence under application considerations:\r\n\r\n- Additional information: After completing the online AKE stage, the server\r\n  may choose to send additional information, encrypted under `session_key`,\r\n  to the client.",
       "createdAt": "2023-10-11T21:03:53Z",
-      "updatedAt": "2023-10-11T21:03:53Z",
+      "updatedAt": "2023-11-16T19:27:09Z",
       "baseRepository": "cfrg/draft-irtf-cfrg-opaque",
       "baseRefName": "master",
       "baseRefOid": "6f98fac04f72d9d8449ca763a42e4f486cf7ff11",
@@ -33772,6 +33779,32 @@
       "mergeCommit": null,
       "comments": [],
       "reviews": []
+    },
+    {
+      "number": 435,
+      "id": "PR_kwDOD79ejs5frCW1",
+      "title": "Incorporating server identity into OPRF computation as a recommendation",
+      "url": "https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/435",
+      "state": "OPEN",
+      "author": "kevinlewi",
+      "authorAssociation": "COLLABORATOR",
+      "assignees": [],
+      "labels": [],
+      "body": "",
+      "createdAt": "2023-11-16T19:50:22Z",
+      "updatedAt": "2023-11-16T19:50:22Z",
+      "baseRepository": "cfrg/draft-irtf-cfrg-opaque",
+      "baseRefName": "master",
+      "baseRefOid": "6f98fac04f72d9d8449ca763a42e4f486cf7ff11",
+      "headRepository": "kevinlewi/draft-irtf-cfrg-opaque",
+      "headRefName": "incorporate_server_identity",
+      "headRefOid": "570bd86ed4d8866c556d4a826f054af43e216939",
+      "closedAt": null,
+      "mergedAt": null,
+      "mergedBy": null,
+      "mergeCommit": null,
+      "comments": [],
+      "reviews": []
     }
   ]
 }