Hi Robert, Many thanks for your review, it is very much appreciated. I attempted to address some comments at https://github.com/ietf-wg-cellar/flac-specification/pull/234. For a few others, I would like to comment on them below: > > The discussion (and possibly the specification) of the use of URLs in metadata > blocks is insufficient. Relying only on explicit user approval to access the > resource still leaves many possible exploits. What does explicit approval mean? > Is clicking approval once in an application to say "Yes, you can download album > cover art" sufficient? Consider an instance, particularly one served over HTTP > using the content type registered by this document that becomes virally popular > and contains a URL pointing to a victim. Consider again such a thing where the > contained URL is, perhaps by mistake, exactly the URL originally retrieved > (causing a naive implementation to enter a request loop). Some additional > discussion of what is reasonable to retrieve is warranted, and the spirit of > same-origin should be taken into account. Privacy should also be mentioned - > what sort of tracking can be accomplished through accesses to the URL? > This has been a blind spot in the development of this document indeed. I am not sure how to improve. Do you perhaps know of RFCs dealing with similar problems from which I can draw some inspiration? I propose adding the following to that paragraph: Retrieving resources via remote protocols can potentially be tracked, exposing the user to a privacy risk. Also, such retrievals can be used in a DDoS attack when the URI points to a potential victim. Therefore, applications are RECOMMENDED to ask user approval for each retrieval individually, and cache retrieved resources. Should I perhaps add a recommendation to show the user the URI when asking for approval? Maybe an exception for user approval can be added when the origin of the stream is known and the URL is same-origin as per RFC 6454? This would be useful when streaming FLAC audio over the internet. Considering a request loop, I am not sure how that would be possible. The FLAC stream points to a URI that is supposed to be an image. When that would point to the FLAC stream, it would make little sense to further parse it, as the application is expecting an image, not another audio file. Explicitly stating that an application should not parse a FLAC stream pointed to by a URI in a picture to find an image more or less recursively seems superfluous to me. > > There should also be acknowledgment of the risks of allowing arbitrary content > to be bundled into FLAC files, particularly in contexts where the MIME type > defined in this document is used (web retrieval, multipart/mime in email, > wherever else). How might this be used to circumvent content security policies > at firewalls, for example? The document already acknowledges that executable > code can appear here, but that's only one type of risk, and the discussion in > the document steers quickly to the implication that the executable code is not > malicious. Is it ever safe to actually execute such code? > I propose to add the following line to the security consideration: Like any lossless codec, FLAC can be used to obscure data and bypass content security policies. Considering whether the execution of such code is ever safe, I'm not sure what to add. Acquiring an uncompressed disc image or one compressed with FLAC makes no difference when considering the security implications, except the latter potentially bypassing malware detection unaware of the FLAC format. In both cases the user will have to decide whether or not to trust the source. > > Nit issue: > > This is really almost editorial, but I'm pulling up here so that the SEC ADs > see it early; It's a little odd to lean on RFC4732 they way the document does. > I understand the intent, but it requires the reader to do some lateral thinking > to apply that RFCs guidance to this document. Consider some words motivating > how you are intending for it to apply here. > Looking back, I think I copied this straight from rfc6716, which is the only other audio codec for which an RFC is written as far as I know. I propose the following instead of that first sentence: Implementations of the FLAC codec need to take appropriate security considerations into account. Section 2.1 of [RFC4732] provides general information on DoS attacks on end-systems and describes some mitigation strategies. Areas of concern specific to FLAC follow. > > More of a question than an issue, but I think the ADs consider the answer: Why > isn't this document moving the registry currently at > https://xiph.org/flac/id.html to IANA? > I think I brought this up during a working group meeting quite a while ago as I felt unable to oversee the consequences of such a decision. I can't find anything about it in the minutes, but there was at some point a decision to not move it to the IANA. Sorry, I am not being vague on purpose, I simply don't know whether it would be a good idea. > > Consider quoting "fLaC" when your are talking specifically about the marker in > prose everywhere (as you quote it in 10.3) > In the XML, those fLaC mentions have 'tt' emphasis. It renders to the HTML and the PDF, but not to the text format, like many other forms of emphasis. I prefer it with this emphasis, but I understand the text format is considered more important? > > At the restriction in section 7 of the maximum block size for 48kHz audio to > 4608 - consider showing where 4608 came from. > I don't know, honestly. 4608 is one of the common block sizes, but other than that, I think it is arbitrary. > > I will almost, but not entirely, let "A bright colored fish" pass without > comment as it's not this document's responsibility. > Yes, that is mentioned in the ID3v2 specification it has been adapted from, but nobody seems to know what it came from. Probably a joke. > > And finally - Please reconsider using the TITLE example in D.2.5 that leaves > you using an rtl script inline with the ltr prose. You are within your rights > to do so, but it is stabbing at a place where the world (not just our own > tooling) isn't as ready as we would like it to be. > That is why I think it is nice to have it as an example. This mix of scripts is rtl and ltr is the rule rather than the exception here, because the field name is always in latin script, and the field contents can be in any script. FLAC tagging tools all face this problem. Once again, many thanks for your review of this document. Kind regards, Martijn van Beurden -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
