jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-perc-dtls-tunnel

Commentary: Changes for -07 of the tunnel draft include : Updated references Change status to informational Align terminology with newer UKS draft 
 LGTM 
 LGTM
Paragraph (version A):
An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure
that endpoints in a multimedia conference have access to the end-to-
end (E2E) and hop-by-hop (HBH) keying material used to encrypt and
authenticate Real-time Transport Protocol (RTP) RFC3550 packets,
while the Media Distributor has access only to the hop-by-hop (HBH)
keying material for encryption and authentication.
Paragraph (version B):
An objective of Privacy-Enhanced RTP Conferencing (PERC) RFC8871 is
to ensure that endpoints in a multimedia conference have access to
the end-to-end (E2E) and hop-by-hop (HBH) keying material used to
encrypt and authenticate Real-time Transport Protocol (RTP) RFC3550
packets, while the Media Distributor has access only to the hop-by-
hop (HBH) keying material for encryption and authentication.
Paragraph (version A):
SDP RFC4566 attribute MUST be included in SDP sent by the endpoint in
both the offer and answer RFC3264 messages as per I-D.ietf-mmusic-
dtls-sdp.
Paragraph (version B):
message when establishing a DTLS association.
Paragraph (version A):
message that advertises support for both
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double.
Paragraph (version A):
RFC Editor Note: Please replace the values 0009 and 000A in the
following two examples with whatever code points IANA assigned for
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.
Paragraph (version B):
message that advertises support for both
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM RFC8723.
Draft: draft-ietf-perc-double

Commentary: This is an important security consideration for the re - encryption case , which does n't appear to be covered by the current text . 
  could be the same , but key definitely needs to be different . Requiring both to be different is best , of course .
Paragraph (version B):
A Media Distributor that decrypts, modifies, and re-encrypts packets
in this way MUST use an independent key for each recipient, SHOULD
use an independent salt for each recipient, and MUST NOT re-encrypt
the packet using the sender's keys.  If the Media Distributor
decrypts and re-encrypts with the same key and salt, it will result
in the reuse of a (key, nonce) pair, undermining the security of GCM.
Draft: draft-ietf-perc-double

Commentary: seems reasonable to me
Paragraph (version A):
To summarize what is encrypted and authenticated, we will refer to
all the RTP fields except headers created by the sender and before
the payload as the initial envelope and the RTP payload information
with the media as the payload.  Any additional headers added by the
sender or Media Distributor are referred to as the extra envelope.
The sender uses the end-to-end key to encrypt the payload and
authenticate the payload + initial envelope, which using an AEAD
cipher results in a slight longer new payload.  Then the sender uses
the hop-by-hop key to encrypt the new payload and authenticate the
initial envelope, extra envelope and the new payload.
Paragraph (version B):
To summarize what is encrypted and authenticated, we will refer to
all the RTP fields except headers created by the sender and before
the payload as the initial envelope and the RTP payload information
with the media as the payload.  Any additional headers added by the
sender or Media Distributor are referred to as the extra envelope.
The sender uses the end-to-end key to encrypt the payload and
authenticate the payload + initial envelope, which using an AEAD
cipher results in a slight longer new payload.  Then the sender uses
the hop-by-hop key to encrypt the new payload and authenticate the
initial envelope, extra envelope and the new payload.  Also to note,
the "Associated Data" input (which excludes header extensions ) to
the inner crypto differs from RFC7714 construction.  This shouldn't
typically impact the strength of e2e integrity given the fact that
there doesn't exist header extensions defined today that needs e2e
protection.  However, if future specifications define header
extensions that needs e2e integrity protection, the input to inner
transform may be modified to consider including the header
extensions.
Paragraph (version A):
The end result is that if the authentications succeed, the receiver
knows exactly the payload and initial envelope the sender sent, as
well as exactly which modifications were made by the Media
Distributor and what extra envelope the Media Distributor sent.  The
receive does not know exactly what extra envelope the sender sent.
Paragraph (version A):
Modifications by the intermediary result in the recipient getting two
values for changed parameters (original and modified).  The recipient
will have to choose which to use; there is risk in using either that
depends on the session setup.
Paragraph (version B):
The end result is that if the authentications succeed, the receiver
knows exactly the payload and initial envelope the sender sent, as
well as exactly which modifications were made by the Media
Distributor and what extra envelope the Media Distributor sent.  The
receiver does not know exactly what extra envelope the sender sent.
Paragraph (version B):
Modifications by the intermediary results in the recipient getting
two values for changed parameters (original and modified).  The
recipient will have to choose which to use; there is risk in using
either that depends on the session setup.
Draft: draft-ietf-perc-double

