<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/23/10 10:44, Ingemar Johansson S wrote:
<blockquote
cite="mid:DBB1DC060375D147AC43F310AD987DCC22B1CF239D@ESESSCMS0366.eemea.ericsson.se"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta content="MSHTML 6.00.6001.18527" name="GENERATOR">
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">Hi Justin</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">In some sense you are
very right but I make a slightly different interpretation. </font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">Quoting section 4 in
RFC3711</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">"<span lang="SV"><font
color="#000000">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.</font></span>"</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">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.</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">Now I don't say that
this is _the_ interpretation, please correct me if
neecessary.</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">I don't intend to
enter a heated debate about which codecs should be used. </font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">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 ?</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">I don't have the
answers, hope that some of the "grey-beards" can chime in
and give some guidance later on.</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">Regards and happy
holidays </font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"><font
color="#0000ff" face="Arial" size="2">/Ingemar</font></span></div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<div dir="ltr" align="left"><span class="356261309-23122010"></span> </div>
<br>
<div class="OutlookMessageHeader" dir="ltr" align="left"
lang="en-us">
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Justin Uberti
[<a class="moz-txt-link-freetext" href="mailto:juberti@google.com">mailto:juberti@google.com</a>] <br>
<b>Sent:</b> den 22 december 2010 17:15<br>
<b>To:</b> Ingemar Johansson S<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:dispatch@ietf.org">dispatch@ietf.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</a>;
<a class="moz-txt-link-abbreviated" href="mailto:Markus.Isomaki@nokia.com">Markus.Isomaki@nokia.com</a><br>
<b>Subject:</b> Re: [RTW] [dispatch] Fwd: New Version
Notification for draft-alvestrand-dispatch-rtcweb-protocols-00<br>
</font><br>
</div>
Ingemar,
<div><br>
</div>
<div>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.</div>
</blockquote>
Ingemar,<br>
<br>
I think you misinterpret RFC 3711 slightly.<br>
<br>
More important than the text you quote is the text in section 5 of
RFC 3711:<br>
<br>
<span class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="border-collapse: collapse;
font-family: Verdana,Geneva,Arial,Helvetica,sans-serif;
font-size: 13px;">
<pre style="font-size: 11pt; font-family: 'Courier New',monospace; margin-bottom: 0px;"><span style="font-weight: bold;">5. Default and mandatory-to-implement Transforms</span>
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.
</pre>
</span></span><br>
<blockquote
cite="mid:DBB1DC060375D147AC43F310AD987DCC22B1CF239D@ESESSCMS0366.eemea.ericsson.se"
type="cite">
<div><br>
</div>
<div>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.<br>
</div>
</blockquote>
I completely agree with your reasoning here.<br>
<br>
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).<br>
<br>
Harald<br>
<br>
</body>
</html>