Martijn van Beurden <mvanb1@xxxxxxxxx> wrote:
> 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
So, this is kind of similiar to whether or not email programs load remote
resources when rendering HTML parts. Generally, they used to, and now they
generally do not. I don't think that this change occured due to any *IETF*
advice. If there was, then it would be great to cite that.
> 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.
I think that this is great, and put it into Security Considerations.
I don't like seeing BCP14 text (RECOMMENDED) in Security Considerations myself.
I would write:
applications need 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.
No, this is rather too specific.
>> 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 think that this is an excessive concern.
It only really applies to LookOut, which ignores MIME content, and tries to
guess the content, and this has been a major security hole for literally decades.
I just don't think this is our business.
>> 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.
+1
>> 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.
We aren't taking over *FLAC*
We are writing a way to put it into an EBML/Matroska container.
The rest of the codes aren't ours, nor is the registry.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