Commentary: Right now , the SRTP KDF destroys the separation between the inner and outer halves of the master key , which means that EKT ca n'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
Paragraph (version B):
represents the default SRTP PRF RFC3711,
Paragraph (version B):
represents the second half of the key.
Draft: draft-ietf-perc-double

Commentary: This is not ready to merge yet but can get discussion started
Paragraph (version A):
TODO - Add text to explain how to use FlexFEC I-D.ietf-payload-
flexible-fec-scheme as described in Option A of slides presented at
IETF 99.
Paragraph (version B):
When using Flex FEC I-D.ietf-payload-flexible-fec-scheme with double,
the negotiation of double for the crypto is the out of band signaling
that indicates that the repair packets MUST use the order of
operations of SRTP followed by FEC when encrypting.  This is to
ensure that the original media is not reveled to the Media
Distributor but at the same time allow the Media Distributor to
repair media.  When encrypting a packet that contains the Flex FEC
data, which is already encrypted, it MUST be encrypted using a crypto
context with a null E2E key.
Paragraph (version B):
The algorithm recommend in I-D.ietf-rtcweb-fec for repair of video is
Flex FEC I-D.ietf-payload-flexible-fec-scheme.  Note that for
interoperability with WebRTC, I-D.ietf-rtcweb-fec recommends not
using additional FEC only m-line in SDP for the repair packets.
Draft: draft-ietf-perc-double

Commentary: 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
Paragraph (version A):
TODO - Add text to explain how to use RTX as described in Option A of
slides presented at IETF 99.
Paragraph (version B):
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.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: 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 do n't think there is anything to be done to make it clearer .
Paragraph (version B):
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.
Draft: draft-ietf-perc-double

Commentary: 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
Paragraph (version A):
The receiver can check the authentication of the initial and extra
envelope information.  This, along with the OBH, is used to construct
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.
Paragraph (version B):
The receiver can check the authentication of the initial and extra
envelope information.  This, along with the OHB, is used to construct
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.
Draft: draft-ietf-perc-double

Commentary: You ca n't think of this as  tunneled inside of SRTP . It 's not . It is SRTP done once with a crypto transform called " double " and with a single key . Double has the weird property that if you know half the key , it ends up only decrypting half the the data for you . The endpoints know the full key , the MDD only half the key , and the both the endpoints and the MMD have to do double . 
 Make sure specs are clear on this 
 wondering where size ends up 
 Which size ? 
 That aligns with what you said you preferred . It 's certainly easier to explain in words here . But , it will be more challenging for MDDs to explain . Since we are using the same cipher and the ciphertext will have a constant size , we can do in - place authenticated encryption and not destroy the EKT field in the process . So performance will not be affected on the middle box . But , we need to explain this somewhere for the media distributor . Maybe the right place to explain that is when we also show an example of the packet format . I can see that expanding to be processing rules for endpoints and the media distributor .
Paragraph (version B):
When using EKT I-D.ietf-perc-srtp-ekt-diet, the EKT Field comes after
the SRTP packet exactly like using EKT with any other SRTP transform.
Draft: draft-ietf-perc-dtls-tunnel

Commentary: This is a rebased version of from last October . 
 You want the MDD to be told " use DOUBLEAEADAES128GCMAEADAES128GCM " , when it will actually only do have of it ? 
 Another question : can we change the words " if IANA assigned " to something concrete ? That is , we just make this assumption . Then , insert a note to RFC Editor to adjust these values as necessary before publication ? 
 On MDD told to do double ... The TLS has to negotiate double or the endpoints will not do double . The endpoints can only do what is negotiated inside of TLS . Keep in mind our desing goal here is to minimize the code changes outside libsrtp to the endpoints and not worry too much about the amount of code on MDD and KDD . On IANA - yah fine with changing this to an RFC editor note to change values to whatever IANA assigned . I think we are at the point where we could have the chairs ask IANA for an early assignment to help pre standard implementations write code .
