jiebi/CodeConvo huggingface dataset:
Code change:
NAME PTAL
The current text on user identity covers the domain portion well enough, but doesn't really say anything about how the part preceding the 'NAME is handled. There is text regarding the use of a local address book for the purposes of rendering, which might help avoid these issues entirely... where available. We may need to consider addressing the issue of confusable characters and whether we need to define the use of a particular normalization form. (See )

Related discussion:
text: authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. <ins> 6.4.4.1. Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see RFC6943 for more on this topic).  This is a problem with any identifier space of this type (e.g., e-mail addresses).  Those minting identifers should avoid mixed scripts and similar confusable characters.  Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see RFC5890, section 4.4).  Other best practices are still in development. </ins> 6.4.5. A number of optional Web security features have the potential to
Code change:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

Related discussion:
text: 11.3. The following registrations are done following the procedure <del> specified in RFC6838 and RFC7303. </del> <ins> specified in RFC6838 and RFC7303.  Clipboard formats are defined for the JSON and XML form of lists but do not make sense for streams or other formats. </ins> Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media-
Code change:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

Related discussion:
text: File extension(s): senml and sensml <ins> Windows Clipboard Name: "JSON Sensor Measurement List" for senml </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-json conforms to public.text for senml </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>
Code change:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

Related discussion:
text: File extension(s): senmlx and sensmlx <ins> Windows Clipboard Name: "XML Sensor Measurement List" for senmlx </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms to publc.xml for senmlx </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>
Code change:
This adds a security consideration for padding. THis addresses issue
With the move from CBC to GCM as a padding mode, there is now no padding for a S/MIME message at all. We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size.

Related discussion:
text: Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without <del> wrapping it in SignedData or enclosing SignedData within it. </del> <ins> wrapping it in SignedData or enclosing SignedData within it.  This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData as the authenticated encryption algorithms provide the authentication without needing the SignedData layer. </ins> If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size
Code change:
This adds a security consideration for padding. THis addresses issue
With the move from CBC to GCM as a padding mode, there is now no padding for a S/MIME message at all. We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size.

Related discussion:
text: the fact that the CEK is going to be known to both parties.  Thus the origination is always built on a presumption that "I did not send this message to myself." <ins> All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm.  This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same.  This information can enable passive observers to infer information based solely on the length of the message.  Applications for which this is a significant problem need to provide some type of padding algorithm so that the length of the message does not provide this information. </ins>
Code change:
…fix the various typos flagged by DKG, submit as WG draft.

Related discussion:
text: 4- The multiplexed server establishes the connection to the protected service, thus revealing the identity of the service. <ins> One of the goals of SNI encryption is to prevent adversaries from knowing which Hidden Service the client is using.  Successful replay attacks breaks that goal by allowing adversaries to discover that service. </ins> SNI encryption designs MUST mitigate this attack. 2.2.
Code change:
…fix the various typos flagged by DKG, submit as WG draft.

Related discussion:
text: HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. In this solution, the client establishes a TLS connection to the Fronting Server, and then issues an HTTP Connect request to the <del> Hidden Server.  This will effectively establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </del> <ins> Hidden Server.  This will establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </ins> The HTTPS in HTTPS solution requires double encryption of every packet.  It also requires that the fronting server decrypts and relay
Code change:
Adding an example manifest using AES-KW in case where the Author knows the recipients (the Author and the Devices have the same pre-shared key).
This is a good example. I looked through it and it made sense to me.
In the firmware encryption draft we have defined an extension to the envelope that indicates what encryption parameters are applied to which component. Here is the CDDL: Currently the text provides no explanation or an example of how this linkage works.
This aspect is related to URL and to the mailing list discussion URL
This issue is also related to URL
With in PR , this issue is solved. Internet-Draft draft-ietf-suit-firmware-encryption-URL is now available. It is a work item of the Software Updates for Internet of Things (SUIT) WG of the IETF. Title: Encrypted Payloads in SUIT Manifests Authors: Hannes Tschofenig Russ Housley Brendan Moran David Brown Ken Takayama Name: draft-ietf-suit-firmware-encryption-URL Pages: 52 Dates: 2024-03-03 Abstract: This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTMLized version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL

Related discussion:
text: a digital signature), multiple recipients, encryption of manifests (in comparison to firmware images).]] <ins> The following manifests examplify how to deliver the encrypted firmware and its encryption info to the Devices. The examples are signed using the following ECDSA secp256r1 key: The corresponding public key can be used to verify these examples: Each example uses SHA256 as the digest function. 9.1. Diagnostic notation of the SUIT Manifest: In hex: </ins> 10. The algorithms described in this document assume that the party
Code change:
In Section 3 of the RFC, it states that the authenticator request includes those extensions allowed for the CertificateRequest message. However, this does not mean it could only includes them and other extensions could also be sent. In the TLS spec CertificateRequest explicitly states "Clients MUST ignore unrecognized extensions.", we should have the same here.

Related discussion:
text: If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  Unrecognized extensions MUST be ignored.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.
Code change:
This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.

Related discussion:
text: A Flags Extension for TLS 1.3 <del> draft-ietf-tls-tlsflags-09 </del> <ins> draft-ietf-tls-tlsflags-10 </ins> Abstract
Code change:
This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.

Related discussion:
text: understands and supports the extension, but some extensions do not require this acknowledgement. <ins> For a flag that does require a response, the only proper response is the same flag in a flags extension.  This extension MUST NOT be used to specify extensions where the response is a proper extension with content. </ins> A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in
Code change:
The 0-RTT key might differ between TLS versions (as demonstrated with the draft -20 changes). Be explicit about storing this version number since section 4.2.9 requires this information too.

Related discussion:
text: the following additional information MUST be provisioned to both parties: <ins> The TLS version number for use with this PSK </ins> The cipher suite for use with this PSK The Application-Layer Protocol Negotiation (ALPN) protocol, if any
Code change:
It has a proper definition in appendix A.4. Note though that RFC 4507 section 7 has allocated this value for the session_ticket/NewSessionTicket handshake type. This point may be moot if RFC 4507 has been integrated with TLS 1.3, in which case RFC 4507 should be added to the list of obsoleted RFCs.
The handshake packets in TLS 1.2 and earlier are numbered so that the HandshakeType for each of client and server is strictly increasing when packets arrive in correct order, and HandshakeType/10 indicates the flight number. This allows for using a simpler state-machine. The new handshake packets {server,client}keyshare break this convention by using numbers in the flight 2 range (17 & 18), while belonging in flight 1. This suggestion is to renumber them to eg clientkeyshare(5) and serverkeyshare(6)

Related discussion:
text: draft-04 <ins> Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration. </ins> Remove renegotiation. draft-03
Code change:
"A client MUST provide a 'pskkeyexchangemodes' extension if it offers a 'preshared_key' extension."

Related discussion:
text: "pre_shared_key" is REQUIRED for PSK key agreement. <ins> "psk_key_exchange_modes" is REQUIRED for PSK key agreement. </ins> A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension with 0x0304 as the highest version number contained in its
Code change:
It appears we should have included rules for populating a registry for the pskkeyexchange_modes extension.
Yes, an obvious oversight in our oversite. :) I approve.
+1
FWIW, +1
+1 to a new registry.
Yes, we should create a registry. But: We need to update the "this document defines a new registry" to match the new number of registries (two) the space of allowed values is only one byte, so we don't need to talk about "first byte"

Related discussion:
text: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. <ins> TLS PskKeyExchangeMode Registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 254 or 255 (decimal) are reserved for Private Use RFC8126.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated psk_ke (0) and psk_dhe_ke (1).  Both SHALL be marked as "Recommended". </ins>
Code change:
The I-D checklist requires that updates and obsoletes be included in the abstract; thought RFC. I personally feel this is [redacted] stupid, but I do not think that we should risk a process appeal to fight this battle.

Related discussion:
text: over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <ins> This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. </ins> 1. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: an editorial update.  It contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to <del> secrets in favor of the term "main". </del> <ins> secrets in favor of the term "main" or shorter names where no term was neccessary. </ins> 1.3.
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. <del> The same warnings apply to any use of the early_exporter_main_secret. </del> <ins> The same warnings apply to any use of the early_exporter_secret. </ins> 0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message creates a unique association between the ticket value and a secret <del> PSK derived from the resumption main secret (see cryptographic- </del> <ins> PSK derived from the resumption secret (see cryptographic- </ins> computations). The client MAY use this PSK for future handshakes by including the