Skip to content

Commit

Permalink
Script updating archive at 2023-08-31T01:14:09Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Aug 31, 2023
1 parent dd4a7bc commit 9adedd0
Showing 1 changed file with 82 additions and 4 deletions.
86 changes: 82 additions & 4 deletions archive.json
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2023-08-29T01:13:38.086606+00:00",
"timestamp": "2023-08-31T01:14:07.740448+00:00",
"repo": "core-wg/corrclar",
"labels": [
{
Expand Down Expand Up @@ -1172,7 +1172,7 @@
"labels": [],
"body": "Currently, when a request with a payload that is not block1wise'd has a response that is block2wise'd, the request payload is not repeated. This is efficient in terms of traffic, but means that the common stateless optimization for GET (where the response is calculated internally on each request, but only the slice requested in block2 is sent) is impossible for FETCH.\r\n\r\nIf we do any alterations around block-wise, I suggest we reconsider that choice.\r\n\r\n(Also, this is what is making it necessary to fix 9175 for small-request-payload-and-then-block2 cases, but I for one am OK with using Request-Tag there, as in OSCORE the empty request tag can be recycled indefinitely; DTLS users may not be so lucky).",
"createdAt": "2023-07-05T19:47:33Z",
"updatedAt": "2023-07-22T19:28:01Z",
"updatedAt": "2023-08-30T18:39:28Z",
"closedAt": null,
"comments": [
{
Expand All @@ -1188,6 +1188,76 @@
"body": "To add to this, I have just stumbled over [RFC8132 2.3.2 The ETag option](https://datatracker.ietf.org/doc/html/rfc8132#section-2.3.2)\r\n````\r\n The FETCH payload is input to\r\n that selection process and therefore needs to be part of the cache\r\n key.\r\n````\r\nwhich means to me that the payload has to be a part of a FETCH (even if split over many blocks), even when asking for the next Block2 response, so I now have a conflict over my conclusions at today's meeting.",
"createdAt": "2023-07-05T20:19:11Z",
"updatedAt": "2023-07-05T20:19:11Z"
},
{
"author": "boaks",
"authorAssociation": "NONE",
"body": "The issues seems to have reached [Eclipse/Californium](https://github.com/eclipse-californium/californium/issues/2168).\r\n\r\nIs there already an conclusion, if `FETCH` SHOULD/MUST send the payload in every request? Especially #28 would raise questions about that,\r\n\r\nMaybe adding a special Response Code in an (updated) RFC similar to [2.31 Continue](https://www.rfc-editor.org/rfc/rfc7959.html#section-2.9.1) helps to indicate, what a client is expected to send.\r\n\r\n\r\n",
"createdAt": "2023-08-29T06:04:56Z",
"updatedAt": "2023-08-29T06:04:56Z"
},
{
"author": "sbernard31",
"authorAssociation": "NONE",
"body": "Just to be sure, payload would be needed in all block2 requests only to support stateless implementation, right ? (or there is something more ?)\r\n\r\nStateless implementation is not possible if FETCH is using block1 and block2 ? because you need to store the FETCH payload somewhere (which is a state), right ? \r\n\r\nIf that true, I ask myself if this is a good idea to repeat the payload for each block just for this use case. :thinking: ",
"createdAt": "2023-08-29T09:02:56Z",
"updatedAt": "2023-08-29T09:02:56Z"
},
{
"author": "chrysn",
"authorAssociation": "MEMBER",
"body": "I don't see a conclusion yet, but maybe we can come to one. Eventually, the WG will need to decide whether we can just change the behavior (by a new document or by just stating that we're now interpreting things this way) or whether Block2 means no-payload-in-later-requests and a new option has to be introduced if we want to change anything. The WG will likely come to implementers about how their impls behave, and here we are.\r\n\r\nIf we can agree that (even if nothing else) our implementations do *tolerate* the repeated payload in the request, that'd be a good step toward eventually placing a SHOULD or MUST on the request payloads.\r\n\r\nI don't think a new response code would be called for (as to some extent they are the last resort), but a response option would be a way out if we need it.\r\n\r\nOne design of that option that I could get behind is following a proposal of @mrdeep1 around the Request-Tag topic that triggered this discussion in the first place; this is assuming that we *can* just start sending request payloads on Block2 requests. If we introduced a response option a la \"Your-Request-Tag\" (whether or not that would be in the same space as Request-Tag is a detail for later), then the server could indicate (in its first response that had Block2:0/1/x) that it *does* keep state. Not only would the client then be free to not send the request body in later request, but it may even elide other options (say, Uri-Path) depending on the semantics of that \"Your-Request-Tag\" option.\r\n\r\n> payload would be needed in all block2 requests only to support stateless implementation, right ?\r\n\r\nMainly, yes. Having the payload also helps with a possible attack scenario, but that's more about how to cleanly specify how that's handled; the main purpose of repeating the request payload in Block2 requests is to allow stateless FETCH.\r\n\r\nAs you say, yes, state is required once there is Block1. But for Block2 it really depends on the implementation, and for most FETCH cases (where the response is generated by some kind of stable algorithm), statelessness would be possible quite easily, provided we do repeat the payload.",
"createdAt": "2023-08-29T09:29:13Z",
"updatedAt": "2023-08-29T09:29:13Z"
},
{
"author": "boaks",
"authorAssociation": "NONE",
"body": "@chrysn \r\n\r\nThanks for your answer and update.\r\n\r\n> I don't think a new response code would be called for (as to some extent they are the last resort), but a response option would be a way out if we need it.\r\n\r\nI choose the response code, because it is already used in blockwise for a similar function in block1. My assumption is, that this would make it easier to implement it, because the means should be already in place.\r\n\r\nIf backwards compatibility must be considered, I agree, that a new response code can't help and we the need an Option. \r\n\r\n> If we can agree that (even if nothing else) our implementations do tolerate the repeated payload in the request, that'd be a good step toward eventually placing a SHOULD or MUST on the request payloads.\r\n\r\nWe would also need to decide, what should happen, if the payload is changing. I guess, this will be a new transfer.\r\n\r\nThat's also one pitfall for an implementation without payload in follow up requests, because that doesn't allow the resume such an transfer in the middle when the server may have timedout the transfer and removed the state. \r\n\r\n",
"createdAt": "2023-08-29T09:46:30Z",
"updatedAt": "2023-08-29T09:47:09Z"
},
{
"author": "sbernard31",
"authorAssociation": "NONE",
"body": "> that'd be a good step toward eventually placing a SHOULD or MUST on the request payloads.\r\n\r\nIf this is a MUST, it will not work with block1.\r\nThat's sounds a bit strange to specify that block2 MUST repeat payload (except if block 1 is also used)\r\n\r\nIf this is a SHOULD then clients which want to increase interoperability will need to send payload by default.\r\nWe get same issue as above :point_up: and this also increase traffic just to support specific stateless implementation.\r\n\r\nNote that maybe I'm biased because it's hard to me to imagine how purely stateless implementation could work. (I mean what happens if state change between 2 blocks request), so I maybe overlook the stateless implementation use case. \r\n\r\n",
"createdAt": "2023-08-29T10:32:13Z",
"updatedAt": "2023-08-29T10:32:13Z"
},
{
"author": "boaks",
"authorAssociation": "NONE",
"body": "> what happens if state change between 2 blocks request\r\n\r\nThat's also a question for GET and using a ETAG is the answer. If the state changes, a well constructed ETAG is changing. And a compliant client will withdrawn the transfer, maybe starting over a new transfer.",
"createdAt": "2023-08-29T13:32:16Z",
"updatedAt": "2023-08-29T13:32:16Z"
},
{
"author": "mrdeep1",
"authorAssociation": "NONE",
"body": "Should Request-Tag be used here to differentiate which response data chunk needs to get sent back instead of repeating data payload?",
"createdAt": "2023-08-29T14:48:26Z",
"updatedAt": "2023-08-29T14:48:26Z"
},
{
"author": "sbernard31",
"authorAssociation": "NONE",
"body": "> Should Request-Tag be used here to differentiate which response data chunk needs to get sent back instead of repeating data payload?\r\n\r\nThat would be used to say : \"I don't want you to repeat the payload\" and so the default behavior will be \"always send the payload\" ?\r\n\r\nIt could work but I feel that default behavior should rather be to not send the payload.",
"createdAt": "2023-08-30T16:31:26Z",
"updatedAt": "2023-08-30T16:31:26Z"
},
{
"author": "mrdeep1",
"authorAssociation": "NONE",
"body": "> That would be used to say : \"I don't want you to repeat the payload\" and so the default behavior will be \"always send the payload\" ?\r\n\r\nRequest-Tag is only allowed to be in a request, not a response. So it cannot be used as a \"hint\" by the server. I think I was more thinking of stateful servers here where Request-Tag would be sufficient as an alternative to the full FETCH payload.",
"createdAt": "2023-08-30T16:58:40Z",
"updatedAt": "2023-08-30T16:58:40Z"
},
{
"author": "chrysn",
"authorAssociation": "MEMBER",
"body": "As much as I'd like to leave the discussion of the response-option-that-guides-later-requests to a separate thread, we'll need a bit of that to carve out the option space. Likewise, I'd have hoped to leave [@mrdeep1's attack](https://github.com/core-wg/attacks-on-coap/issues/3) out, but that too is part of the outcome and thus needs to be considered.\r\n\r\n As I see it, options around a situation with a short request payload and a long response payload are\r\n\r\n1. Do nothing.\r\n * Stateless FETCH stays impossible.\r\n * We'll need to think hard about how to defeat the attack. Possible outcomes are \"the server must be extra careful with its ETags\" and \"the client must send Request-Tag quite often\".\r\n2. Add an option in which the server requests repetition of the payload.\r\n * This allows stateless FETCH (when supported by the client, but that's the case for all solutions).\r\n * It doesn't help with the attack; items of 1 still apply.\r\n2. Alter 7959 in short-request-long-response mode to send the payload by default\r\n This requires a \"breaking\" update of 7959. I put breaking in quotes because AIU implementations do different things anyway.\r\n (Or a variant that @cabo suggested in today's interim, possibly just the rules for block-wise FETCH, although I'd rather use a code independent model, also due to the attack; that'd only break 8132).\r\n * Stateless FETCH becomes possible; stateful FETCH has now more overhead.\r\n * The attack is practically defeated (as long as the client applies the rules of 9175 on when to set a Request-Tag, and the server the rules for when to use an ETag).\r\n Possible mitigations for the increased overhead of FETCH:\r\n 1. The client can minimize the overhead by decreasing the block1 size to split the request payload in two parts, effectively creating a long-request-long-response situation. This adds a single round-trip, and works for requests > 16 bytes (but for the smaller ones, the repetition is not too bad). But it's weird to implement.\r\n 2. The server can tell the client that it *is* stateful, similar to how in a long-request situation it says 2.31 Continue. That option would be elective, stating that the client is free to just send the request payload all over again (as well as all options). If the client supports the option, it sends later requests only with Block2, the reflected option value, and the payload. This even saves data compared to the original scenario, because other request options can be elided as well (precise rules TBD; I think we better pick a different option to Request-Tag as otherwise we get mixups as to who is responsible for the namespace).\r\n The breakage would be visible to clients that do not know the updated behavior (they don't need to know the new option). If the server sends a 4.08 Request Entity Incomplete for any later block request without a request payload, it's even kind of within spec (the server just has a *very* short timeout...). Servers that do have state may support the old behavior *if* they can be sure to not be affected by the attack. Servers that are stateless didn't work previously (or were just implemented assuming the new behavior), so they don't become broken by this change.\r\n\r\nI think that 3.ii is a good way to go.\r\n\r\nIf that's a direction we can converge on, the next question would be to ask implementers what their servers are doing -- would servers out there *tolerate* clients sending additional payloads? (For that is the case where actual breakage can occur -- in the other direction, there's the option \"*if* they can be sure to not be affected\" above).\r\n\r\nFor aiocoap (a stateful server), I can report that it ignores any request payload sent in later Block2 requests. This is compatible behavior. (It will break if clients start randomly accessing FETCH responses, but that is the essence of the attack, so I argue it's already broken).",
"createdAt": "2023-08-30T18:39:28Z",
"updatedAt": "2023-08-30T18:39:28Z"
}
]
},
Expand All @@ -1203,9 +1273,17 @@
"labels": [],
"body": "What should be done for the request for the next Block2 data of the server payload after the request payload has been transferred and has had the NUM=0 Block2 response?\r\n\r\n- Not include the Block1'd data in the request for the next block?\r\n- Include the Block1'd data in the request for the next block?\r\n\r\nCase for NOT including the data [RFC7959 2.7 Combining Block1 and Block2](https://www.rfc-editor.org/rfc/rfc7959.html#section-2.7)\r\n````\r\n In PUT and particularly in POST exchanges, both the request body and\r\n the response body may be large enough to require the use of block-\r\n wise transfers. First, the Block1 transfer of the request body\r\n proceeds as usual. In the exchange of the last slice of this block-\r\n wise transfer, the response carries the first slice of the Block2\r\n transfer (NUM is zero). To continue this Block2 transfer, the client\r\n continues to send requests similar to the requests in the Block1\r\n phase, but leaves out the Block1 Options and includes a Block2\r\n request option with non-zero NUM.\r\n````\r\nas Block1 option is not allowed and hence no data payload in the subsequent request for the next block. Certainly true for PUT and POST.\r\n\r\n[RFC 9177 10.3.3 Handling Recovery](https://datatracker.ietf.org/doc/html/rfc9177#section-10.3.3) states\r\n````\r\n Note that, following (https://www.rfc-editor.org/rfc/rfc7959#section-2.7, the FETCH request does\r\n not include the Q-Block1 or any payload.\r\n````\r\n\r\nCase FOR including the data [RFC 8132 2.3.2 The ETag Option](https://datatracker.ietf.org/doc/html/rfc8132#section-2.3.2)\r\n````\r\n The FETCH payload is input to\r\n that selection process and therefore needs to be part of the cache\r\n key.\r\n````\r\nso at least one cache-key which includes the payload needs to be maintained by the server.\r\n\r\nFurthermore, it is reasonably clear for a FETCH doing an Observe request using Block1 has to send the entire FETCH payload when de-registering the Observe Request [RFC 7641 3.6 Cancellation](https://datatracker.ietf.org/doc/html/rfc7641#section-3.6)\r\n````\r\n a client MAY explicitly deregister by issuing a GET\r\n request that has the Token field set to the token of the observation\r\n to be cancelled and includes an Observe Option with the value set to\r\n 1 (deregister). All other options MUST be identical to those in the\r\n registration request except for the set of ETag Options. When the\r\n server receives such a request, it will remove any matching entry\r\n from the list of observers and process the GET request as usual.\r\n````\r\nas updated by [RFC 8132 2.4 Working with Observe](https://datatracker.ietf.org/doc/html/rfc8132#section-2.4)\r\n````\r\n The Observe option [RFC7641] can be used with a FETCH request as it\r\n can be used with a GET request.\r\n````\r\n\r\nWhat is the right answer here with the FETCH payload (which can span multiple Block1s) for requesting a subsequent block?\r\nIs that then consistent with POST and PUT as per RFC 7959?\r\n\r\n",
"createdAt": "2023-07-06T13:22:19Z",
"updatedAt": "2023-07-22T19:28:27Z",
"updatedAt": "2023-08-30T10:12:05Z",
"closedAt": null,
"comments": []
"comments": [
{
"author": "sbernard31",
"authorAssociation": "NONE",
"body": "Some more inputs : \r\n\r\n[RFC8132\u00a72.5. Working with Block](https://www.rfc-editor.org/rfc/rfc8132.html#section-2.5) says : \r\n> The Block1 option [[RFC7959](https://www.rfc-editor.org/rfc/rfc7959)] can be used with a FETCH request as it\r\n would be used with a POST request; the Block2 option can then be used\r\n as it would with GET or POST.\r\n\r\nAt least to me, it's hard to imagine that repeating all block1 sequence for each block2 request could be a good \"default\" behavior. \r\n\r\nMaybe it eventually makes sense for some FETCH stateless implementation (at cost of more traffic) ? In that case it should maybe better that this kind of server ask for repeating payload explicitly.\r\n\r\nJust to better understand the situation, Is there other use case where repeating all block1 sequence would be needed ?",
"createdAt": "2023-08-30T10:12:05Z",
"updatedAt": "2023-08-30T10:12:05Z"
}
]
},
{
"number": 29,
Expand Down

0 comments on commit 9adedd0

Please sign in to comment.