Paragraph (version A):
message that advertises support for both SRTP_AEAD_AES_128_GCM and
SRTP_AEAD_AES_256_GCM RFC7714.
Paragraph (version B):
message that advertises support for both
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double.
Paragraph (version B):
RFC Editor Note: Please replace the values 0009 and 000A in the
following two examples with whatever code points IANA assigned for
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.
Draft: draft-ietf-perc-double

Commentary: it should point at draft - ietf - perc - private - media - framework
Paragraph (version A):
more detail in more detail in I-D.jones-perc-private-media-framework.
Paragraph (version B):
more detail in more detail in I-D.ietf-perc-private-media-framework.
Paragraph (version A):
Obviously, if the Media Distributor is to be able to modify header
fields but not decrypt the payload, then it must have cryptographic
context for the outer transform, but not the inner transform.  This
document does not define how the Media Distributor should be
provisioned with this information.  One possible way to provide
keying material for the outer ("hop-by-hop") transform is to use I-
D.jones-perc-dtls-tunnel.
Paragraph (version B):
Obviously, if the Media Distributor is to be able to modify header
fields but not decrypt the payload, then it must have cryptographic
context for the outer transform, but not the inner transform.  This
document does not define how the Media Distributor should be
provisioned with this information.  One possible way to provide
keying material for the outer ("hop-by-hop") transform is to use I-
D.ietf-perc-dtls-tunnel.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: There is slight mention of i frames but they get called " intra coded video frames " 
 Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets . Maybe section 2.6 goes here . You have just said that either the FullEKTField or ShortEKTField is appended , so it seems the perfect place to say how to decide which one to append . 
 Pointing to the section looks good This is ok . I reviewed the timing section briefly , but did n't see mention of I - frame or key frame packets . That 's another good time to provide the full EKT field .
Paragraph (version A):
Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets.
Paragraph (version B):
Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets.  The decision on which to send is specified in
timing.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: This is a very substantial change . I suspect it is correct but given text in security section but think carefully about if this breaks anything . 
 Section 4 The presence of the SSRC in the EKTPlaintext ensures that an attacker can not substitute an EKTCiphertext from one SRTP stream into another SRTP stream . I do not see a step in Section 2.2.2 that performs this check . I expected to see a comparison of the decrypted SSRC to the one that is in the packet . Without such a check , we can not expect every implementation to prevent this substitution attack . 
 I think this is right .
Paragraph (version B):
If the SSRC in the EKTPlaintext does not match the SSRC of the
SRTP packet, then all the information from this EKTPlaintext MUST
be discarded and the following steps in this list are not done.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: Section 2.3 Ciphers EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext . We first specify the interface to the cipher , in order to abstract the interface away from the details of that function . We then define the cipher that is used in EKT by default . The default cipher described in Section 2.3.1 MUST be implemented , but another cipher that conforms to this interface MAY be used , in which case its use MUST be coordinated by external means ( e.g. , key management ) . The SPI tells which cipher is being used , so I do not understand the second MUST in the sentence . Key management needs to put the key in place regardless of the algorithm in play . 
 Fixed by
