October 2004 - Ietf-types

ConfirmSystem: iana@icann.org [[b8cff28327f85e7c]]
by iana＠iana.org 29 Oct '04

29 Oct '04

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=b8cff28327f85e7c&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thank you!" and it arrived at IANA approximately at Fri Oct 29 04:03:54 2004. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[b8cff28327f85e7c]] 4

1 0

ConfirmSystem: iana@icann.org [[c1bcd9ea4cb39927]]
by iana＠iana.org 29 Oct '04

29 Oct '04

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=c1bcd9ea4cb39927&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hello" and it arrived at IANA approximately at Fri Oct 29 03:37:41 2004. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[c1bcd9ea4cb39927]] 3

1 0

ConfirmSystem: iana@icann.org [[83f3d701c0925134]]
by iana＠iana.org 29 Oct '04

29 Oct '04

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=83f3d701c0925134&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thanks :)" and it arrived at IANA approximately at Fri Oct 29 03:27:40 2004. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[83f3d701c0925134]] 2

1 0

ConfirmSystem: iana@icann.org [[f27213adb9130923]]
by iana＠iana.org 29 Oct '04

29 Oct '04

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=f27213adb9130923&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hi" and it arrived at IANA approximately at Fri Oct 29 01:05:37 2004. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[f27213adb9130923]] 1

1 0

Pre review of 3GPP MIME type for RTP payload format
by Magnus Westerlund 28 Oct '04

28 Oct '04

Hi, I would like to have a pre registration request review of the below propsed MIME type for a RTP payload format. This registration request is intended to use the updated registration procedure based on specification available from other standards body. The specification that the registration belongs to can be found in the following 3GPP contribution: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip Which is the specification delta that included the RTP payload format defined within to the following specification: http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip The registration template for this looks like the following: ------------------------------------------------------------ MIME media type name: audio, video, text, application, image MIME subtype name: rtp.enc.aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA ---- End of template --- Hope for comments within a week. Otherwise any changes within 3GPP will be more difficult. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 6

Comments on draft-freed-media-types-reg-01.txt
by Magnus Westerlund 27 Oct '04

27 Oct '04

Hi Ned and John, I have now reviewed your document and have some comments and questions. MW1: Section 3.4: Based on all arguments I have heard about any experimental tree, they should be strongly discouraged to be used at all. The motivation, is that if one defines a experimental type in a test application. The application becomes a success, suddenly you have an deployed base of something you didn't intended to. Then trying to change the type leads to interoperability issues, and may in best case result in usage of two different names for the same type. I think it might be better to recommend that one simply uses a real type, and tries to register it as soon as possible. MW2: Section 4.2.1, third paragraph: "Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of "text"." When one has limited usage, like say "only for usage in RTP" I think there are need to consider some wider interpretation of what "to some extent readable" means. We had an example in the 3GPP timed text discussion, where the RTP payload format consists of embedded UTF-8 or UTF-16 strings in an otherwise binary format. However for RTP that is the common case. Should such any clarification on the performance of such consideration be written into this spec or do it belong to a further registration document in relation do a specific domain of usage? ME3: Section 4.3: Parameters only applicable to a specific domain of usage? Certain types will be (are) registered for several domain of usage, however the different domain may require that different parameters are used. I can give you an example in RFC 3267 that has quite many parameters for RTP usage, but none for the file format. How is it supposed to be indicated that this is the case? MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF) definition of the parameter values need to be properly defined. Otherwise it is hard to make any assumption about what is potential to be used in protocols. I think it also needs to take the current used protocols like, mail, HTTP, SDP into account. MW5: Section 4.9: I think the draft hints in section 4.2 that with certain limited usage, another document may further define how the media types should be treated, and what to think of. However I think it might be worth being a bit more clear on what such a document should do. In addition to defining any further restrictions on registration, I think it should define a "name" for this application to be used in the "Restriction on Usage" heading in the template. MW6: I think further clarification on the coupling between the "intended usage" and the "Restriction on usage" is needed. For example, is one allowed to use "Common" when the restriction of usage says: Only for use in RTP? And is the classification of what is common, limited usage, or obsolete depending on the domain? MW7: Section 10: Actually I find the labeling of "Author/Change controller:" a bit confusing. In my view there can be a big difference between Author and Change controller. For example in my proposed registration of audio/rtp.enc.aescm128 where I am the author and the direct recipient of any comments at the initial stage. However the change control over this type belongs to 3GPP. And although the contact person exist, that might be even a third entity in some cases. Might it not be wise to split them into separate cases to clarify this? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

6 20

Post-facto reporting of media type security considerations
by Bruce Lilly 23 Oct '04

23 Oct '04

