jiebi/CodeConvo huggingface dataset:
Change:
So far, it was used 1x in abbreviated form, and 2x as "CWT Claims Sets (CCS)". The abbreviation was problematic the way it was used while being a reference into RFC8392, it was not defined there. I'm not 100% happy with dropping the term "CCS" because it having an abbreviation is a good pointer for users to see that this is an established, good and compact thing to use (right?), but I'd rather spare readers the confusion of clicking through to 8392 and not finding the letters "CCS". I'd be happy with any better handling of the possible confusion, this is just the best I'm coming up with.

Discussion:
Authentication credential: set of information associated with an entity, including that entity's public key and parameters associated with the public key.  Examples of authentication <del> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) </del> <ins> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets </ins> RFC8392, X.509 certificates RFC7925 and C509 certificates I- D.ietf-cose-cbor-encoded-cert.  Further details about authentication credentials are provided in sec-pub-key-format.

"subjectPublicKeyAlgorithm" element, respectively. If authentication credentials are CBOR Web Tokens (CWTs) or CWT <del> Claims Sets (CCSs) RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </del> <ins> Claims Sets RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </ins> Authentication credentials are used to derive pairwise keys (see key- derivation-pairwise) and are included in the external additional

For example, an X.509 certificate is provided as its direct binary serialization.  If C509 certificates or CWTs are used as authentication credentials, each is provided as the binary <del> serialization of a (possibly tagged) CBOR array.  If CCSs are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </del> <ins> serialization of a (possibly tagged) CBOR array.  If CWT Claims Sets are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </ins> If authentication credentials are CWTs, then the untagged CWT associated with an entity is stored in the Security Context and used
Change:
Not a grave issue, but it's a leak of information that can be reduced to leaking unexpected reboots vs. leaking any reboot by being aware of it.
Thanks NAME , I am just confused by the term "clean shutdown" here. What do you mean by that? If I understand correctly the rest of your text, you are suggesting that to avoid leaking information about accidental reboots, the device keeps track of the node's state constantly, so that when an accidental reboot happens, the node can re-instate the right seq. When does clean shutdown come into the picture?
Typical devices can not tolerate the flash wear of writing the sequence number state on any package transmission (that's why there's the "Seq + K" part in 6.3.1), and that limitation won't go away just because it has privacy consequences. Accidental reboots will thus be leaked, but deliberate ones can be hidden by storing the fine-grained seqno state on flash. For example: Initial boot, everything is 0 Before sending package 1, write "seqno=1000" Send 999 more packages w/o writing Before sending package 1001, write "seqno=2000" Send some more packages w/o writing Zap, reboot! Before sending seqno 2001, write "seqno=3000" (this is a hard to prevent leak) Send 49 more packages Shutdown requested, write "seqno=2050" Reboot Before sending seqno=2051, write "seqno=3050" (no reboot leaked)

Discussion:
ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. <ins> Using the mechanisms described in seqno-replay-state reveals when a device goes through a reboot.  This can be mitigated by the device storing the precise state of sender sequence number and recipient replay window on a clean shutdown. </ins> 12. Note to RFC Editor: Please replace all occurrences of "[[this
Change:
This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value. The text about kid being the last field is a draft, please modify if you have any better formulation.

Discussion:
option is critical, safe to forward, part of the cache key, and not repeatable. <del> The Object-Security option contains the OSCORE flag byte and for requests, the Sender ID (see compression).  If the flag byte is all zero (0x00) the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </del> <ins> The Object-Security option contains the OSCORE flag byte, the Sender Sequence Number and the Sender ID when present, (see compression). If the flag byte is all zero (0x00) and no other fields are present, the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </ins> A successful response to a request with the Object-Security option SHALL contain the Object-Security option.  Whether error responses

8.1. The value of the Object-Security option SHALL contain the OSCORE flag <del> byte and the kid parameter as follows: </del> <ins> byte, the Partial IV parameter, the Context Hint parameter (length and value), and the kid parameter as follows: </ins> The first byte (= the OSCORE flag byte) encodes a set of flags and the length of the Partial IV parameter. <del> The three least significant bits, n, encode the Partial IV length.  If n = 0 then the Partial IV is not present in the </del> <ins> The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the </ins> compressed COSE object.  The values n = 6 and n = 7 is reserved.

The sixth-eighth least significant bits are reserved and SHALL be set to zero when not in use. <ins> The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint) s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). </ins> The remaining bytes encode the value of the kid, if the kid is present (k = 1) <ins> Note that the kid MUST be the last field of the object-security value, even in case reserved bits are used and additional fields are added to it. </ins> The presence of Partial IV and kid in requests and responses is specified in cose-object, and summarized in fig-byte-flag. 8.2. <del> The payload of the OSCORE message SHALL be encoded as follows: The first n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint), s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). The remaining bytes encode the ciphertext. </del> <ins> The payload of the OSCORE message SHALL encode the ciphertext. </ins> 8.3.
Change:
As suggested in
Need to update example as well
Not on expert on HTPP header formats, but are single quotes '' correct? I think I have only seen double quotes "" in HTTP.
should be fixed now
"The value of the payload" It is called body in HTTP
Jim suggested to not have an empty HTTP header (legal but likely to create problems), instead use: ""

Discussion:
The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security <del> in the mapped request or response.  The value of the field is the value of the Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding).  The value of the payload is the OSCORE payload oscore-payl, also base64url-encoded without padding. </del> <ins> in the mapped request or response.  The value of the field is: "" (empty string) if the CoAP Object-Security option is empty, or the value of the CoAP Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding). The value of the body is the OSCORE payload oscore-payl. </ins> Example:
Change:
I believe this is about the minimum change that we can make to avoid the need for a normative reference to draft-ietf-cbor-cddl, which might hold up the document in the RFC editor queue.
Thank you NAME the only thing I can think of is adding a reference to CBOR in the appendix too, but that's it.

Discussion:
Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE <del> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl, and constrained environments RFC7228. </del> <ins> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl as summarized in cddl- sum, and constrained environments RFC7228. </ins> The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or
Change:
This should fix issue
As per Christian Amsüss' message from 2017-01-04 we should clarify how we expect implementers to map sequence numbers to partial IV's. I think that network-byte order is a good way.

Discussion:
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the <del> Partial IV (Sequence Number) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </del> <ins> Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </ins> Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the

Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV) <del> with the Sender Sequence Number (partial IV). </del> <ins> with the Sender Sequence Number in network byte order (partial IV). </ins> If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)
Change:
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.

Discussion:
length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. <del> If the OHB is one octet in length, it contains both the original X bit and PT field value.  In this case, the OHB has this form: </del> <ins> If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt. </ins> If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: <del> If the OHB is three octets in length, it contains the original X bit, PT field value, and RTP packet sequence number.  In this case, the OHB has this form: </del> <ins> If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: </ins> If an MDD modifies an original RTP header value, the MDD MUST include <del> the OHB extension to reflect the changed value.  If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </del> <ins> the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present. If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB. To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </ins> 5.
Change:
Make sure double can work with future FEC schemes that do HBH repair and have state that could be corrupted by non authenticated packets
resolved in latest draft

Discussion:
typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra <del> envelope information.  This, along with the OBH, is used to construct </del> <ins> envelope information.  This, along with the OHB, is used to construct </ins> a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.
Change:
EKT draft should make a clear naming difference between the message form TLS server / client and the the thing that goes at end of RTP packet Also clear up figure 5. First packets go to KD, last several packets go elsewhere
The PR fixes the figure. I looked at the naming and I don't think there is anything to be done to make it clearer.

Discussion:
The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. <ins> Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the oter packets will be relayed by the Media Distributor to the Key Distributor. </ins> 5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
Change:
This is not ready to merge yet but can be used to start discussion on RTX text
Higher level question .. Should it help having a generic repair processing section that identifies the sender and receiver behavior. It could be informative and can reflect the pictures from the presentation. Thoughts ?
I think as confusing as the whole topic is/was to us experts I think we should have a paragraph explaining that any of the repairs are effectively a triple encryption.
looks good

Discussion:
7.1. <del> TODO - Add text to explain how to use RTX as described in Option A of slides presented at IETF 99. </del> <ins> When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be encrypted using a crypto context with a null E2E key. </ins> 7.2.
Change:
Right now, the SRTP KDF destroys the separation between the inner and outer halves of the master key, which means that EKT can't set the E2E key without also resetting the HBH key. This PR moves from the default SRTP KDF to use a "split PRF" that preserves the separation between the E2E and HBH halves of the key.
LGTM

