jiebi/CodeConvo huggingface dataset:
Change:
difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. <del> Clients MUST NOT include identifying information in the request that is encrypted.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </del> Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the <del> Oblivious Relay resource.  However, clients need to ensure that they construct requests without any information gained from previous requests.  Otherwise, the server might be able to use that information to link requests.  Cookies COOKIES are the most obvious feature that MUST NOT be used by clients.  However, clients need to include all information learned from requests, which could include the identity of resources. </del> <ins> Oblivious Relay resource.  However, the content of requests might be used by a server to correlate requests.  Cookies COOKIES are the most obvious feature that might be used to correlate requests, but any identity information and authentication credentials might have the same effect.  Clients also need to treat information learned from responses with similar care when constructing subsequent requests, which includes the identity of resources. </ins> Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not

Discussion:
Not even once, down from two. Using cookies is dumb, but we don't need to ban them so directly. There are tons of ways in which information from a previous request might leak across into the current one. The point is to highlight the risk of using them. A direct prohibition doesn't make sense if the use of the cookie is well understood (not that attaining such an understanding is likely to be easy).
In Section 6.1, the document states twice, in the space of two paragraphs, that clients MUST NOT use cookies. That seems a little excessive.
I'm OK with this relaxation. Clients who want to use OHTTP will presumably not do the dumb thing.
Change:
RFC7515 object is created as follows: The JOSE header MUST contain the "kid" parameter of the key bound to <del> this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </del> <ins> this signer for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by "kid" and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following additional parameters.

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use
Change:
detected and used according to their own specifications and can be used with the lookup interface as with any other resource. <ins> When resource observation is used, the following convention MUST be followed: When /rd-lookup/res does not exist, the response code 4.04 (Not Found) is returned and the request is not registered. When rd-lookup/res exists, the request is registered in the list of subjects and observers. When none of the links matches the filter, an empty payload with response code 2.03 (Valid) is returned. In all other cases, the set of matching links is returned in the payload with response code 2.05 (Content). Every time, the set of matching links changes, or the content of a matching link changes, the RD sends a notification with the matching link set. </ins> The lookup interface is specified as follows: Client -> RD

Discussion:
Unless takes a very surprising turn, I suggest reverting this: /rd-lookup/res (assuming it was discovered) always exists 2.03 is the wrong code this prescribes things already following from general observation Not reverting it yet awaiting the closure of .
chrysn schreef op 2018-01-31 12:26: Peter
Change:
silently disable the new feature.  By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. <ins> If an implementation does not select GREASE values at random it is possible it will allow for fingerprinting of the implementation or perhaps even of individual users.  This can result in a negative impact to a user's privacy. </ins>

Discussion:
Adding security considerations for fingerprinting.
This change is to address
NAME if you fix this nit up then NAME can merge and we can WGLC this draft.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
Change:
Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. <del> 15.4. </del> <ins> 16.4. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized

Discussion:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.
Change:
is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_3 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". <del> RFC3264 requires that the <sess-id> be representable as a 64-bit signed integer.  It is RECOMMENDED that the <sess-id> be generated as a 64-bit quantity with the high bit being sent to zero and the remaining 63 bits being cryptographically random.  The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </del> <ins> The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used

Discussion:
Not sure this is correct yet. Have a read of text in bugs.
The fourth sentence of the second bullet of section 5.2.1 is confusing. (It starts "It is RECOMMENDED that the ".) RFC3265 requires the initial sess-id high-order bit to be zero. As written, this can be read to say that setting that bit to zero is only RECOMMENDED, and that it's possible to have sess-ids that are something other than 64 bits. You mean to say "Do what 3265 says to do and make the lower 63 bits random". Here's one possible replacement for the sentence: "RFC 3265 requires that the high-order bit of the initial be zero. It is RECOMMENDED that the remaining 63 bits be initially set to a cryptographically random value."
Yes, this is a reasonable change.
The text from 3264 is The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (262)-1, to avoid rollovers. My read of this is the two high order bits need to be zero
Is there some other SDP formatting that requires this number to be positive ?
LGTM
Change:
m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del> <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same. </ins> 5.3.3.

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints. </del> <ins> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

