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

[Harald Alvestrand]

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; rtc-web at alvestrand.no; 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20101226/e9965c9e/attachment.html>