hi Ben. comment inline.
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: Wednesday, June 26, 2013 1:04 PM
Hi Michael,
Thanks for the continued responses. A few more comments inline. I deleted
sections that did not seem
to need further comment. In summary, all of my concerns are resolved except
for the crypto profile
question.
Thanks!
Ben.
On Jun 26, 2013, at 2:00 PM, Michael Thornburgh
<mthornbu(_at_)adobe(_dot_)com> wrote:
[...]
yes, endpoints need a common cryptography profile to interoperate. there
is no repository for
crypto profile documentation at this time. currently, there is one defined
cryptography profile
(the
one used for Flash communication) that is not publicly documented, because
i do not yet have
permission to publish it. i (meaning me personally) hope that a memo
documenting the
crypto/application profile for Flash communication (as being a widely
deployed and used profile for
RTMFP) would also be published someday as an I-D and hopefully an
Informational RFC.
I understand the issue about permission to publish, but does this document
serve its purpose until
you
are ready to publish the crypto profile? Ideally they would be published
together and this document
would reference that one. Do I infer correctly that there is no way
someone could create an
implementation that interops with Adobe products based on the documents
available at this time?
additional documentation is needed to interoperate (at the application
layer) with the Adobe
products that implement RTMFP. i hope that the successful publication of this
memo will help me in
getting the necessary approval to publish the higher layer details of Adobe's
RTMFP ecosystem.
the situation is analogous to having published TCP, but there's a lot more
you need to know to talk
to a web server with HTTPS (like TLS and HTTP). it's still useful to know
how TCP works, and plenty
more to do with it than talk to web servers.
I don't think that's a fair analogy. I can use TCP for many purposes other
than talking to web
servers. It can even be useful all itself. But if I understand correctly, you
can't expect to use
RTMFP _at_all_ until you publish they crypto-profile(s). Is that correct? If
so, a better analogy
would be to publish TLS without any published cryptosuites.
If I am correct on the inability to use the protocol at all without more
documentation that does not
currently exist, then I think it would be reasonable to put a clearly worded
assertion to that effect
early in the draft, along with a comment that you intend to publish at least
one crypto profile in the
future. (Perhaps an applicability statement would be helpful here.)
interoperating with the Flash ecosystem requires additional documentation. i
agree that a better analogy is publishing TLS without any published
cryptosuites.
using RTMFP requires _a_ cryptography profile. this memo describes the required
semantics of a cryptography profile. the first bullet of Section 1.1 "Design
Highlights" (which occurs on the first page after the TOC), Section 2.2.3
"Encryption", and the first paragraph of the Security Considerations section
all indicate that this protocol defines a general framework for security, and
that the application designer chooses/defines the algorithms and data formats
to be used within that framework. an application designer could, using only
this memo (and knowledge of security and cryptography principles), define her
own cryptography profile suitable for her application of RTMFP, and create a
correct and useful RTMFP application.
since i don't yet have permission, i can't make a commitment in this memo that
Adobe will (or intends to) publicly document any additional layers of the
RTMFP-in-Flash ecosystem. just for extra clarification: it is my *personal*
hope that i will be able to do so in the future.
[...]
thanks!
-michael thornburgh