Subject: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments

From: [email-masked]
Date: Fri, 4 Jul 2003 18:46:34 +0200

Dear Allison, all,

Thanks for the IESG comments. In response I would like to suggest the 
following:

1) Comment:  It is strange to have more than one section labeled
  "Introduction."  Please pick a new label for section 2.1.

My proposal is to label 2.1 as "Signaling by MIME format parameters"

2) Where is the security model defined for ECMAScript in this context? 
   (Problems with the model have been part of the Javascript security 
   problem for Web browsers.)

MPEG-4 defines some important constraints on the use of ECMA scripts in 
MPEG-4. An annex to the MPEG-4 system spec describes the differences 
between "regular" ECMA scipts and "MPEG-4 scripts". As far as I understand 
these constraints do not allow dangerous ECMA script constructs, which 
means there is no need for an ECMA script security model in this context. 
Below I attached the MPEG-4 annex that describes the differences. 
I suggest to resolve this as follows:
a) replace in section 5 "security considerations" all current references 
to ECMAScript by MPEG-4 script, and 
b) add to the fifth paragraph (starting with "In ISO/IEC 14496-1 a 
security model is defined for ...") the following trailing sentence "Note: 
MPEG-4 scripts are based on ECMA scripts, but there is no need for an ECMA 
script security model, as the use of insecure ECMA  script constructs is 
impossible in MPEG-4 scripts."

3) 2.4:  Why is this form of application-level fragmentation better than
   IP fragmentation?

This is because of error resilience. If IP fragmentation occurs without 
application-level fragmentation, then all data of the entire Access Unit 
gets lost when one such fragmented IP packet is lost. When 
application-level fragmentation is used, and one RTP packet with an AU 
fragment gets lost, then the received RTP packet(s)  with the other AU 
fragments can still be decoded. I suggest to remove "so as to avoid IP 
layer fragmentation" from the first sentence of section 2.4, and to add 
the following after the first sentence: "Hence when an IP packet is lost 
after IP-level fragmentation, only an AU fragment may get lost instead of 
the entire AU".

Any comments very welcome.

Best regards,

Jan van der Meer

*******begin of MPEG-4 system annex*******

        MPEG-4 Scripts Have a Rigid Representation 
MPEG-4 scripts differ slightly from ECMA scripts. The most important 
difference is that MPEG-4 scripts are not represented textually, but are 
transmitted as a parse tree representation.  This means that only 
constructs that can be represented by the MPEG-4 parse grammar can be 
encoded and transmitted. Not all ECMA script constructs can be represented 
in MPEG-4 scripts. 
The differences between ECMA scripts and scripts that can be represented 
in MPEG-4 are given below.

        Keywords
MPEG-4 scripts cannot utilize the following keywords: catch delete do finally in instanceof throw try typeof void with .
This means that  do ? while loops and  for ? in loops are not possible.
        Relational operators
The relational operators  "===" and "!==" cannot be included in MPEG-4 Scripts. 

        Labeled statements
In MPEG-4 scripts it is impossible to label statements and to break or continue to labeled statements.

        Switch statement restriction
MPEG-4 scripts with switch statements can only take numerical case expressions and always must have at least one case statement.
In particular this means that 
switch {
        case (x+1):  ?.
}

is not possible, while
Switch {
        case 1:  ?.
}
is okay.
        Functions, not programs
The MPEG-4 event driven script model allows only functions to be called in 
response to events. 

        Expressions 
Statements that include statement blocks, such as for are represented in 
the parse tree as having an empty statement block, where as in ECMA script 
they can omit this block. Functionally, the statements behave identically. 
For example, the expression: 
        for ( <expr>; <expr>; <expr>) 

must be represented as

        for ( <expr>; <expr>; <expr>) {}

        Array and Object Literals
Array and object literals of the form [value1, value2, .., valueN] and {property1:value1, property2: value2, .. propertyN:valueN} cannot be used in MPEG-4 scripts. 
*******end of MPEG-4 system annex*******

Allison Mankin <[email-masked]>
2003-06-27 06:19 AM
Please respond to mankin

        To:     Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
[email-masked]
[email-masked]
[email-masked]
Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1
        cc:     [email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
        Subject:        IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments
        Classification: 

The IESG reviewed draft-ietf-avt-mpeg4-simple-07.txt and had a few 
concerns
that should be addressed before the draft can advance.  Editorially:

   Comment:  It is strange to have more than one section labeled
  "Introduction."  Please pick a new label for section 2.1.

Steve Bellovin and Ned Freed both request that a reference be given in
the Security Considerations for security model for ECMAscript.  Here
is Steve's Discuss comment:

   Where is the security model defined for ECMAScript in this context? 
   (Problems with the model have been part of the Javascript security 
   problem for Web browsers.)

Steve also asked:

   2.4:  Why is this form of application-level fragmentation better than
   IP fragmentation?

Please discuss the issues in email and we'll see if the fixes to the draft
can be done as notes rather than a revised i-d, to be quicker.

Allison

---

From: John Lazzaro <[email-masked]>
Date: Mon, 7 Jul 2003 12:33:05 -0700

>  [email-masked] writes:
>
> As far as I understand these constraints do not allow dangerous ECMA
> script constructs, which means there is no need for an ECMA script
> security model in this context. Below I attached the MPEG-4 annex that
> describes the differences.

Do "MPEG-4 scripts" give the script control over audio volume of the  
presentation, in a way that could override the levels manually set
by the human listening to the decoder?  A rogue program that blows
out the speakers of the victim's terminal seems like a security
risk of some sort, although not of the classical kind since data
and CPU and network are not compromised ... if this is an actual
risk, might be worth warning implementors in the Security
Considerations section ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Tue, 8 Jul 2003 17:00:29 +0200

Hello John,

Thanks for commenting. 

> by the human listening to the decoder?

In my understanding, MPEG-4 only provides the capability to control the 
presence of audio objects (streams) in a scene, hence the audio level can 
be controlled from zero up to a certain "nominal" level. MPEG-4 does not 
provide the capability to control the volume level at which the user 
"enjoys" the scene. In other words, in my understanding the problem that 
you mention does not exist in MPEG-4.

Best regards,

Jan

John Lazzaro <[email-masked]>
Sent by: 
[email-masked]
2003-07-07 09:33 PM

        To:     [email-masked]
        cc:     (bcc: Jan vanderMeer/EHV/CE/PHILIPS)
        Subject:        [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss 
Comments