Discussion:
provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel. <ins> 3.1. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following PRF, which preserves the separation between the two halves of the key: Here represents the default SRTP PRF RFC3711, represents the first half of the key, and represents the second half of the key. </ins> 4. The Original Header Block (OHB) contains the original values of any
Change:
Should be in EKTkey not where it is. Should have text that when grt new KEK, need to wait X then start using new SRTP master key

Discussion:
6. <ins> 6.1. </ins> TODO IANA registry for Message Type <ins> 6.2. </ins> TODO IANA registry EKT ciphers. <del> 6.1. </del> <ins> 6.3. </ins> IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer

Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". <del> 6.2. </del> <ins> 6.4. </ins> IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer
Change:
Fixed typos/deleted extra words in the Conf Id section.
LGTMlooks good.

Discussion:
5.3. <del> The Key Distributor needs to know what endpoints are to being added to in a given conference resource.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </del> <ins> The Key Distributor needs to know what endpoints are being added to a given conference.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </ins> 6.
Change:
Ignoring my concern and bias over extensibility with EKT :), this looks fine.
Should the registries be part of the SDP or RTP parameters group? I.e., collected together with the other SDP parameters?

Discussion:
5.1. <del> IANA is requested to create a new registry for "EKT Messages Types". The initial values in this registry are: </del> <ins> IANA is requested to create a new table for "EKT Messages Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry.  The initial values in this registry are: </ins> Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification.

5.2. <del> IANA is requested to create a new registry for "EKT Ciphers".  The </del> <ins> IANA is requested to create a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry.  The </ins> initial values in this registry are: Note to RFC Editor: Please replace RFCAAAA with the RFC number for
Change:
If anyone has ideas on how to write this is a more clear way, love any suggestions ...
s2.1, MessageType Maybe it’s late but I’m having trouble parsing this sentence: Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. Can “and is not implemented” be dropped?

Discussion:
The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField <del> format.  Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. </del> <ins> format.  Values less than 64 are mandatory to understand while other values are optional to understand.  A receiver SHOULD discard the whole EKTField if it contains any message type value that is less than 64 and that is not understood.  Message type values that are 64 or greater but not implemented or understood can simply be ignored. </ins> 2.2.
Change:
s2.1, EKTMsgLength Should this be “MUST”: All EKT message other that ShortEKTField must have ...

Discussion:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. <del> All EKT message other that ShortEKTField must have a length as </del> <ins> All EKT message other that ShortEKTField MUST have a length as </ins> second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.
Change:
Does this way of phrasing it look better ?
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.

Discussion:
When an SRTP or SRTCP packet contains a ShortEKTField, the ShortEKTField is removed from the packet then normal SRTP or SRTCP processing occurs.  If the packet contains a FullEKTField, then <del> processing continues as described below. </del> <ins> processing continues as described below.  The reason for using the last byte of the packet to indicate the type is that the length of the SRTP or SRTCP part is not known until the decryption has occurred.  At this point in the processing, there is no easy way to know where the EKT field would start.  However, the whole UDP packet has been received so instead of the starting at the front of the packet, the parsing works backwards off the end of the packet and thus the type is put at the very end of the packet. </ins> The Security Parameter Index (SPI) field is used to find which EKT parameter set to be used when processing the packet.  If there is
Change:
Changed reference to Tunnel and added an (interim) reference to Roach's PERC signaling draft
Added the actual reference to ietf-roach-perc-webrtc in the body.
LGTM

Discussion:
Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized.  Trusted endpoint authorization is described in the (add ref to new signaling draft here). </del> <ins> authorized.  Trusted endpoint authorization is described in WebRTC Signaling for PERC I-D.ietf-roach-perc-webrtc. </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects

between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media Distributor which will then forward them to the Key Distributor as <del> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I- </del> <ins> defined in I-D.draft-ietf-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I- </ins> D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media

4.5.1. <del> The procedures defined in DTLS Tunnel for PERC I-D.jones-perc-dtls- tunnel establish one or more TLS tunnels between the Media </del> <ins> The procedures defined in DTLS Tunnel for PERC I-D.draft-ietf-perc- dtls-tunnel establish one or more TLS tunnels between the Media </ins> Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each endpoint and the Key Distributor as shown

given conference.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as <del> defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </del> <ins> defined in I-D.draft-ietf-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </ins> 6.