jiebi/CodeConvo huggingface dataset:
If all EAD were critical then the old device which doesn't understand the new EAD would be forced to discontinue the protocol at the arrival of the remote attestation EAD. If the EAD is elective, then both old and new devices can be supported. Question: With this example in mind, is critical / elective a property of the EAD type, or isn't it rather a boolean set by the application? I can think of another use case where remote attestation is mandatory and it doesn't make sense to define different EADs for these two use cases. (Then we are somehow back at the application specified property. But it may still make sense to have a standardized way of expressing criticality.) Thoughts?
The critical/elective property always needs to be encoded in the message (as an LSB, or as the number's sign) no matter whether criticality is the sender's choice or whether it's part of the registration. From a recent chat I think that registering one number, and then allowing it to be used in positive (elective) or negative (critical) role as by the sender's choice. Application authors would describe in which criticality/-ies it makes sense to use their number, just as they describe in which of the messages it makes sense. (The alternative is to allow registering elective and critical options independently, and that application authors who do need to give the senders a choice of using either would register a pair of options; really would work just as well). Introducing RATS data seems like a very good use case to illustrate EAD examples. (In this particular case I don't know why a sender would insist the attestation to be processed into its network joining). To rephrase the original use cases with recently published terminology, we can refer to . That reference might go with a suggestion that devices that can afford sending a few more bytes should occasionally do so in a grease-style non-critical option, or maybe in a non-critical Encrypted-EAD1 option right away. I'd welcome if ace-ake-autz already defined an EAD field for what could resemble Encrypted-Client-Hello; AIU it currently refers to an older version of EDHOC.
It could be updated to place LOCW and ENCID into separate EAD items, and the latter could be more generally defined as "a container for encrypted data which the responder, possibly guided by other EAD1 fields, can use to come up with a suitable IDR". (How encid is then constructed would not be a property of using that particular option, but follow from using the LOCW option). Then, there would be no need for a defined Grease field, as that ENCID field could serve the very same purpose.
Since there seems to be a case for non-critical EAD I made PR . Please review. (Yes, ace-ake-authz needs to be updated, following the closing of this issue.)
I did not read this discussion before now as it did not seem relevant for the base EDHOC protocol. The PR seems quite far from the use case described here. PR described a general critical, non-critical mechanism similar to X.509 extensions while the discussion in this issue is about an ECH type of mechanism..... PR does not seem to be the basis of a good ECH mechanism.... NAME could you have a short presentation at LAKE IETF 114? (edit: fixed Christian's github name)
I think it is clear that PR does not solve the use case outlined here. In particular, the comment from NAME above is not considered as far as I can see. But the point about critical / non-critical (eadlabel, eadvalue) appeared in this discussion and merits to be specified as a general feature.
I think it would be good with longer discussion about ECH type mechanisms in EDHOC. Might be added on later but it could also benefit from being added alrady in the base EDHOC specification. For a use case where the Initiator knows the long term key of the Responder the TLS ECH solution is a quite ugly hack that uses two different keys and an ineficient message flow. The use of a single key as discussed above is an improvement, but the use of a noise XX pattern is not optimal. If you want to design something for the use case where the Initiator knows the long term key of the Responder it makes more sense with noise IK which is used by WireGuard. If the use case where Initiator knows the long term key of the Responder is small the above approach makes sense.
If is is big it might make more sense to define new method(s) based on the noise IK pattern.
Could we have a design team meeting or an interim to discuss this issue?
In the use case that the Initiator gets the Responders static public key beforehand The Responder would in this case have a static DH key. The Initiator could use Static DH or a singature.
Perhaps a breakout meeting during/just before IETF 114?
Closing this since NAME agreed that the introduction of critical/non-critical EAD (PR , included in -15) in combination with an example using third party encrypted EAD (as in ace-ake-authz) resolves the issue.
if we want to do that. There was a hole in the error code space, so I filled it with this. I haven't pulled Push out to its own error; it doesn't seem like it belongs with this one.
We might want to add a mention of this in A.4 where we talk about PROTOCOL_ERROR
(I couldn't find anything on this, but I'm prepared to be corrected. Also, it's late, so if this is closed, I'm totally OK with that.) We're just in the process of doing full validation of pseudo-header fields (I know, seems late, what are you gonna do about that). And we realized that there is no error code for indicating this sort of error. That is, if pseudo-fields are out of order, or a request contains , or there are uppercase characters. contains lots of MUSTs, but it seems to rely entirely on the definition of "malformed" which leads to H3GENERALPROTOCOL_ERROR. This is fine, but not especially helpful in isolating problems. Could we define an error code for this specific case?
H2 just says malformed is treated as PROTOCOL_ERROR. So H3 is providing parity. There might be an argument for more fidelity but I'm not convinced it would help much. It could require more contortions in the text - do you have different error for different types of malformed?
Internally, we use a different error code. Of course, all internal error codes map to the same code for sending in RESETSTREAM/CONNECTIONCLOSE.
I'm inclined not to do much, if anything, here. They all trace back to "malformed," as you note, which leads to GENERALPROTOCOLERROR. The instances in which we use GPE are: Malformed HTTP messages Push whose request headers change across multiple promises As a substitute for more specific codes I wouldn't be opposed to splitting the first two off into a new / two new codes, because that would be consistent with our principle of indicating the general area where the failure occurred. I would push back on having separate error codes for specific ways the message could be malformed, because that's pretty expansive rabbit hole.
OK, I'm satisfied with that response. I think that we'll just have to signal extra information in the text field. Happy to close this.
NAME do you think an error code for "malformed message" would be useful, if we don't go into the various types of malformed?
That might be useful, yes.
This is a design change, albeit a marginal one.
NAME let's merge the associated PR but keep this issue open and marked as "call-issued"
Keeping open, as requested.
Closing this now that the IESG review of draft 33 has concluded.
In fairness, I question whether the IESG review of the HTTP drafts has concluded. But as this is not an IESG comment, I'm content to close it. People have had time to object.
Yes I agree Mike. This was due to me being over eager with the close button. The issue may not have strictly been raised in the period that the IESG were directed to review the doc, and they have yet to ballot on draft 33. But either way there was no push back from the WG on this change since draft 33 was published.
Section 7.2.6. says " for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored." I don't think this is entirely true as you can still decide in which order you schedule independent messages on one stream.
I don't get this. The sentence says "in-order". Scheduling them from buffer A into buffer B in accordance with priorities won't help when everything leaves buffer B in a fixed sequence.
How about a less complex sentence: ..."for example, if the transport system selects a stack that only provides a single in-order reliable stream, the prioritization information is ignored."
message on the taps "layer" are independent. so the order an application calls send on these message doesn't have to be the same order the messages are send on an "in-order stream"
Oh, now I see what you mean. Hmmm... looking at the text, it seems that we could just delete this sentence and the problem is solved?
I think what was intended with the example was to show that the set priorities may not have any effect. Perhaps we should instead just add "and the set priorities may not have any effect" if we want to be explicit? Removing it also works though.
I think just add that!
I'm for removing it (I think I wrote this sentence btw :-) ). Giving this example just throws off someone who thinks about this case like Mirja did here - even if we say "may not apply", the reader may (correctly) think "but why, in this case they CAN well apply!". So I don't find that helpful. For context, the full current statement is: and I believe that we say everything we need to say if we just change this into:
I like simple examples, this one wasn't great so this is OK.
Any chance we could also update the initial salt?
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).
I agree with NAME Let's leave the salt update to the final version.
With Google's QUIC deployment, we're already experiencing version ossification due to middleboxes inspecting initial packets - some of our traffic is stuck on older versions of GoogleQUIC because of this. Changing the salts every time we change the version number will help remind everyone that this is not an ossified aspect of the protocol. The cost to implementors is pretty much zero. NAME out of curiosity, why the pushback?
What NAME says makes sense to me, so I would be in favor of shipping draft-29 with new salts.
I updated the salts and the test vectors in quic-go, and I can confirm that the values match.
The draft describes that a client SHOULD NOT reuse a token in different connections (URL). However, I miss the argument that the server SHOULD NOT construct the same token multiple times. This argument addresses the risks of client tracking via tokens if a deterministic approach is used to construct them.
Maybe ?
NAME do you mean already covers this?
Yes, my view is that and the corresponding mailing list thread (URL) covers this issue. They discuss about unlinkability between the tokens issued by a server.
NAME do you agree that this is (mostly) covered by ? If yes, can we close this issue and resolve it as part of ?
No, does not cover this particular point. makes the point that a network observer should not be able to derive information such as a timestamp from observed tokens. However, this issue says that the construction of the token should not be deterministic. To illustrate this problem, assume that the token is more or less the hash of the client's source address. Thus, the client receives upon repeat connections each time the same token, if its source address is identical. As a result, even if the client uses each token only a single time the corresponding connections established with these tokens can be correlated to each other by a network observer.
NAME could be modified to cover your issue? could you comment there?
NAME Ok, I will make proposals within to cover this issue.
NAME the automation failed here - this should not be moved to "Text Incorporated", it should just be closed As stated in URL, my understanding is that a token sent in a NEW_TOKEN frame SHOULD be encrypted. The only exception would be the case of the token carrying only an opaque and randomly-generated key identifier in a stateful design (i.e. a server using a key-value store to retain the information of previous connections). Otherwise, an observer can use the information contained in the token sent in an resuming connection, to correlate that connection to the previous connection that issued the token. For example, if a server includes the generation time of the token in plaintext, an observer can extract that information found in an Initial packet to nail down the connection that issued the token. While I think we might be call this an editorial issue, I think we should clarify this as a normative requirement (e.g., SHOULD). Hence bringing the discussion to the mailing list as well. Kazuho Oku
Adding an example manifest using AES-KW in case where the Author knows the recipients (the Author and the Devices have the same pre-shared key).
This is a good example. I looked through it and it made sense to me.
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. 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. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTMLized version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
We got another Secdir review: Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits Compared to my last review (-09) a lot of text has been removed, reducing the technical details and giving a briefer (but arguably cleaner) overview. I do still have a personal preference of dropping CurveCP and MinimalT as I don't really think these are anything but abandoned research items. I have never seen or heard of these being deployed. I would be more tempted to list openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite some deployment. If the intent is really to show different kind of API's, than there are other esoteric examples that could be included, such as Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but with the ability to generate session keys for encrypted bulk transport (eg for video/audio or file transfer) Section 5.1 "Session Cache Management (CM):" which does not include IKEv2/IPsec, even though it does have session resumption (RFC 5723). I guess this is because the section limits itself to "the application" that can restart the session. But for IKEv2/IPsec the same could be said. An application that after a long idle period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 session resumption. WireGuard does not have this capability as there are no API/hooks for packet trigger tunnel events (AFAIK) "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support PSK based authentication - only public key based authentication. While I understand the IKEv2 entry (PSKs are used for authentication of peers), I am not sure the ESP entry should be here.
ESP does not "authenticate peers", unless you call "being able to decrypt and authenticate packets" as an instance of "authenticating peer" Section 5.2 This states "This can call into the application to offload validation.". This "can" is only not supported by WireGuard, as all of this is happening inside the kernel. Maybe a note could be useful here? "Source Address Validation" - It is a little unclear why TCP based protocols are not listed here. They (implicitly) do source address validation. Perhaps the introduction in this paragraph can state this more explicitly. Eg "for those protocols that do not use TCP and therefor do not have builtin source address validation ......."
On which protocols to include, MinimalT and CurveCP have different feature sets and interfaces exposed, which I think warrants their inclusion. Things like Signal and OTR indeed have seen very wide deployment, though they're asynchronous, application-layer protocols akin to MLS, which I think is out of scope. I'd also not like to add draft-mavrogiannopoulos-openconnect, if for no other reason than to draw a line in the sand. (We run the risk of indefinitely delaying this while adding more protocols.) On Session Cache Management, this is an explicit interface, and the example Paul mentions, while correct, does not exercise such an explicit interface. On WireGuard and PSK import, WireGuard uses the IKpsk2 Noise pattern (see URL, and URL), in which a responder uses its PSK to additionally authenticate a connection. On ESP and PSK import, we note that importing a PSK can be used for "encrypting (and authenticating) communication with a peer," which remains true for IPsec. (Right NAME I'll address the issues in 5.2 in a PR!
What makes these errors "special"? It seems a strange term to use, and the meaning is unclear.
I didn't write this, but I think it was an effort to lump together, from minset, two quite different types of errors: 1) notification of excessive retransmissions; 2) notification of icmp error message arrival. Any suggestions for a common term?
If it's just those two types of errors, we can probably just list them...
URL is what I did in minset :)
so the suggestion is to split these out into two protocol selection properties?
yes, I think so
all right then, see
lgtm
This is OK with me
S 5.2.2 says: If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. However, Section 5.2.3.4 says: If the "IceRestart" constraint is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If this constraint is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).
Yes, if this is an ICE restart, then ufrag/pwd need to change.
Discussed in DC: restart requires a change of credentials. Might want to add text that notes the dangers in doing this (i.e., don't do this).
URL supports offset time zones, e.g. . For backwards compatibility, this RFC should support them too. This PR also adds clarifying text to several time-zone-related definitions.
Makes sense. Should I start one? Yep, we added these in Temporal primarily for compatibility with prior art in URL URL In Java (and currently in Temporal) a time zone ID can either be an IANA name or an offset. The ID is an index into a set of rules ( in Java, in Temporal) for converting between exact time and local time. If the ID is an offset, there's only one trivial rule because the offset is always the same. I don't have a strong opinion about the name of offset time zones.
NAME - Let me know if you have responses to the questions in my comment above, or how you'd like me to change this PR. Thanks!
I think we still need the mailing list discussion first. If we get to a certain state of clarity by March 18, we might be able to post yet another update of the draft right before IETF week.
Sounds good. I sent mail to the mailing list. Waiting for responses.
I plan to merge this within a couple of hours, so we have a merged draft to look at in Monday's WG meeting. Since the discussion hasn't concluded yet, I'll edit the merge so it is useful for those discussions; we can edit some more after Monday's meeting.
Sounds good to me. Based on your comments here and on the mailing list, I think we're in agreement on the important points.
Hi NAME - is the merged draft available? If not, I'm happy to make the edits you and NAME suggested here in this PR, but didn't want to step on changes you're making in parallel. Let me know how I can help. Thanks!
I merged the PR and made some edits in main. I included you in the contributor list; please advise if that is OK, the information is right and whether you want to include any more contact/affiliation information.
Great! Your edits look good to me. I may follow up after the meeting with minor text clarification PRs but nothing important. Info looks right. I'm a volunteer not working on behalf of my employer so no need for additional affiliation. Thanks!
The current ABNF for the time zone extension does not support offset time zones, e.g. . These zones are supported in URL, which is the prior art driving the bracketed time zone extension format. Therefore, I'm assuming that it makes sense for the standard to also allow offsets in brackets too. Current ABNF: URL Suggested ABNF for, where is imported from RFC 3339: Example of Java usage:
Please excuse my ignorance: What is the meaning of ? We'd need some text explaining the semantics.
This format asserts that derived timestamps (e.g. add one day) should also use the offset. It's mostly for backwards compatibility with URL It's not recommended for normal use. Heres the explanatory text I added in : >
I assume that conflicts between the timestamp offset and a bracketed offset (e.g. ) should be handled the same as other conflicts, per discussion in URL
Signed-off-by: David Navarro For the reasons stated in .
Hi, OMA LwM2M is using Minimum Period (pmin) and Maximum Period (pmax) attributes. The DynLink draft has this requirement: In its version 1.0, LwM2M had a different version of this requirement in the form: Thus having pmax equal to pmin was allowed. In LwM2M 1.1 we aligned this requirement with the DynLink one, making pmin equal to pmax forbidden. However, it was that having pmin equal pmax is a valid use case if the client wants the notification to be sent exactly every N seconds. Is there a strong opinion on forbidding pmax to be equal to pmin, or are people open to changing the Dynlink requirement ? Regards
NAME After the discussion at IETF 109, I think we can agree that there are no strong opinions against allowing pmax to be greater than or equal to pmin in the draft. However in order to avoid any ambiguity in interpretation, do we want reflect the discussion so far, so that the draft has pmax == pmin, specifically for this use case, ie when this condition is met, then the CoAP server sends (is it a MUST/SHOULD/MAY?) the resource representation every N seconds? Also how does the client then cancel this request?
Closing this issue, with the draft allowing pmax to have equality to pmin