Re: [secdir] Security review of draft-thornburgh-adobe-rtmfp-07

[Michael Thornburgh <[e-mail]>]

> From: Uri Blumenthal [mailto:[e-mail]]
> Sent: Tuesday, June 25, 2013 5:11 AM
> 
> Leaving alone everything else - there was no better encryption mode for streaming data (I assume Flash
> would be streaming?) than CBC? And what's the purpose of encrypting something with a key shared with
> the entire Universe?

as mentioned in this thread, Section 2.2.3, descriptions of the startup chunks, and the Security Considerations of the memo, the Default Session Key is used at session startup, during which per-session encryption keys are negotiated.  also as mentioned in this thread and the Security Considerations, the startup handshake is encrypted with the Default Session key to scramble startup packets to avoid meddling by middleboxes, to obscure the content from casual observation, and to act as a spread-spectrum or subchannel code for different RTMFP applications that might be sharing a transport channel.

> I think you're expecting too much from "error discovery" of CBC mode. Also, for the last two decades
> cryptographers insist that the correct way of MACing is applying outer MAC. Also, especially
> considering the capabilities of the later Intel chips, using HMAC after (or before:) encryption is a
> waste of time - there are fast Authenticated Encryption modes (GCM and OCB, to name a couple).

in the Flash profile, the MAC is an outer MAC.  when HMAC mode is not selected, there is a simple inner checksum.  the inner checksum is at least as good as a checksum over a normal unencrypted packet.  as far as detecting whether a packet was encrypted with an incorrect key in checksum mode: even if the checksum succeeded, the likelihood that the incorrectly decrypted packet could parse correctly even to a first complete and valid chunk is very low.
 
> So far I tend to agree with Hillary, and suggest using DTLS.
> 
> Yours in confusion...

HTH.  i invite you to read the entire memo.  note that this memo documents an existing and widely deployed vendor-supplied protocol.  note also that this memo doesn't describe the cryptography profile used by Flash (including AES-CBC, HMAC, and anti-replay measures).

-michael thornburgh


