jiebi/CodeConvo huggingface dataset:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.
I think that the hash/auth tag list should be better moved at the end of the frame after the auth tag to make it easier to apply the encryption and generating the auth tag without having to reconstruct the frame to insert the signature in the middle of it. So, my new proposal would be first to generate the frame header with the s bit = 1, append the payload, encrypt the frame and add the auth tag as normal: Then append the tags before that frame at the end and the number of auth tags without the current frame one Then calculate the signature of the auth tags in reverse order: And then append the Signature at the end of the frame: When the receiver gets the frame, it will also be able to reuse the buffer to calculate the Signature without having to move momory around. In case it is not secure to use the auth tags, it would be still be similar: The receiver would have to generate the Hash of the frame up to the Auth tag, and then calculate the signature with the rest of the hashes on the list.
Adding Signature at the end will mean adding a new offset field to point to where the Signature block start as it will be a variable length block (depends how many hashes it has), where if it was put at the beginning, we won't need to add an offset field.I think doing signature over the auth tag is fineYou are right about the startFrameIndex, it won't be enough. What about having startFrameIndex 4 bytes or whatever, then having one byte frameOffset for every other hash to get the frameindex by using this offset from the start index, assuming 255 is enough range. I just don't want to add full length frameId for every hash
didn't you said that: Why is it fixed if it is at the beginning, but variable if it is in the end? why do we need the at all? The receiver would just need to have an ordered map of the pending to be verified authentication tags and remove them when they signature for each is received. The receiver should have also a verification timeout and if a signature is not received for that tag in time, it would be considered as failed.
Ok, I see, ECDSA signatures are ASN1 encoded objects, so the length can be derived by parsing it from the start bite. Is that correct?
I have made a new tentative approach with my comments above. What do you think?
Sorry I should have been more clear The signature itself is fixed length (ex 64 bytes for ed25519) but The entire signature block will be variable depends on the number of signature, unless you want to make this number fixed (ex always 50 hashes)We need frameIndex so the recipient know which hashes to use to verify the signature, we can't just relay on an ordered list of all previous hashes because the signature block could have hashes of missing frames, or even the signature packet could be lost itself
What is a signature block? What is the difference between the signature and the signature block? That should be covered by my proposal.
signature = sign(data) Signature block is what I referred to on my drawing as signature header+ signature + hash list
If I understood your proposal correctly, you are sending the whole list of hashes so the receiver can recreate the if any of them is missing. So you don't really don't need the index of each frame, as you there should be (almost) a 1-to-1 mapping between the hashes/auth tag and the frame index (how probable is to have a hash or auth tag collision?). So, given the hash/auth tag list, the receiver could derive the frame index of it (by keeping an internal map)
I think that's good for now. My initial thought was to have the sender chose the packet to sign, they can be different number each time, also they might chose not ti sign every packet, for example random X packets every Y seconds. Anyway, we can always improve later, your proposal is good to start with
This should be also possible with current approach, right? Have you seen any reason that it couldn't be done?
In the draft it says that: >when the signature is sent, it will also send all the hashes it used to calculate the signature How is the bitstream format of the signature+hashes, also how is the signature added to the frame (after the auth tag?) and how is the presence of the signature in a frame signaled?
How about something like this for the signature format? The signature is appended after the block if the bit of the SFrame header is 1. The first byte (SLEN) is the length of the signature data . After the signature there will be 1 or more blocks of HMACs.
A they can be off different size, each HMAC block will have 1 byte header with HNUM (4 bits) indicating the number of HMACs present and HLEN(4 bits) to indicate the size in bytes of each HMAC. To indicate the end of the HMACS blocks an HMAC header block with HNUM=0 and HLEN=0 will be inserted.
One question, what are the sizes of the HMACs? I have considered the ones for AES which are 4 and 8, but in GCM are bigger, right? Are they required to be even or a power of 2? we could do either length=2^(HLEN+1) or LEN=2(HLEN+2) in that case.
I don't think they have to be 2*n. SHA-256 is, of course, but SHA-384 isn't
Currently it says that: However, if using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. In that case, the receiver will never get a full frame and be able to check the signature. Which will render it a kind of useless feature. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph).
This is a good point and suggests 'frame' really refers to each independently decodable unit.
I think I mixed two things on this issue and my original comment is not totally accurate. The signature will contain the HMAC of all the frames it contains, so if any of them is dropped, the receiver can still compute the signature of the received ones. However, if the signature is not sent on the base layer, then it can be dropped by the SFU. I think it still makes sense to send different signatures over different layers to avoid having to send data on the wire that will be dropped by the SFU.
A static key should not be used both for X25519 and Ed25519. This PR corresponds to .
Please review the proposed change.
The standard does not restrict private key usages. In particular, it could be tempting to use the public/private keys for the ed25519 signature scheme as a public and private key pair for the static authentication mode with the elliptic curve X25519. This does not have clear direct and practical implications. However, this usage falls outside the existing cryptanalysis for the signature scheme, and is a bad practice from a theoretical point of view. This would require a dedicated cryptographic analysis, similar to [2]. [1, Section 12] typically recommends that different keys are used for different algorithms, but it may be unclear if the EDHOC use case falls under this recommandation, or if an extra one could be pertinent. We recommend to mention this issue somewhere in the standard, or explicitly forbid such a shared key usage. [1]: URL [2]: URL On using the same key pair for Ed25519 and an X25519 based KEM. Erik Thormarker.
I've seen single keys used for both ed25519 and x25519 during plugtests; IIUC the agreement among the plugtesters back then was that this was not intended use and should generally not be done. This might serve as a data point that illustrates the need for a clear statement.
Mentioning this issue and refering to [1, Section 12] seems like a good idea. The text would need to mention EDHOC methods as [1, Section 12] only talks about algorithms and the ECDHE in EDHOC is not strictly a COSE algorithm. Writing that using the same key requires a dedicated cryptographic analysis, similar to [2] also seems like a good idea. (As a comparision, I don't think TLS 1.3 states anything about forbidding the public key in the certificate to be used for Elgamal, ECIES, or ECDHE outside of TLS).
Should we propose a PR for this?
NAME Please go ahead. Prepare for the option to have a reference to an analysis showing this is secure under certain conditions.
Addressing issue raised by Martin at URL
Should the server reject the ClientHello if it appears as though the client is responding to a HelloVerifyRequest? What if it also contains a cookie extension?
I don't think the server should reject a ClientHello if it thinks the Client should provide a cookie previously sent with the HelloVerifyRequest. This would require the server to keep state and to implement more complex logic in the server-side. If the ClientHello contains a cookie in the ClientHello.legacycookie field in the DTLS 1.3 field then IMHO an "illegalparameter" alert has to be sent. I created a PR to add a note about this: URL There is, however, the question why whether we should omit some of the legacy fields for use with DTLS 1.3 (not in the ClientHello because it would be needed for backwards compatibility) but for the ServerHello/HelloRetryRequest.
Fixed
Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps?
LGTM
If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. I note that there can be difference here between an offer and an answer if the RTCP mux indication may have changed or not between these two description.
Agreed. If we offered rtcp-mux, but it wasn't accepted, the next offer would be without mux. It should only be an error if we accepted mux and already discarded the RTCP ICE component.
I'm not sure if this is actually necessary, but there usually seem to be issues in Merkle trees when the leaves are not explicitly distinct from the parents.
I would find it nicer to describe things with a like in other parts of the protocol: It is equivalent to your modification. Stating things that way ensures there is no ambiguity: TreeHashInput is parseable, which is I think the property you want to ensure with this PR.
Use enum instead and then ready for merge.
Interim 2022-05-26: Nicer with an NAME to update to , then merge
When computing the tree hash, should there be an indicator bit for whether the value being hashed represents a leaf or parent node?
This doesn't seem like a terrible idea. You could either add a field to LeafNodeHashInput and ParentNodeHashInput, or define an enum and do the same, or make a . For example:
Specifically: Specify use of the "one-shot" HPKE APIs defined in RFC9180, replacing equivalent use of the "multi-shot" APIs. (This change is intended to be a clarification, not a functional change.) Move the task_id parameter from the "info" parameter to the "aad" parameter. This is intended to protect against key-commitment-related attacks[1]. (This is a functional change.) Clarify that the URL field is an encapsulated key, rather than an encryption context. (This is a clarification, not a functional change.) [1] See discussion in URL
Per URL section 8.1: PPM effectively uses the single-shot APIs; we should consider refactoring PPM's usage of HPKE to use only one of applicationinfo & AAD. Following the advice of the HPKE RFC, we would want to use applicationinfo. This would permit slightly simpler implementations. I am not sure how much it would simplify the HPKE computations.
Should we then formally use the single shot HPKE APIs from ?
That would be my recommendation (though, somewhat confusingly given the advice quoted above, those APIs still allow specifying both application info & AAD). Implementations can & do already use the single-shot APIs, so I strongly suspect specifying the single-shot APIs will be feasible. & .]
+1 to using single-shot APIs, though I'm not sure I agree that using either info or add (but not both) is simpler. What's the reasoning?
The reasoning is: a) it follows the advice of the HPKE spec (quoted above) b) AFAICT, in a single-shot setting, application info & AAD serve exactly the same purpose, so using both is arbitrary/confusing/a potential source of mistakes. (in a multi-shot setting, application info is bound to all encryptions/decryptions done by the same context; AAD is bound to a single encryption/decryption)
TBH I'm not sure I agree with the quoted guidance here. There is a concept in protocol design known as "domain separation", the goal of which is to provide some kind of binding of long-term secret key operations to the context in which they were used. Imagine, for example, that someone used an HPKE secret key for PPM and some other protocol. Suppose further that both are using the empty string for .
Then the security of our PPM deployment depends on how the other protocol uses the derived AEAD key, since in both protocols may end up deriving the same AEAD key. One way to avoid creating this attack surface is to pick an string that no other application is likely to choose so that derived keys are guaranteed to not collide (except with some negligible probability). That said, I'd go for changing how we use and . Something like this might be simpler: Let be a fixed string that identifies the protocol. It would be good if this string were relatively long, say the SHA-256 hash of "ppm-00". Let encode the task ID, sender/receiver roles, etc.
I definitely agree that application info should include information allowing domain separation, for the reasons you mention. (Indeed, the current PPM spec includes the strings "ppm input share" or "ppm aggregate share" in its application infos, presumably for this purpose.) But I think that's orthogonal to the question of whether we should also use AAD, since the application info could also include information other than the "domain separation parameter". Picking one example to make things concrete, a client upload request sets its application info to and its AAD to . But it could just as easily set the application info to (i.e. the concatenation of the two previous strings) and not use AAD. (Or alternatively, it could place that string in the AAD and not use application info.) My argument is that it's simpler to use only one of the parameters, since in the single-shot setting that PPM is using HPKE, the two parameters serve exactly the same purpose (i.e. including additionally-authenticated data).
As I see it, our goal is to make sure that decryption only succeeds if the sender and receiver agree on the "context", i.e., the task ID, sender/receiver role, nonce, extensions, and so on. This way a MITM cannot force the aggregator to interpret an input share incorrectly. Does this sound reasonable to you? From the point of view of this threat model, I don't think it's immediately clear that sticking the context in or is equivalent.
For example, if we stuff the context in , then it influences the derivation of the AEAD key; but depending on the AEAD, it might be feasible for an attacker to find a find two keys that decrypt the same ciphertext. (See URL) More analysis will be needed to say for sure whether this weakness in the AEAD amounts to an attack against our protocol. In the meantime, sticking the "context" in seems like a more conservative choice to me.
Given your concern, your approach SGTM. It sounds like this may be a concern worth raising with the folks working on the HPKE spec, given the advice to "use the Setup info parameter for specifying auxiliary authenticated information", but I'm not going to chase this down currently.
So I think there's two tasks for this issue: Move task ID from to Use single-shot APIs for HPKE Anything else?
Yep, I think that's it.
(reopening for now as the fix PR has been reverted temporarily)
Perfect, great work!
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).
From "Opsdir last call review of draft-ietf-rtcweb-jsep-21" A minor observation, not even a nit, is that the text in the Security Considerations "While formally the JSEP interface is an API, it is better to think of it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint. " could be more clear.
I have no idea what to do with this. Obviously I thought it was clear when wrote it, and still do.
This is the only place in the document where we use "JS". I think it would be good to spell out "JavaScript", and potentially use "application JavaScript" in the first usage. Finally, I think we should use "implementation" rather than "endpoint" in this para.
LGTM
Right now, we only allow authenticated and matching-IP opportunistic use of the DDR record. While use of the record in a case where authentication fails isn't safe to use automatically, we should clarify that implementations MAY choose to use the information anyhow by policy, and possibly with user control.
For authentication to matter, it generally has to operate without fallback. Currently the text is not very clear on this point, but it sure seems like IP-authenticated mode is expected to fall back to cleartext if no upgrade is possible. I think we need to clarify the use case for an authenticated mode, or abandon the distinction between opportunistic and authenticated. In my view, authenticated mode only makes sense if (1) the resolver is identified by its IP address AND (2) the system knows a priori that this resolver supports encrypted DNS, so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker. This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names (Section 5) or opportunistic instead.
Currently, this is what we say (which I now see a grammatical error in, but there it is): We don't say anything else because that would be out of WG scope. The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS. The stub resolver's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business. Look at this through a common OS scenario: the OS stub resolver learns an IP address from DHCP, and it's a public IP address (my old ISP did this). It knows of no other resolvers because the user doesn't know what DNS is and that's the default configuration (use network recommendation). If I try to use DDR and I get no answer back, then I'm in the same position as I was before DDR: I know of no other resolver, so I either have to use this one or have no DNS resolutions. DDR did not introduce that conundrum; it offers clients a way out of it when DNR is not present and there is no plain-text DNS attack present. The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text.