Skip to content

Commit

Permalink
Script updating archive at 2020-06-03T19:23:37Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jun 3, 2020
1 parent 8e2e2b0 commit a8b4c45
Showing 1 changed file with 122 additions and 8 deletions.
130 changes: 122 additions & 8 deletions archive.json
View file
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2020-06-03T06:41:04.482814+00:00",
"timestamp": "2020-06-03T19:23:34.341584+00:00",
"repo": "quicwg/base-drafts",
"labels": [
{
Expand Down Expand Up @@ -82280,7 +82280,7 @@
"id": "MDU6SXNzdWU0MzgwMjM0NDk=",
"title": "Discarding connection state at server on unvalidated client",
"url": "https://github.com/quicwg/base-drafts/issues/2656",
"state": "OPEN",
"state": "CLOSED",
"author": "janaiyengar",
"authorAssociation": "CONTRIBUTOR",
"assignees": [
Expand All @@ -82292,8 +82292,8 @@
],
"body": "The recovery draft says:\r\n```\r\nUntil the server has validated the client's address on the path, the amount of\t\r\ndata it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.\t\r\nIf not all unacknowledged CRYPTO data can be sent, then all unacknowledged\t\r\nCRYPTO data sent in Initial packets should be retransmitted. If no data can be\t\r\nsent, then no alarm should be armed until data has been received from the\t\r\nclient.\r\n```\r\n@mikkelfj notes in #2655 that the sender should discard connection state after some time.\r\n\r\nThis should probably happen after the idle timeout. In which case, the idle timeout timer ought to be armed. ",
"createdAt": "2019-04-28T07:13:54Z",
"updatedAt": "2020-04-29T15:19:10Z",
"closedAt": null,
"updatedAt": "2020-06-03T19:19:51Z",
"closedAt": "2020-06-03T19:19:51Z",
"comments": [
{
"author": "mikkelfj",
Expand Down Expand Up @@ -82371,6 +82371,20 @@
"body": "The originally quoted section has been substantially rewritten and now specifies the PTO alarm, so there's no confusion about which alarm.\r\n\r\nSo I support @martinthomson suggestion to close this with no further action/OBE.",
"createdAt": "2020-04-29T15:19:10Z",
"updatedAt": "2020-04-29T15:19:10Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "@janaiyengar, if you agree with the previous suggestions, we could have one fewer open issue with very little effort.",
"createdAt": "2020-06-03T06:47:38Z",
"updatedAt": "2020-06-03T06:47:38Z"
},
{
"author": "janaiyengar",
"authorAssociation": "CONTRIBUTOR",
"body": "My experience with this suggests that things work fine with just the idle timeout, so closing this.",
"createdAt": "2020-06-03T19:19:51Z",
"updatedAt": "2020-06-03T19:19:51Z"
}
]
},
Expand Down Expand Up @@ -109430,7 +109444,7 @@
],
"body": "Over in TLS we have been discussing the data which is included in the AEAD transform. \r\n\r\n1. Some parts of the context for encryption (epoch, length, etc.) are implicit.\r\n\r\n2. The AD only covers the bits on the wire.\r\n\r\nThis intuitively seems like it ought to be OK because these values do affect how the protection is done, but only implicitly. For instance, length delineates the data, the packet number/record sequence number controls the nonce, etc., but nevertheless only some of these values are in the AD. It turns out that there is a bit of a gap between analysis we have of this so far and the\r\ncurrent state, and specifically we don't have analysis of the epoch, which is sent only partially in both QUIC and DTLS [0]. Note that QUIC is actually worse than DTLS here because in DTLS the epoch is folded into the sequence number used to make the nonce, but in QUIC the nonce is just the packet number. This issue is intended to raise the question of if we should revisit that, for instance by putting the epoch in the AD.\r\n\r\n[0] https://mailarchive.ietf.org/arch/msg/tls/Ri33zZmFNb1kZ4HToDHs9cDDTPY/",
"createdAt": "2020-05-15T22:58:11Z",
"updatedAt": "2020-06-02T21:46:32Z",
"updatedAt": "2020-06-03T11:23:07Z",
"closedAt": null,
"comments": [
{
Expand Down Expand Up @@ -109488,6 +109502,20 @@
"body": "Without evidence this is a problem, I strongly prefer the status quo which aligns more closely with TLS.\r\n\r\nIf we get new information, we can always fix this in QUICv2.",
"createdAt": "2020-06-02T21:46:32Z",
"updatedAt": "2020-06-02T21:46:32Z"
},
{
"author": "fxguenther",
"authorAssociation": "NONE",
"body": "As already mentioned, there's little analytical support regarding key updates in QUIC (and DTLS), including [our analysis](https://www.felixguenther.info/docs/QUIPS2020_RobustChannels.pdf). As stated for DTLS, my understanding is that some form of authentication of the epoch number would be helpful for a clean analysis.\r\n\r\nMy thought is: with QUIC's current approach, you could _in principle_ have that the key+IV across two epochs collide, which then would mean you can replay packets across those two epochs. If the epoch is authenticated through the AAD, that's prevented. With XOR-ing into the nonce it's more messy, as now you could have a colliding IV 'cancel out' the XOR (the same affects DTLS, actually).\r\n\r\nThat said, I would expect the concrete loss for key+IV collisions to probably be an additional birthday-bound term in the order of #epochs^2 / 2^{|key|+|IV|}. Here, I am thinking of #epochs = number of epochs in a connection, coming from an/our analysis viewpoint on the full channel. In extending that to multiple keys one would usually want to abstract out key generation and assume key/IV across all epochs to be independent, hence the birthday bound.\r\n\r\nMartin pointed out to me that (a) #epochs might be reduced to the number of currently active epochs (2-3), and (b) |IV| might be too much due to the sequence number range, which may lead to nonce collisions between ranges.\r\n\r\nSo, overall, while having the epochs in the AAD might be cleaner from an analysis point of view, I don't have a strong basis for that and think no-change likely comes with a small loss only in comparison.",
"createdAt": "2020-06-03T07:14:14Z",
"updatedAt": "2020-06-03T07:14:14Z"
},
{
"author": "larseggert",
"authorAssociation": "MEMBER",
"body": "It sounds like the proposal is to close with no action, or alternatively, to park this issue until new information is available? It would be great if we could resolve this soon, since we are hoping WGLC the next set of documents w/o open design issues.",
"createdAt": "2020-06-03T11:23:07Z",
"updatedAt": "2020-06-03T11:23:07Z"
}
]
},
Expand Down Expand Up @@ -110093,7 +110121,7 @@
],
"body": "I think the spec is ambiguous when it says in section 17.2:\r\n\r\n> PING, PADDING, and CONNECTION_CLOSE frames are also permitted. An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error.\r\n\r\nand:\r\n\r\n>Handshake packets MAY contain CONNECTION_CLOSE frames.\r\n\r\nBut CONNECTION_CLOSE can mean 0x1c or 0x1d. Are both permitted during the handshake?",
"createdAt": "2020-06-02T22:51:30Z",
"updatedAt": "2020-06-03T06:37:29Z",
"updatedAt": "2020-06-03T17:53:31Z",
"closedAt": null,
"comments": [
{
Expand Down Expand Up @@ -110130,8 +110158,34 @@
"body": "I'm going to re-close the can of worms I half-opened in my earlier comment and take this as editorial.\r\n\r\nFrom memory, the larger question of how to deal with junk is something we've discussed several times. If anyone wants to take that up, I'm happy to do that, but let's at least correct the obvious error.",
"createdAt": "2020-06-03T06:37:28Z",
"updatedAt": "2020-06-03T06:37:28Z"
},
{
"author": "rpaulo",
"authorAssociation": "CONTRIBUTOR",
"body": "It does make sense that we only allow 0x1c during the handshake.",
"createdAt": "2020-06-03T17:53:31Z",
"updatedAt": "2020-06-03T17:53:31Z"
}
]
},
{
"number": 3715,
"id": "MDU6SXNzdWU2Mjk4MTA3NjY=",
"title": "MUST not -> MUST NOT",
"url": "https://github.com/quicwg/base-drafts/issues/3715",
"state": "OPEN",
"author": "larseggert",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [
"-transport",
"editorial"
],
"body": "In \"17.2.5.1. Sending a Retry Packet\":\r\n\r\n`This value MUST not be equal` -> `This value MUST NOT be equal` ",
"createdAt": "2020-06-03T08:44:17Z",
"updatedAt": "2020-06-03T08:44:25Z",
"closedAt": null,
"comments": []
}
],
"pulls": [
Expand Down Expand Up @@ -388678,7 +388732,7 @@
],
"body": "",
"createdAt": "2020-06-02T00:09:01Z",
"updatedAt": "2020-06-03T03:06:26Z",
"updatedAt": "2020-06-03T17:55:04Z",
"baseRepository": "quicwg/base-drafts",
"baseRefName": "master",
"baseRefOid": "b3ea75ac4d66a725efc76fe77f028e7fe1903df3",
Expand All @@ -388703,6 +388757,13 @@
"body": "I was saving that for the final version, by popular demand. If you have a reason to change, then I can do that (I'll also want to update the keys for Retry in that case).",
"createdAt": "2020-06-03T03:06:26Z",
"updatedAt": "2020-06-03T03:06:26Z"
},
{
"author": "rpaulo",
"authorAssociation": "CONTRIBUTOR",
"body": "I agree with @martinthomson. Let's leave the salt update to the final version.",
"createdAt": "2020-06-03T17:55:04Z",
"updatedAt": "2020-06-03T17:55:04Z"
}
],
"reviews": []
Expand Down Expand Up @@ -388901,7 +388962,7 @@
],
"body": "When we prohibited the use of application-layer CONNECTION_CLOSE in\r\nthese packets, we should have updated the text in the description of the\r\npackets also.\r\n\r\nCloses #3713.",
"createdAt": "2020-06-03T06:40:08Z",
"updatedAt": "2020-06-03T06:40:08Z",
"updatedAt": "2020-06-03T17:53:56Z",
"baseRepository": "quicwg/base-drafts",
"baseRefName": "master",
"baseRefOid": "b3ea75ac4d66a725efc76fe77f028e7fe1903df3",
Expand All @@ -388913,6 +388974,59 @@
"mergedBy": null,
"mergeCommit": null,
"comments": [],
"reviews": [
{
"id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDIzMjU5NTA1",
"commit": {
"abbreviatedOid": "e694476"
},
"author": "kazuho",
"authorAssociation": "MEMBER",
"state": "APPROVED",
"body": "",
"createdAt": "2020-06-03T06:43:58Z",
"updatedAt": "2020-06-03T06:43:58Z",
"comments": []
},
{
"id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDIzNzk1NjU4",
"commit": {
"abbreviatedOid": "e694476"
},
"author": "rpaulo",
"authorAssociation": "CONTRIBUTOR",
"state": "APPROVED",
"body": "",
"createdAt": "2020-06-03T17:53:56Z",
"updatedAt": "2020-06-03T17:53:56Z",
"comments": []
}
]
},
{
"number": 3716,
"id": "MDExOlB1bGxSZXF1ZXN0NDI3NDAzMzIz",
"title": "Fix typo",
"url": "https://github.com/quicwg/base-drafts/pull/3716",
"state": "OPEN",
"author": "janaiyengar",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "Closes #3715",
"createdAt": "2020-06-03T19:22:42Z",
"updatedAt": "2020-06-03T19:22:42Z",
"baseRepository": "quicwg/base-drafts",
"baseRefName": "master",
"baseRefOid": "b3ea75ac4d66a725efc76fe77f028e7fe1903df3",
"headRepository": "quicwg/base-drafts",
"headRefName": "jri/mustnot",
"headRefOid": "8318c14e9a1b1ce079a3b6e3711d1514b3259514",
"closedAt": null,
"mergedAt": null,
"mergedBy": null,
"mergeCommit": null,
"comments": [],
"reviews": []
}
]
Expand Down

0 comments on commit a8b4c45

Please sign in to comment.