> Sent from my iPad
> 
> On Jun 24, 2013, at 14:32, Michael Thornburgh <[e-mail]> wrote:
> 
> > hi Hilarie.  thanks for your review.  comments/replies inline.
> >
> >> From: Hilarie Orman [mailto:[e-mail]]
> >> Sent: Friday, June 21, 2013 10:05 AM
> >>
> >> Security review of
> >> Adobe's Secure Real-Time Media Flow Protocol
> >> draft-thornburgh-adobe-rtmfp-07
> >>
> >> Do not be alarmed.  I have reviewed this document as part of the
> >> security directorate's ongoing effort to review all IETF documents
> >> being processed by the IESG.  These comments were written primarily
> >> for the benefit of the security area directors.  Document editors and
> >> WG chairs should treat these comments just like any other last call
> >> comments.
> >>
> >> This is an informational RFC describing an existing Adobe protocol.
> >> It has the feature of allowing sessions to change their IP addresses
> >> and to use forwarders to help in NAT traversal.
> >>
> >> The draft does not specify the cryptographics requirements and
> >> processing in enough detail to facilitate interoperable
> >> implementations, and I don't recommend advancing it.
> >
> > this draft describes a generic framework of cryptographic operational semantics with requirements
> and recommendations.  the generic framework is a common part of RTMFP and belongs in this
> specification.  specific cryptography choices are left to applications/profiles of RTMFP.  the
> intention is that application-level interoperation would be achieved using this specification and a
> specification of the application-specific Cryptography Profile; for example, a specification
> describing the Cryptography Profile to be used for Flash platform communication.
> >
> >> The draft generically specifies the cryptographic features that would
> >> provide privacy and authentication.  All specifics are left to the
> >> implementor.  The cryptographic profiles could be trivial (rot13 and
> >> casting out nines, for example).
> >
> > correct. for testing/development of the RTMFP implementation used in Adobe's products, i created a
> "Null Crypto Adapter" implementing (NOT RECOMMENDED) straight-copy for the "Packet Encryption"
> function, and a trivial session-specific key to salt a simple checksum for "data integrity".  this
> profile/adapter met the semantic requirements of a Cryptography Profile but was not suitable for any
> circumstance where actual aspects of security were desired.  however, it made debugging using a packet
> sniffer a lot easier!
> >
> >> How is the cryptographic profile specified?  Is there only one, to be
> >> used by all implementations RTMFP?  If not, how do two implementations
> >> agree on which profile they will use?
> >
> > a Cryptography Profile would be specified in another document.  the intention is that there could be
> different Cryptography Profiles for different applications or uses of RTMFP.  there is one defined for
> Flash platform communication, which has features uniquely tailored to the Flash ecosystem; however,
> specifics of this are unfortunately not currently publicly disclosed.  i agree that it would be
> valuable to have this profile available as a concrete example; however, i don't have permission to
> publish it at this time.  i considered designing a new cryptography profile to use as an example, but
> it would have no real-world implementation or deployment experience behind it and would not have the
> benefit of the years of refinement and experience we have with the Flash profile.  publishing such an
> example would probably encourage people to implement it, even though it could have serious flaws.  i
> concluded that creating a new example profile was a bad idea.
> >
> >> How is the "default session key" selected?  The text mentions the
> >> possibility of multiple default keys.  In "Security Considerations":
> >>   ... to allow for different applications of RTMFP using different
> >>   Default Session Keys to (intentionally or not) share network
> >>   transport addresses without interference.
> >> I don't see how this could work.
> >
> > the Default Session Key is chosen by the designer of the Cryptography Profile.  for example, in the
> Flash Crypto Profile, the Default Session Key is the 16 bytes of the UTF-8 coded string "Adobe Systems
> 02" (note: this has been widely known for years and is not a secret).  these 16 bytes form the raw key
> for AES-128-CBC, which is the default (and currently only) cipher used in the Flash Crypto Profile.
> >
> > as far as two RTMFPs using the same network transport address, think of the different Default
> Session Keys as different spread-spectrum spreading codes.  if used with something like AES-128-CBC,
> then even a "data integrity" check comprising an interior checksum would be enough to reject as
> corrupt a packet using the wrong Default Session Key.
> >
> >> What is the algorithm for encrypting with the default session key?
> >> Note that the crypto profile is supposed to determine the keys, but
> >> there is not necessarily an interface that accepts a default key
> >> and produces usable encryption and integrity/authentication keys.
> >
> > the Cryptography Profile also determines the method of encryption (Section 2.2.3 first sentence).
> in the case of Flash communication, this method is AES-128-CBC, and would be fully specified in the
> "RTMFP for Flash" document, were it published.
> >
> >> Is there any response for "endpoint discriminator unacceptable"?
> >
> > section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discriminator selects the
> identity of the responder.  see sections 3.5.1.4 and 3.5.1.5 for possible behavior for when an
> Endpoint Discriminator does not select the identity of the responder.
> >
> > there are no chunks or other messages to encode "i received an EPD i didn't like for one reason or
> another".  what to do in this circumstance is intentionally not specified and is left to the
> implementer's discretion.  in the Adobe implementation, an IHello or FIHello with an EPD that doesn't
> select the receiver (including because it's malformed) is silently dropped (except in
> forwarders/redirectors).
> >
> >> I did not see any "MUST" requirements for rejecting data that fails to
> >> pass cryptographic checks.
> >
> > i will add a statement to that effect in Section 2.2.3 3rd paragraph.
> >
> >> How are message integrity and authentication achieved?  Is it required?
> >> Section 2.2.3 says:
> >>   "The packet encryption layer is responsible for data integrity and
> >>   authenticity, for example by means of a checksum or cryptographic
> >>   message authentication code."
> >> That does not seem to require that the message integrity be tied to
> >> the Endpoint Discriminator.
> >
> > by "message integrity" i assume you mean "data integrity" in the context of packets.  data integrity
> is not tied to the EPD.  the EPD is a field interior to the packet, which must be tested for integrity
> before being parsed.  in the sentence you quoted above, i will add "of packets" after "integrity and
> authenticity" and before the comma.
> >
> > in general, (packet) data integrity and authenticity is left to the designer of the cryptography
> profile. in the case of Flash communication, this is achieved using either an (interior) checksum or
> an (exterior) HMAC, the choice being determined during the IIKeying/RIKeying phase of the startup
> handshake in the respective Keying Components, and in the case of HMAC, the HMAC key being derived in
> a manner similar to how the packet encryption key is derived.
> >
> >> Is there anti-replay prevention?  I cannot tell.  There are sequence
> >> numbers, but they could be spoofed under some definitions of the
> >> cryptographic profile.
> >
> > anti-replay prevention is part of "data integrity and authenticity".  in the case of Flash
> communication, a "Session Sequence Number" can be enabled (during the IIKeying/RIKeying phases,
> similar to how HMAC/simple checksum is selected) to prevent packet replay.  i will add a RECOMMENDED
> about anti-replay in SS2.2.3PP3.
> >
> > flow sequence numbers prevent anti-replay (and enable retransmission) within a current flow;
> however, an observer could capture a packet that starts a new flow (using traffic analysis to figure
> out what packet that was), and later, after using traffic analysis to infer that flow is concluded,
> could replay that packet to potentially start a new flow with the same flow ID (or interfere with a
> new flow with the same ID).  i will add something to the Security Considerations about that, to
> further make the case for implementing packet-level anti-replay.
> >
> >> Section 2.2.2:
> >>   "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by
> >>   performing a bitwise exclusive-or with the bitwise exclusive-or of
> >>   the first two 32-bit words of the encrypted packet."
> >> This is security-by-obscurity and is not worth the trouble.
> >
> > disagree with the characterization of "security-by-obscurity" and that it's not worth the trouble.
> the intention is to make every byte of UDP payload appear to a casual observer (and especially to a
> meddling middlebox) to be random noise.  RTMFP is intended to be used with a strong cipher (like AES),
> where every ciphertext byte appears pseudorandom.  during startup, the Session ID is 0, and during the
> rest of the session it is a fixed non-zero value.  without the scrambling operation, there would be a
> tasty and consistent 4-bytes that a middlebox might want to interpret as an IP address or something,
> or otherwise meddle with.  if we XORed with only the first 4 bytes, then during startup (with SID 0)
> the first 4 bytes would be the same as the second 4 bytes.  XORing with two 32-bit words (where those
> 64 bits are strongly pseudorandom in the case of AES) ensures that the first 4 bytes at least don't
> match the next 8.
> >
> > note that it's not security-by-obscurity because it's documented.  :)  note also that even if it's
> not worth the trouble, it *is* how this deployed protocol actually works.
> >
> >> The Security Considerations admit that the Default Session Key is such
> >> a weak measure that all messages that use it should be considered to
> >> be sent in the clear.  It isn't worth the trouble of using it.
> >
> > disagree. the Security Considerations section states that the Default Session Key is intended to
> scramble startup packets to avoid meddling by middleboxes, to obscure the content from casual
> observation, and to act as a spread-spectrum or subchannel code for different RTMFP applications that
> might be sharing a transport channel.  this is particularly important because startup packets can
> contain IP addresses and port numbers.  i disagree with the characterization as "admit [...] such a
> weak measure" -- the Security Considerations states the intent and disclaims (with a "MUST NOT") any
> security aspect to it.
> >
> >> There are robust IETF security protocols that could be layered over RTMFP.
> >
> > true.  RTMFP could also be adapted to be encapsulated in DTLS.
> >
> >> I recommend removing all references to cryptography from this
> >> document.
> >
> > disagree. the generic (and intentionally open-ended) cryptographic framework is an essential
> semantic aspect of the protocol.  the normative semantics described in this document are common to any
> application of RTMFP.
> >
> >> Hilarie
> >
> > thank you very much.
> >
> > -michael thornburgh
> > _______________________________________________
> > secdir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview