Editorial comments and questions to Draft H.235
Jim Toga
jtoga at ideal.jf.intel.com
Wed Aug 27 19:47:51 EDT 1997
Dear Mr. Okubo,
Thank you for your review and comments. Some of your editorial comments I
have previously noticed, many I had not and I will attempt to address them.
I have included my responses where appropriate, below.
Best Regards,
jimt.
At 07:29 PM 8/27/97 JST, you wrote:
>Dear Jim,
>
>I had a chance to read (actually look) through APC-1191 (Hertzlia
>meeting document) and found some presumable editorial errors as
>attached from a bystander perspective. This might be too late for
>your Sunriver input, but I hope it would be of some use for your
>further editing. { } indicates my thoughts.
>
>I have a couple of questions other than THE editorial comments for my
>understanding.
>
>1) General
>
>H.235 seems to be handling only media by media encryption. The case
>of encrypting H.222.1 multiplexed stream or H.223 multiplexed stream
>is also covered by the current specification? Or can it be part of
>the future H.235 extension?
The current H.235 only covers logical channel oriented encryption. The
intent was to adopt other methods for other H series terminals. Section 14
is a place holder for H.324. The initial possibility there, was to allow
for a secure adaptation layer to be provided above the H.223 MUX. This
could be used to swap the modes to either simulate the 'per channel'
encryption or provide the entire MUX encryption.
In any case, I believe this area would benefit from further work, and
perhaps some additional Annexes.
>
>2) Section 9.2, nonIsoMediaEncryptionAlgorithm ::=CHOICE
> Section 13.3.5, nonIsoIdAlgorithm ::=CHOICE
>
>We have three such non-ISO algorithms specifically listed. Is this
>the policy we confirmed? Are we going to list all of proprietary
>algorithms one by one in H.235 (or H.225.0, H.245)? Or are they
>identified in non-standard ways?
This has been changed to incorporate all algorithms (whether they be
'standards body' registered or completely proprietary) by utilizing a
generic object identifier. This method removes the ITU-T from any awkward
position of deciding which algorithms to include/exclude.
>
>3) Section 9.2, ASN.1 syntax
>
>H.245 syntax has a top-down structure, but here it looks bottom-up.
>{Perhaps either way is alright for encoding and decoding?}
Much of this has be re-worked to facilitate the cryptographic functionality
needed within ASN.1. The general intent was to allow for an association
between specific codecs (modes/media) and specific security mechanisms.
>
>Best regards,
>
>Sakae OKUBO (Mr.)
>********************************************************************
>Graphics Communication Laboratories Phone: +81 3 5351 0181
>6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184
>4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo at gctech.co.jp
>151 Japan
>********************************************************************
>
>Source: Sakae Okubo
>Title: Ecitorial comments on APC-1191 Draft H.235
>Date: 27 August 1997
>
>1. Contents
>
>title of 13. ==> H.323 SPECIFIC TOPICS
>title of 14. ==> H.324 SPECIFIC TOPICS
>
>2. Section 2, Item 4
>
>The last sentence "This may include both the number of secured users
>and the levels of security provided." is duplicated.
>
>3. Section 2, Item 6
>
>Period is missing at the end.
>
>4. Section 7.1, Items IV. and V.
>
>OpenLogicalCahhnel, OpenLogicalChannelAc, EncryptionUpdateRequest,
>EncryptionUpdate ==> in bold {?}
>
>5. Section 7.1.3, second sentence
>
>on a channel by channel basis ==> on a logical channel by logical
>channel basis {?}
>
>6. Section 7.2, 2nd paragraph, 4th sentence
>
>the card is always may always be ==> one of them should be deleted
>{may be due to my reading the document on Mac Word}
>
>7. Section 7.2.1, 2nd paragraph
>
>H.Secure ==> H.235
>
>8. Section 7.5, 1st paragraph, "any entity which terminates a
>call control channel (H.245) "
>
>{There are several places where "call control" is associated with
>H.245, but Q.931/Q.2931 is more appropriate for the call control.
>H.323 says H.245 control, call control H.225.0 and RAS control H.225.0
>as part of the system control in Figure 4. So, H.245 control channel
>may be the replacement, otherwise communication control may be the
>choice according to the title of Rec. H.245.}
>
>9. Sections 7.5.2 and 7.5.3
>
>They should be transposed {?}
>
>10. Section 8.1, 1st paragraph
>
>See #8.
>
>11. Section 9.1, 1st paragraph
>
>The first sentence needs a period at the end.
>
>12. Section 9.1, 2nd paragraph
>
>"scope (in italic)" is used with a security specific meaning. I would
>suggest this should appear in Section 4 Definitions. We have general
>"scope" in other places.
>
>13. Section 9.3, 2nd paragraph, 2nd sentence
>
>It is hard to understand this sentence; notions of "inclusive and
>exclusive" and "encrypted codes" in particular.
>
>14. Section 11.1, 3rd sentence
>
>I cannot find "prepend" in my dictionaries.
>
>15. Section 11.3, overall
>
>The style is something like a discussion contribution. We need to
>change it to that of specification.
>
>15. Section 11.3, Item I. A. Initialization vectors, 2nd last
>sentence
>
>What is "B" octets?
>
>16. Section 11.3, Item I. B. Padding, 2nd paragraph, "Two methods
>are proposed to handle packets ..."
>
>"proposed" is strange in Recommendation.
>
>17. Section 11.3, Item I. B. Padding, 4th paragraph
>
>There is a spurious period.
>
>18. Section 11.3, Item I. B. Padding, 5th paragraph
>
>- H.Secure ==> H.235
>- "It is recommended that all H.Secure implementations must support
>..." must ==> should {?}
>
>19. Section 11.3, Item I. B. Padding, 5th paragraph
>
>What is "P" bit? See also #15.
>
>20. Section 11.3, Item Stream Algorithms
>
>The item number ==> II.
>
>21. Section 11.3, after Item II. A. (spurious)
>
>and if the performance problem is not deemed to be exist, it should
>not be included. ==> to be existing, or to exist
>
>22. Section 13.1, Figure, TLS/SSL
>
>SSL is striked out in Section H.245Security. If it is valid, it
>should appear in Section 5. Symbols and Abbreviations.
>
>23. Section 13.3.1, 2nd paragraph, 2nd sentence
>
>The intent (as stated in section 7.2) is to not provide absolute, ==>
>is not to {?}
>
>24. Sections 13.3.2, 13.3.3, 13.3.4
>
>There are several "shared secret" in this section. ==> shared secret
>key {?}
>
>25. Appendix B, 3rd paragraph
>
>SSL appears. See #22.
>
>26. Appendix E, 1st paragraph
>
>"call control" appears. See #8.
>
>27. Appendix E, 2nd and 3rd bullets
>
>TLS/SSL appears. See #22.
>
>28. Appendix E, Item III. Call Control (H.245)
>
>See #8.
>
>29. Appendix E, Item 1b), 3rd sentence
>
>Some of the RAS messages are multicast by definition, and as such is
>would be impractical to make confidential. ==> either of "is" or
>"would be" is spurious.
>
>30. Appendix E, Item 1b), 4th sentence
>
>Call establishment messages are currently carried on UDP (unreliable)
>transport Possible solutions ... ==> Call establishment messages are
>currently carried on UDP (unreliable) transport. Possible solutions
>...
>
>31. Appendix E, Item 1c)
>
>H.Secure ==> This Recommendation, or H.235
>
>32. Appendix E, Item 1c), last sentence
>
>... using a "per-message randomization" in section Non-registration
>RAS signaling 13.3.4. ==> ... using a "per-message randomization" in
>section 13.3.4 Non-registration RAS signaling. {?}
>
>33. Appendix E, Item 3a)
>
>... as provide in TLS/SSL. ==> ... as provided in TLS/SSL.
>
>See also #22.
>
>34. Appendix E, Item 3b)
>
>Bystanders able to snoop media encryption algorithms and keys
>exchanged by participants loss of 4b, 4c and 4d. ==> Some words are
>missing between participants and loss {?}
>
>35. Appendix E, Item 4c)
>
>Denial of service attack if bystanders, 'scramble' data. ==> the comma
>is unnecessary {?}
>
>36. Appendix E, Item 4c), last sentence
>
>Integrity servies for media data is ... ==> Integrity service for
>media data is ... or Integrity services for media data are ...
>
>37. After Appendix F
>
>There are five definitions. These should be moved to Section 4. Or
>are they a part of Appendix F?
>
>---------< Thank you for your attention. >---------
>
>
*************************************************************************
*** +1-503-264-8816(voice) +1-503-264-3485(fax) ***
*** jtoga at ibeam.intel.com Intel - Hillsboro, OR. ***
*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41***
*************************************************************************
More information about the sg16-avd
mailing list