Paragraph (version A):
EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext.  We first specify the interface to the cipher, in order
to abstract the interface away from the details of that function.  We
then define the cipher that is used in EKT by default.  The default
cipher described in DefaultCipher MUST be implemented, but another
cipher that conforms to this interface MAY be used, in which case its
use MUST be coordinated by external means (e.g., key management).
Paragraph (version B):
EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext.  This specification defines the interface to the
cipher, in order to abstract the interface away from the details of
that function.  This specification also defines the default cipher
that is used in EKT.  The default cipher described in DefaultCipher
MUST be implemented, but another cipher that conforms to this
interface MAY be used.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: Inbound Processing When receiving a packet on a RTP stream where EKT was negotiated , the following steps are applied for each received packet . Will an implementation ever be doing SRTP with EKT with some sessions and  without EKT for other sessions at the same time ? If so , how does the inbound processing determine whether an EKT is present or not ? Is an additional step needed to perform " normal SRTP or SRTCP processing " on packets without EKT ? 
 I do n't think you can ever receive non EKT packets on a flow with EKT negotiated . That is to say know from the SDP when you get a SRTP packet if it is EKT or not 
 Use of EKT must be negotiated in signalling on a per session basis . In the case of PERC , all multiplexed flows must use EKT . For WebRTC , that should also be true , unless a determination can be made based on the payload type . That actually raises a question . How are PERC endpoints supposed to construct the SDP for PERC that indicates use of DTLS ? Is that going to be in  's draft ? PERC endpoints are always required to initiate the DTLS association . 
 Framework and Signaling draft should sum up the usage of this . 
 More reason to delay framework until we know we 've covered everything . 
 Framework is not getting published anytime soon . We have time :)
Paragraph (version A):
When receiving a packet on a RTP stream where EKT was negotiated, the
following steps are applied for each received packet.
Paragraph (version B):
When receiving a packet on a RTP stream, the following steps are
applied for each received packet.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: EKTMsgLength All EKT message other that ShortEKTField must have a length as 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 . This " must " statement is really a requirement on the person that will specify other EKT messages . Is there a better place to state This requirement ?
Paragraph (version A):
All EKT message other that ShortEKTField MUST have a length as
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.
Paragraph (version B):
All EKT message other that ShortEKTField have a length as 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.
Paragraph (version B):
All new EKT messages MUST be defined to have a length as second from
the last element.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: Section 2 ( para 2 ) EKT MUST NOT be used in conjunction with SRTP 's  ( Master Key Identifier ) or with  's < From , To[RFC3711 ] , as those SRTP features duplicate some of the functions of EKT . Do you expect implementations to check for this MUST NOT ? If so , what should the recipient do if the sender does use EKT in conjunction with SRTP 's MKI or with  's < From , To ? Same issue has be raised by Spt What happens if an implementation does use SRTP 's MKI or with  's < From , To ? Is an error thrown ? 
 I do expect they 'd check , because they have to know how to parse the packet and where to insert the EKT field . With EKT , the key to use is conveyed via the RTP packet . Only after the EKT field is parsed would it make sense to look to find an MKI value . In any case , if MKI is used it 's just redundant . One thing I did n't see in reviewing the current specs is where the EKT field should be inserted . It should be inserted on the inner encryption step of double . The outer encryption is consumed by intermediaries and they do n't understand EKT . We probably need to put that back into the framework document . The packet format was removed during one revision . 
 opened new bug for where EKT goes
Paragraph (version A):
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> RFC3711, as those SRTP features
duplicate some of the functions of EKT.
Paragraph (version B):
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> RFC3711, as those SRTP features
duplicate some of the functions of EKT.  Senders MUST not include MKI
when using EKT.  Receivers SHOULD simply ignore any MKI field
received if EKT is in use.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: s2.1 , EKTPlaintext Probably over thinking this , but is the concatentation like so : + --------------+--------+--------+ + -------------+---------+--------+ I ’d be afraid somebody would think it ’s the other way around without being more specific . Maybe it ’s as easy as : putting something like " SRTP MK denotes concatenation ” s omewhere in the paragraph .
Paragraph (version A):
The following shows the syntax of the EKTField expressed in ABNF
RFC5234.  The EKTField is added to the end of an SRTP or SRTCP
packet.  The EKTCiphertext is computed by encrypting the EKTPlaintext
using the EKTKey.  Future extensions to the EKTField MUST conform to
the syntax of ExtensionEKTField.
Paragraph (version B):
The following shows the syntax of the EKTField expressed in ABNF
RFC5234.  The EKTField is added to the end of an SRTP or SRTCP
packet.  The EKTPlaintext is the concatenation of
SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The
EKTCiphertext is computed by encrypting the EKTPlaintext using the
EKTKey.  Future extensions to the EKTField MUST conform to the syntax
of ExtensionEKTField.