Dear Shawn, thanks for your feedback. Replies inline. On Tue, 4 Apr 2023 at 07:30, Shawn Emery via Datatracker <noreply@xxxxxxxx> wrote: > The security considerations section refers to section 4.6 of RFC 6838 and > possible exploits regarding arbitrary code execution from YAML tags, DoS > through infinite or high recursion, and DoS through the partial processing of > YAML streams. Ok. If you envision further issues, please let us know. > I do agree with each of the mitigations prescribed for the > aforementioned exploits, but it does seem counterintuitive to me to validate > all the documents in the stream before processing. Does this defeat the > purpose of streaming? Before answering, I have to clarify that the term "YAML stream" designates zero or more serialized YAML documents, independently of how they are processed (see https://yaml.org/spec/1.2.2/#streams). This means that a short, serialized YAML document stored in a filesystem is a "YAML stream". This is the reason why Section 4.3 uses the term "incremental", and we never use the term "streaming" in this document. Your question is appropriate. The general idea is that if an implementer is fine in processing each document in a stream independently (e.g. he knows that the documents in the stream are not part of a sort of "transaction", or that broken documents can be referenced in some way and retransmitted later on), there is no need to validate all the stream beforehand. Do you think that the current wording does not convey this concept? Do you have any editorial suggestions? Moreover, if you think that the section can be improved, I'm happy to get your feedback. > General Comments: > > The FAQ section helped me to understand why some of these design decisions were > made, thank you. You welcome! > Editorial Comments: > > s/Security considerations: See Section 2.1/Security considerations: See Section > 4/ This should be "Same as application/yaml", without references to this document. > s/impact on the/impact the/ Fixed in #82 s/impact on/affect/ > s/serialize it JSON/serialize it in JSON/ Fixed in #84 s/it JSON/it as JSON/ > s/details: this/details, which/ Fixed in PR#85 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