[This message has been sent to the ietf-types mailing list with a courtesy copy to IANA (as IANA issues are raised); I have suggested responses be directed to the ietf-types list] There are some media types for which security issues have become known since the original type registrations. RFC 2048 has a provision for reporting such issues: 2.2.6. Security Requirements [...] The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular may be extended by use of the "comments on media types" mechanism described in subsequent sections. and 2.4. Comments on Media Type Registrations Comments on registered media types may be submitted by members of the community to IANA. These comments will be passed on to the "owner" of the media type if possible. Submitters of comments may request that their comment be attached to the media type registration itself, and if IANA approves of this the comment will be made accessible in conjunction with the type registration itself. RFC 2048 was issued nearly eight years ago, so I wonder if the procedure listed there is still considered appropriate. In particular, I have several questions that members of this list might be qualified to answer: 1. Has this mechanism ever been used? [I have scanned several dozen media registrations, but could find no example of anything that looks like commentary attached to the media type registration] 2. Media types can be registered via a textual form alone, or in an RFC. It seems unlikely that IANA can attach comments to an RFC, as RFCs are supposed to remain unchanged once published. There is a somewhat obscure errata page, but that's managed by the RFC Editor, not IANA. I therefore believe that the RFC 2048 procedure as written is not entirely adequate. Comments? 3. Does IANA itself currently have the expertise to evaluate accuracy and applicability of submitted comments? If not, who will IANA turn to for advice, and would it be prudent/advisable/acceptable for "submitters of comments" to copy them (assuming that submission of comments to IANA is still considered the applicable procedure)? 4. The RFC 2048 text mentions that comments will be forwarded to the media type "owner", and mentions IANA approval of comments. What procedures exist for conflict resolution? For example, suppose that the submitter of a textual registration which claimed "no known security issues" believes in security through obscurity (or is constrained by such a corporate employer's policy) and objects to having security comments attached to the registration (assume that substantial third-party corroboration of real security issues is provided with the comments); does the type "owner" have final say in the matter, does IANA have the authority to override such non-substantive objections, is there provision for IETF AD or IESG review if necessary, etc.?

3 7

ConfirmSystem: iana@icann.org [[a92b5906721e8790]]
by iana＠iana.org 18 Oct '04

18 Oct '04

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=a92b5906721e8790&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Post-facto reporting of media type security considerations" and it arrived at IANA approximately at Mon Oct 18 07:59:33 2004. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[a92b5906721e8790]] 1

1 0

RE: Registration of media type text/3gpp-tt
by Rey Jose 10 Oct '04

10 Oct '04

> -----Original Message----- > From: ned.freed(a)mrochek.com [mailto:ned.freed@mrochek.com] > Sent: Friday, October 08, 2004 4:43 AM > To: Rey Jose > Cc: IETF-Types; Colin Perkins > Subject: RE: Registration of media type text/3gpp-tt > > > It is more than 2 weeks since I sent this in for > consideration. Could > > you please inform me about the status? I would like to > proceed ASAP > > with WGLC in AVT but cannot without passing this review. > > The ietf-types list is for informal media type reviews only. > It is not where types are "considered" or "approved". > Somtimes people comment on registrations, other times they don't. > Yes, you are right, "review" is the correct term. However, reading the attached email from Colin, I understand that this review is 'required' for WGLC. This means that whether this review is "no comments" or there are in fact comments, I (we) have to know in order to progress the document. Specially this part (original attached): "In future, as new RTP payload formats are developed, we will require expert review of the media type registration as part of the working group last call process. Please contact the chairs for guidance on the procedure for this review, when you believe your draft is ready for working group last call. We will not forward drafts to the IESG for publication **unless they have received such review.**" Thanks, José > This type appears to be specified in an internet-draft that > is destined to become an RFC. If that's the case, the media > type will be reviewed as part of the IESG review and RFC > publication process. > > Ned > >

3 5

RE: Registration of media type text/3gpp-tt
by Rey Jose 08 Oct '04

08 Oct '04

--snip-- > > However, reading the attached email from Colin, I > understand that this > > review is 'required' for WGLC. This means that whether > this review is > > "no comments" or there are in fact comments, I (we) have to know in > > order to progress the document. Specially this part (original > > attached): > > > > "In future, as new RTP payload formats are developed, we > will require > > expert review of the media type registration as part of the working > > group last call process. Please contact the chairs for > guidance on the > > procedure for this review, when you believe your draft is ready for > > working group last call. We will not forward drafts to the IESG for > > publication **unless they have received such review.**" > > This is an AVT policy, to avoid last minute confusion and > problems such as we had with the RTP payload format for text > conversation; it's not a wider IETF requirement. If no > comments result after a reasonable time period, so be it. > Oops! my mistake, I really had "AVT" written while drafting the email, must have deleted it... I understand that these rules are restricted to AVT, but from your email it is not clear that no response from the IETF-TYPES after a "reasonable time period" (whatever that is, probably >= 2 weeks) is also fine for proceeding with WGLC. Anyhow, Martin Duerst did have a comment which I answered. So I'll wait for that to be solved. José > Colin > > >

1 0