[RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

[Ingemar Johansson S]

Hi

I must admit that I am a real bad reader, can only blame it on Santa... :-(

Tried to find some background info on AES-CTR and according to 
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/workshop1/papers/lipmaa-ctr.pdf
it was devised already in 1979, this probably explains a lack of IPR disclosure for RFC3711 (at least I have not found any)

Regards
Ingemar  

________________________________________
Från: Harald Alvestrand [harald at alvestrand.no]
Skickat: den 26 december 2010 00:11
Till: Ingemar Johansson S
Kopia: Justin Uberti; rtc-web at alvestrand.no; dispatch at ietf.org; Markus.Isomaki at nokia.com
Ämne: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

On 12/23/10 10:44, Ingemar Johansson S wrote:
Hi Justin

In some sense you are very right but I make a slightly different interpretation.

Quoting section 4 in RFC3711
"While there are numerous encryption and message authentication algorithms that can be used in SRTP, below we define default algorithms in order to avoid the complexity of specifying the encodings for the signaling of algorithm and parameter identifiers. The defined algorithms have been chosen as they fulfill the goals listed in Section 2. Recommendations on how to extend SRTP with new transforms are given in Section 6."
I don't interpret this as mandatory to implement said algorithms, rather I see this as something needed to make the RFC complete. The encryption can be negotiated out of band so an implementer can avoid said algorithms completely if he/she wants to.
Now I don't say that this is _the_ interpretation, please correct me if neecessary.

I don't intend to enter a heated debate about which codecs should be used.
My concern is more that it is not good to end up in a situation where a mandatory codec is specified in an IETF RFC and later on gets subject to some legal issues. What is the situation for the RFC then?, should the codec be demoted to optional in a new RFC that deprecates the old ?
I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on.

Regards and happy holidays
/Ingemar





________________________________
From: Justin Uberti [mailto:juberti at google.com]
Sent: den 22 december 2010 17:15
To: Ingemar Johansson S
Cc: dispatch at ietf.org<mailto:dispatch at ietf.org>; rtc-web at alvestrand.no<mailto:rtc-web at alvestrand.no>; Markus.Isomaki at nokia.com<mailto:Markus.Isomaki at nokia.com>
Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Ingemar,

RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as the default authentication algorithm for SRTP. As a result, those algorithms are used by pretty much every application that uses SRTP, which makes interoperability much easier.
Ingemar,

I think you misinterpret RFC 3711 slightly.

More important than the text you quote is the text in section 5 of RFC 3711:


5.  Default and mandatory-to-implement Transforms

   The default transforms also are mandatory-to-implement transforms in
   SRTP.  Of course, "mandatory-to-implement" does not imply
   "mandatory-to-use".  Table 1 summarizes the pre-defined transforms.
   The default values below are valid for the pre-defined transforms.

                         mandatory-to-impl.   optional     default

   encryption            AES-CM, NULL         AES-f8       AES-CM
   message integrity     HMAC-SHA1              -          HMAC-SHA1
   key derivation (PRF)  AES-CM                 -          AES-CM

   Table 1: Mandatory-to-implement, optional and default transforms in
   SRTP and SRTCP.

In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not
a conformant SRTP implementation.



I think a similar statement can be made regarding the selection of MTI video codecs. There are various reasons why one might choose one codec versus another. But if we are unable to pick at least one default/MTI codec (for each media type), interoperability and thereby adoption of this platform will be much more challenging.
I completely agree with your reasoning here.

Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link).

                         Harald