DAPT 2023-07-31 / 2024-11-07 > 2025-01-07 #59
Comments
|
Hey there, would appreciate an update on the likely timeline for this please, on behalf of TTWG. |
|
@simoneonofri WG is waiting for your comment on security consideration section. Please give us any comment if you find. |
|
hi @simoneonofri , may I ask about current status of this review request? |
|
Hello @himorin, @nigelmegitt, First of all, thank you for your patience! I've read the questionnaire, and considering it's a file format, with @innotommy, we've come up with a Threat Model for File formats:
You have already identified an issue related to embedding
Let me know if you prefer to discuss here or in a dedicated issue in your repo. Thank you, Simone |
|
Hi @simoneonofri thank you for the review. I am not sure what you mean about "embedding There is nothing in TTML2 or DAPT that supports execution of any javascript within the payload of I would suggest that DAPT's dependency on XML, the payload syntax constraints in DAPT and TTML, and the validation semantics of both, are adequate to conclude that data integrity has been considered. |
|
My attempt at responding to @simoneonofri's questions:
The
DAPT is based on TTML2, which is based on XML, so the security concerns regarding PLS are those of XML languages.
I don't know if we should consider base64 encoding as a CD mechanism. In any case, base64 support is a feature of TTML2, nothing new in DAPT. Generally, I would say there is no specific CD consideration in DAPT. There could be CD considerations in the transport layer, like HTTP Transfer encoding but that is not specific to DAPT.
DAPT (and TTML2) does not allow embedding of executable code.
DAPT reuses the features of TTML2 that allow linking to external resources. It does not define any new one. The only use of TTML2 linking feature is for
Can you elaborate on what this means?
Can you elaborate on what this means? |
|
@simoneonofri thank you for your review and comments, I believe all questions are answered, and please let us know if you are satisfied or not. In addition to @nigelmegitt 's comment about For 6 items from Threat Model, thank @cconcolato for giving analysis of DAPT, and it seems these items are better to be integrated into self-review material. I suppose it's still early phase for rebooted security group, but WGs would be happy to hear about any plan to update questionnaire with recent security considerations. |
@nigelmegitt thank you for the clarification :) |
Thank you :)
Ok, so in the questionnaire it was an example, and for that in the current considerations there is a reference to the security considerations of TTML2. It's a “way” (profile) of using that format? In this sense, does it add components/functionality? In general, adding features could introduce vulnerability issues. That's why I ask. If there are new threats/vulnerabilities/attacks that can be made through DAPT, compared to TTML2.
Ok, great, thanks for the explanation, so as @nigelmegitt writes, it might make sense to reference that potentially there are various attacks/vulnerabilities/branches derived from the use of XML, same as you wrote for TTML2.
I agree that base64 is ecoding. Thank you for the analysis, I think this
Ok!
Okay, thanks for the explanation. One direction is to include elements to verify the integrity of external files, such as the SRI. Does that make sense? Otherwise, it's out of scope. I've seen several vulnerabilities exploited by audio libraries, but they don't depend on DAPT.
Of course, if there is metadata present (I would tell you internal to this format if we are talking about an XML base), if yes, what happens if it is manipulated (dates, timestamps, authors, etc.), for example, there are some attacks done by altering not so much the file itself but its metadata (to give an example, it was common practice to insert malicious payloads inside EXIF data, as well as to use them to get information that is not strictly necessary).
Yes, then, if there's a mechanism to check whether or not when the file gets to the processor, it's been altered or not. Or if that issue is maybe delegated to another level (e.g., transport) |
himorin thank you, yes I think with a few more messages (if we need to even make a short call), we can get a good result and then propose a standardized structure of the section.
You brought up a very good point. I've already opened an issue about that, obviously from the experience we're having from these early reviews. I would appreciate it if you would support the change. On facilitating the Threat Model, it's definitely a goal of SING. |
|
@simoneonofri in terms of this review, rather than potential future changes to the self-review or to the structure of security sections in data format specifications, are you satisfied that we can proceed, or do you have remaining unanswered questions or concerns? |
Hi @nigelmegitt I was waiting some feedback from @cconcolato on my explanation 😄. For now, I think the main point is to refer to the Security Considerations of TTML2 (already done), and also - as you suggested - to refer also XML Security potential issues. |
Yes.
DAPT does not add functionality related to the
It does. I was not aware of this ~10 year old spec! It is an interesting idea to offer a standard way for authors to provide hashes/digests of embedded resources. I think the TTWG should consider that first for inclusion into TTML first and then DAPT could adopt it.
First of all, DAPT does not rely on external (e.g. transport level metadata). Now, there is no official data/metadata classification of the content of a DAPT document. If we had to, I would say, anything that is not text content would be metadata, such as timing, annotations, language information. Given that definition, manipulation of metadata would result in text content being processed at the wrong time, or wrongly (e.g. audio description being processed as dubbing or vice versa). You could, for example, make the characters say things in a different order. It would be hard to differentiate from badly authored content. I don't know if this can be considered as an attack. How do you define an attack?
Yes, I think DAPT would defer that to the transport level. |
This is very interesting, I was not aware of it either. I can foresee significant potential problems with requiring it in the context of DAPT. The subresources that would be relevant are audio files, most likely for audio descriptions; during the authoring and quality checking phases of content production it could be useful to replace those audio files, for example if a better recording is made. In that case, I would not like to be prescriptive about how the referencing DAPT document might need to be modified. On the other hand, it could be helpful to have the option of adding an integrity check when the content is considered complete, i.e. that no more work is required. If the DAPT file is being distributed, it is likely that any URLs for external resources would need to be changed to take into account CDNs etc. Player behaviour if an integrity check fails would be an interesting consideration. I agree with Cyril that this could be useful and needs more consideration - I would certainly not like to delay the initial version of DAPT while we think about it, if I'm reading correctly that this would be a "nice to have" rather than an "essential" from a security point of view. |
hi @simoneonofri , sorry to rush into, but does reply satisfy your concern from security point of view? I suppose all points except for verification are clarified, and integration of verification using standard approach could be considered as future extension but not a blocker for DAPT into CRS. If so, could you mark this review request as completed (and close this issue)? |
|
@himorin @nigelmegitt @cconcolato thank you for the conversation. I've opened two issues related to our discussion. |
We prefers groups to run a self-review around the time of FPWD. See https://w3ctag.github.io/security-questionnaire/.
If you still want us to review your spec, please provide the information below.
In the issue title above add the document name followed by the date of this request.
Other comments:
We have built, actually or conceptually, on previous privacy reviews for TTML2 and IMSC to inform this.
The text was updated successfully, but these errors were encountered: