jiebi/CodeConvo huggingface dataset:
Some small tweaks and fixes for issue : Move HKDF-Extract citing to a sentence and bring HKDF-Extract with it. Change the Messages arg to HashValue, as the actual hashing is stated in the definition of Derive-Secret which is passing this function a hash, not messages. (fixes issue ) More concise defining of HkdfLabel. Use the word "zeroes" instead of "0s". Edited to add: Also, appended a commit to fix an extra trailing paren.
The other possibility is that a hash of the concatenation of hashes was to be the new HashValue. Simplest change is just to make the arg for what's currently used in the definition and passed in.
NAME Rebased. Is this ok to merge now?
It never actually says that hash_value is H(messages).
This should be clear now.
Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.
Instead of just an address / hostname, could we ask to open a tunnel to a prefix?
Tommy, can you please clarify the reasoning why this functionality is useful. Specifying the target as a subnet would to my understanding compared to a general IP tunneling address just restrict that the client will never try to send IP packets to any IP addresses outside of this subnet. And thus potentially enable serving multiple masque clients using restricted targets to share the source IP address. Is that the intention? Or is the intention here to have the masque server potentially redirect to another instance based on the target in the request?
This came up in a discussion—if we let you ask to connect to a specific hostname or address instead of all addresses (as we do today), we wondered if there was any need to connect to a subnet of addresses. This would be for connecting to an IPv6 /64, which is unique enough for a device, and doesn't require needing to assign an IP address exclusively to the client that is issuing the request.
I'm supportive of adding this if we can come up with an encoding that's not a pain to implement. For example slash with prefix length seems fine to me - the slash would be percent-encoded just like the IPv6 address colons are.
In relation to my just raised issue on source address validation if we add this functionality, I would think that the proxy would need to do destination or source address validation depending on direction of traffic to enforce the signalled aspect.
The goal here is really to provide more clarify about cardinality, if there's a better way or place to do that, that'd be fine.
I don't believe this is necessary. This idiom is well understood in TLS and this just appears to be excess verbiage.
Hiya, (As with all these PRs, I'm ok if they're not accepted...) For me, that is better than the original, but I do think we ought state the expected cardinality that implementers need to handle somewhere. I reckon it's better to not assume implementers are very familiar with SVCB as for libraries at least, the DNS stuff happens elsewhere. They will have to figure that out eventually, but better to say it somewhere explicitly I think, or we may face some important code base that doesn't handle >1 public key when it ought. Cheers, S.
I tried to work in what I thought were the important parts of Gorry's suggested text, PTAL if I captured everything.
It's also true that for many RF media, the performance of the forward path can be impacted by the rate of acknowledgment packets when the link bandwidth is shared.
“Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by acknowledgment packets. When traversing such links, reducing the number of acknowledgments allows connection throughput to scale much further.” I’m going to push back again on this as largely wrong. Links such as DOCSIS, LTE, satellite and WiFi are asymmetric. But it’s not just that the design decisions made for these types of link resulted in asymmetric capacity (throughput limit), the designs also share the capacity, and it is important to mitigate the impact on that sharing of capacity, than purely thinking of it items of bytes/sec of capacity used. A lower feedback rate can help avoid inducing flow starvation to other flows that share resources along the path they use.On mobile devices sending data consumes RF and battery power and is more costly for a host of reasons not just asymmetry when present.
NAME -- I don't follow why you say that the statement is wrong. It seems to me that you think that the statement is inadequate. Would you mind responding here with some text you would prefer instead, and I'm happy to wordsmith and turn it into a PR?
I suggest some text something like: For some link technologies (e.g., DOCSIS, LTE, WiFi, and satellite links) transmission of acknowledgment packets contribute to link utilization and can incur significant forwarding costs. In some cases, the connection throughput in the data direction can become constrained when the reverse bandwidth is filled by acknowledgment packets. In other cases, the rate of acknowledgment packets can impact link efficiency (e.g. transmission opportunities or battery life). A lower ACK frequency can be beneficial when using paths that include such links.
NAME -- Is the text proposal in the issue enough for you to make a PR?
This is much better.
It might pay to reconcile: {{vars-of-interest}}) to be larger than the congestion window, unless the packet is sent on a PTO timer expiration; see {{pto}}. And now exceeds the recently reduced congestion window. Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.
Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?
That sentence is the the definition of the . We haven't implemented that either, and I was wondering if it truly helps.
For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for QUIC.
The second sentence was added later in , and the MUST wasn't updated, so I'll fix that. Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going. I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.
seems to be the wrong issue you are pointed to...
Good catch, it's
I've suggested some symbolic references.
Took a stab at normative language for the rules to process Selection Properties, as discussed in . As far as I remember, we always said that outcomes have to be deterministic/consistent, so I made everything that matters a MUST. I guess our example illustrates that even given the same Selection Properties, the outcome might change depending on the situation, e.g., your path might still be Wifi but it might or might not support your preferred protocol. So, does this really have to be all MUST, or is there a SHOULD in there? Discuss. :) Also, if anyone can name a good reason why the outcome has to be deterministic, please suggest text - maybe something like "avoid surprises for the application", but this didn't really sound right, so I left it out for now.
In section 5.2. in the API doc: "Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. Selection Properties that select paths take preference over those that select protocols. For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the preference." This sounds rather like an example algorithm that should maybe go into the implementation doc instead? Or is there any part of this that we need to specify normatively in order to ensure that all systems implement the same?
This goes back to issue on "conflicting policies". At the time, we decided that there must be a deterministic outcome, therefore, text was added to both the API and the Implementation document, see . If we keep it that way, perhaps the text here should point out that the goal is to resolve conflicting policies, so we achieve a deterministic outcome.
Ah okay, thanks for the background info; missed that. I think we need to use normative language here then. Maybe also a separate subsection makes this more prominent.
This reads to me like the rules for processing polices rather than an example algorithm. I think it is part of the API... Normative language would be good and a stronger opening that explains why the rules exist.
I don't think a separate subsection would make this a better read - this fits fine as it stands, as an intro to the transport property specification IMO. Regarding normative language, that's a separate discussion. So, can we close this issue?
Agree that we don't need a separate subsection. I can try to tweak the beginning of this part a bit to explain why the rules exist as NAME suggested. Regarding normative language - we definitely have it in the API draft, right? So why not have the discussion on it here as well? if we're serious about deterministic outcomes, I guess the whole thing needs to be a MUST, right?
Sorry, true, that normative language debate was about the arch draft, and we definitely have it in the API draft. So yes, let's discuss it here. I also think a MUST would make sense.
So the order of filtering out require/prohibit is not important (outcome is the same) - making the order a MUST does not make sense. Also, first sorting by preference and then filtering has the same outcome as doing it the other way around. the only thing we need to say is that filtering MUST happen and sorting SHOULD happen.
ok - I have to admit I didn't think this through, I just agree that we want a deterministic outcome from this.
Why did we require a deterministic behavior in first place? Does this prevent TAPS implementations from running experiments like Apple did with TCP SACK and ECN? Does this prevent probabilistic path probing?
This was discussed in the TAPS BoF? ... I thought it was about developers being assured that X will happen if they choose Y and not finding the ground shifting as they use the interface.
Interim: Prefers and avoids allow the implementation to decide the ordering and weighting; require and prohibit are the only hard requirements. Applications should be able to cope with any possibility that isn't prohibited. Likely should add implementation text to say how preferences weight racing.
During the interim discussion, we found that was too strict and limiting, so we opted for another approach that moves the selection algorithm to the Implementation draft. I'm preparing another PR implementing these changes.
The text that ended up in the implementation draft is not fully consistent with the racing text, opening a new issue for this and closing this issue.
LGTM, merging this. thanks, Theresa!This reads good to me.
cc NAME
Looks good to me, thanks!
Comment by NAME Maybe add a sentence saying this means there is no repudiation of messages?
I would prefer not to say anything like that here, because the degree to which signature implies non-repudiation depends on a bunch of context for how the signature keys are managed. Clearly if you have long term or certified keys, then yes, there's a pretty high degree of non-repudiation. But people are also interested in configuring MLS to be deniable, e.g., by exchanging signature keys over a deniable channel. So I would propose closing this with no action.
Ah, that is a very good point. In my head I was thinking signature means proof of key and key is proven to person. But that might certainly not be the case here.
The description of is clear that proposals defined in the RFC are not to be included because they are considered standard, however there is no such clarification around extensions. In general, extension requirements are not all that clear because in several places (such as Lifetime) it is mentioned that an extension must be included, however they are all listed as recommended rather than required in the table. It also raises a question in that if an extension is required to be implemented as part of the specification, and required in every KeyPackage, should it just be a field rather than an extension?
Even that is not quite clear to me. At least to me it doesn't follow from Section 10.1. The last one at least, I can shed some light on, as we had this discussion before and I was arguing the same thing. From what I remember, the argument was the keeping it an extension rather than a field would force implementers to implement the Extension mechanism. I don't have a super strong opinion here, but I seem to remember that that's what it boiled down to. I generally agree, though, that some things around RequiredCapabilities (RC) and Capabilities in general is unclear. I discussed this with NAME and here are some examples/questions that came up: If a group doesn't have an RC extension, can we assume that all extensions/proposals in the spec are supported by everyone, or do we have to check all KeyPackages? Do we want all extensions/proposals in the spec to be MTI and thus implicitly supported by everyone?
It might be useful to distinguish between basic (MTI) ones like Add, Remove, etc. and consider some optional such as ExternalInit or AppAck. Relatedly, should the extension in the KeyPackage list all the Spec proposals/extensions, too? Are they invalid if they do or if they don't? We might want to discuss the difference between RC and a potential group policy. The way I understand it, RC is not meant to be an allow list or a block list, but instead should specify a minimum requirement for all clients in the group. A question here would be: If it's not in the RC, but everyone's capabilities support it, can I use/send it?
Reacting to Konrad's points here: It seems like to to be sure, you always need to check. RC just helps ensure that the check will produce the right answer. I would propose the answer to this be "Yes, the proposals/extensions in the spec are MTI" If the answer to the prior question is as I propose, then you don't need to list spec proposals/extensions in Capabilities The difference between RC and checking everyone supports it is whether we expect it to be supported in the future. For Proposals, that might not matter; for GroupContext extensions, it matters more. It also seems like there's a fair argument that RequiredCapabilities should just be removed from the spec and replaced by some application-layer coordinated policy. I would be OK with that. To NAME point about mandatory extensions -- I would probably be OK with converting mandatory extensions to fields, especially with the better division of labor proposed in .
I kind of like the idea of RequiredCapabilities because it enforces the proper checks lower down. Application layer would need to proxy packets via a middleware type of layer which could potentially be messy.
Discussion on working call: Agreement to not list in-spec capabilities in RC/Capabilities, so all those things are MTI
moving into .
Ken, here is the reasoning for moving encryption functionality outside the SUIT manifest: When the firmware author needs to encrypt a payload for a specific recipient it needs to know its public key (for HPKE) or its symmetric key (for AES-KW). Since the firmware author does not typically know the recipients ahead of time, it cannot perform this encryption operation. What he can, however, do is to digitally sign the manifest (and thereby the firmware image) since it only requires its private key. Later the distribution system, before delivering the firmware to the devices, will encrypt the firmware images. It cannot modify the manifest anymore since otherwise the signature previously generated would be invalidated. Hence, any information regarding firmware encryption has to go into the envelope. I hope this makes sense. For this reason, I believe the current text in the document is correct.
I've misunderstood your intention. Are these correct? Author has the raw firmware image and creates by signing the with its signing key. Distribution System receives the raw firmware image and its from the Author, then encrypts the firmware. It appends to (outside the ). Device verifies the and decrypts encrypted firmware image using . My concern is that the would be untrusted because it locates outside the signature. How about this one? The order of suit-protection-wrappers array corresponds to the suit-components array in suit-common it can be if no decryption is required The Device can verify whether the decrypted firmware image is correct using the digest hash of raw firmware image the image digest and the image size are trusted because they are inside the though the s are untrusted because they are outside the The Author MUST aware that the firmware will be encrypted by Distribution System to create appropriate suit-install section
The distribution system is not untrusted but rather trusted to do the encryption of the plaintext firmware image and to distribute it to the intended recipients. If the author already knows the recipients ahead of time and has their public keys, then it can also encrypt the firmware image without relying on the distribution system. Hence, I do not believe that the wording that the distribution system is untrusted is correct. Note that the recipient will get to learn that the encryption has been applied by the distribution system since the encryption info is also signed. The recipient (device) can still check the signature of the manifest to verify whether the plaintext image has been unchanged.
Hence, I don't see a problem with the approach
Btw, I agree with you that the manifest needs to carry a hash of the plaintext firmware and it also needs to contain instructions for matching the hash against a specific value. The reason why I believe that no commands for processing the encrypted payload are needed is simply because the encryption must happen before any of the other processing steps need to take place. Otherwise nothing can proceed. Is this the right approach? I don't know.
I wonder whether we should bring this up on the SUIT mailing list since it is an important design decision.
The term "untrusted" I used was ambiguous, but I meant the part was outside the signature. Before discussing in the mailing list let me confirm this: Distribution System is trusted case A-1) as a firmware server and a device management infrastructure case A-2) as a firmware server and a device management infrastructure, and also a manifest signer The firmware is encrypted by case B-1) the Author case B-2) the Distribution System With case A-2, the Distribution System can just update the manifest and then update the signature because Devices trusts its public key. With case B-1, the Author can create encrypted firmware and its manifest, so that there is no need Distribution System to modify the manifest. They work well with current SUIT Manifest, but our case does not especially with non-integrated payload. Am I correct?
I think you are saying that because a non-integrated payload requires a URI to be included in the manifest, which will then be integrity protected. Hence, the distribution system will not be able to change that URL and it will typically not have permissions to replace the content of the referenced file. Is this correct? FYI: I think it would be good to have examples of all these cases in the draft.
Here is what Øyvind proposes in URL
In the firmware encryption draft we have defined an extension to the envelope that indicates what encryption parameters are applied to which component. Here is the CDDL: Currently the text provides no explanation or an example of how this linkage works.
This aspect is related to URL and to the mailing list discussion URL
This issue is also related to URL
With in PR , this issue is solved.
SUITEncryptionInfo was defined in the past SUIT Manifest core document describing how to decrypt the firmware image, but in this document it may not be associated with any component. I will create a Pull Request to move SUITEncryptionInfo under the suit-manifest.
See also URL A new idea to leverage SUIT Dependency for Firmware Encryption has come up to my mind. Please review and make comments, especially for SUIT Manifest usage and security considerations. The Author creates firmware and its manifest The Distribution System encrypts the firmware and distribute it to Devices The Device fetches and decrypts encrypted firmware, then check and install it It introduces new section suit-security-wrapper holding SUITEncryptionInfo, which is appended by the Distribution System The Device decrypts the encrypted firmware with SUITEncryptionInfo and then check it with condition-image-match Distribution System cannot modify the URI in the manifest where the encrypted firmware is stored SUITEncryptionInfo is used without verification because it locates out of the Author's signature The Author and the Distribution System create manifest respectively Distribution System's manifest fetches encrypted firmware and decrypts it, and depends on Author's manifest Author's manifest check the decrypted firmware with condition-image-match The Device MUST trust both Author and Distribution System keys to verify manifests The Distribution System can freely set the URI to distribute encrypted firmware in Distribution System's manifest SUITEncryptionInfo is inside signature created by the Distribution System (Only important parts are shown in this example) (Only important parts are shown in this example) Best, Ken
Internet-Draft draft-ietf-suit-firmware-encryption-URL is now available. It is a work item of the Software Updates for Internet of Things (SUIT) WG of the IETF. Title: Encrypted Payloads in SUIT Manifests Authors: Hannes Tschofenig Russ Housley Brendan Moran David Brown Ken Takayama Name: draft-ietf-suit-firmware-encryption-URL Pages: 52 Dates: 2024-03-03 Abstract: This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key.