Discussion:
Also restructured the "rejecting media descriptions" sections since there are now four things that can cause it to be rejected.
I think this does a good job clarifying these edge cases and is the behavior we want.
lgtm
LGTM
I just realized this may not be complete. Even if max-bundle is used, shouldn't one media description be accepted? This would ensure the same result regardless of whether the max-bundle endpoint is the offerer or answerer. It would also prevent a remote offer from being rejected if it didn't include a "BUNDLE" group simply because there was only one media description.
Deficiencies should be addressed by this PR (apologies for missing them on the first pass): URL
Change:
8. An agent MAY restart ICE processing for an existing media stream.  An <del> ICE restart, as the name implies, will cause all previous states of ICE processing to be flushed and checks to start anew.  The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair. </del> <ins> ICE restart will cause all previous states, excluding the roles of the agents, of ICE processing to be flushed and checks to start anew. The only difference between an ICE restart and a brand new media session is that during the restart media can continue to be sent to the previously validated pair, and that a new media session always requires the roles to be determined. </ins> An agent MUST restart ICE for a media stream if:

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] <ins> This declaration indicates that the receiver is capable of decoding any image resolution from 16x16 up to 640x360 pixels. </ins> 3.5.2. RFC6236 defines "a=imageattr" to be an advisory field.  This means

Discussion:
LGTM
C. Section 3.6.1: As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p. In this case, the implemention would generate this attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Maybe this example should discuss the minimal aspect of this. What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side. No limitations to any picture aspect ratio. That the examples expresses this is missing in the example text.
I think this is a realistic example, so I suggest we just add more descriptive text.
Change:
in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> A direction attribute which is the same as that of the associated transceiver. </del> <ins> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,

Discussion:
Also, fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section.
Not clear whether this should be an example, i.e., in the Examples section, or perhaps just an aside in the setDirection section.
Change:
connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST <del> use the IP address as the URI host for DoH requests. </del> <ins> use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests. </ins> Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to

Discussion:
In 6.3 we say: "When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests." There are multiple IP addresses that may be in-play here. We should clarify which is "the IP address" in the case where the Designated Resolver and the Unencrypted Resolver do NOT share an IP. (I take it that this is the IP of the Unencrypted Resolver ?)
Good point!
LGTM
Change:
Subject Alternate Name Extension by RFC 5280 RFC5280.  An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix <del> in the authorization identifier value. </del> <ins> in the authorization identifier value.  The returned authorization MUST include the optional "wildcard" field, with a value of true. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents of

Discussion:
requests are allowed to send DNS type identifiers with a value that contains a wildcard prefix ('') as the leftmost label. The authorization object created for the wildcard identifiers in the requests are not allowed to carry the wildcard prefix in the authorization identifier per spec language: This is sensible because the authorization is not for the logical wildcard but for the specific base domain. This leaves an ambiguous situation for client developers/users. Imagine a situation where a user requests a new order with the following request body: It's possible two authorizations will be created for this case, but both will contain the identifier . This can be confusing to users! (e.g. shred/acme4j) If one of the authorizations fails a challenge validation operation the client can't know whether it was the "URL" validation, or the "URL" validation that failed and won't be able to prompt the user to retry with the failed domain removed. Generally speaking it makes presenting accurate error information difficult without over-fitting Let's Encrypt's particular Wildcard issuance policies. (E.g. see discussion in URL and URL) This commit introduces an optional boolean authorization field that can be used to indicate the authorization's identifier should be considered the base domain of a wildcard identifier that was requested. This replaces , which included the baggage of .
Change:
use a CONNECTION_CLOSE frame if it has sufficient state to do so. To support this process, a token is sent by endpoints.  The token is <del> carried in the NEW_CONNECTION_ID frame sent by either peer, and servers can specify the stateless_reset_token transport parameter during the handshake (clients cannot because their transport parameters don't have confidentiality protection).  This value is protected by encryption, so only client and server know this value. Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </del> <ins> carried in the Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers can also specify a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake; clients cannot use this transport parameter because their transport parameters don't have confidentiality protection.  These tokens are protected by encryption, so only client and server know their value.  Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </ins> An endpoint that receives packets that it cannot process sends a packet in the following layout:

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.
Change:
utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. <del> TLS cannot be used directly in datagram environments for the following five reasons: </del> <ins> TLS cannot be used directly over datagram transports the following five reasons: </ins> TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence

Discussion:
== COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? [Hannes] DTLS is also used over non-IP-based networks (e.g. LoRaWAN, NB IoT, Bluetooth Smart) and "datagram transport". What would be the right term to describe "environments" that include transport layer protocols like UDP as well as those non-IP-based networks? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? [Hannes] The complete sentence is: " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered. " I believe that saying sequence numbers enable reassembly in the correct order is correct. -- Section 3.1 -- Should there be a hint to a maximum retry count ? [Hannes] There will be a retry count in an implementation. Do we need to say that if we don't have a number to suggest? Not sure. -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer... [Hannes] Seems to be common these days. Examples: CoAP, and QUIC
I don't think I found the PR to match up with the "pr-exists" label; could I get a pointer?
My bad. URL