[AVTCORE] Observation in RFC 3711

Christian Oien <coien@cisco.com> Fri, 16 August 2013 12:39 UTC

Return-Path: <coien@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1C8B211E8271 for <avt@ietfa.amsl.com>; Fri, 16 Aug 2013 05:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NCFPzrTz2I8j for <avt@ietfa.amsl.com>; Fri, 16 Aug 2013 05:39:02 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id B960411E8270 for <avt@ietf.org>; Fri, 16 Aug 2013 05:39:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6225; q=dns/txt; s=iport; t=1376656742; x=1377866342; h=message-id:date:from:mime-version:to:subject; bh=uXc0F4QzITefx/O3mOx9cb5gvOjvw11LCcmyf6ij/3c=; b=H4m1+B6gm3FPzAGOmA+6D4jLKDdbTIfUe8T6lVEwxcQYjwPuUYUv/gjc wW6o8ru7DnEwHLUSONBduhtiTdLx8sxeipBKX3/WRvFNAjFrAW1wwkGl4 t4tEYubpwvtvzTfWvvtMvZbwjW/Y32F8a6pD53+68QvkQlX4DkZ4JuSW5 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAIccDlKtJXG9/2dsb2JhbABbgwaBBoh3t0sWdIMjPRYYAwIBAgFLDQgBAYgMmUagKpRpA4h1jm+GKYssgx6CKA
X-IronPort-AV: E=Sophos; i="4.89,895,1367971200"; d="scan'208,217"; a="248190739"
Received: from rcdn-core2-2.cisco.com ([]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2013 12:39:00 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7GCd0M7005168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <avt@ietf.org>; Fri, 16 Aug 2013 12:39:00 GMT
Received: from [] ( by xhc-aln-x12.cisco.com ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 16 Aug 2013 07:38:59 -0500
Message-ID: <520E1D77.4030101@cisco.com>
Date: Fri, 16 Aug 2013 14:39:19 +0200
From: Christian Oien <coien@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: <avt@ietf.org>
Content-Type: multipart/alternative; boundary="------------040406010709080503050104"
X-Originating-IP: []
Subject: [AVTCORE] Observation in RFC 3711
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2013 12:39:20 -0000

Hello WG,

After reading RFC 3711, and making an implementation in the context of RFC
4568 for the default ciphers, and then, afterwards, looking at a couple of
existing implementations, I have come to the conclusion of having found
a mismatch between the specification and the existing implementations,
including libsrtp.

RFC 3711 section "4.3 Key Derivation" describes a formal operator DIV,
with a result having the same number of bits as its first operand.
For SRTP the first operand is the SRTP packet index, which is a 48-bit
quantity, meaning that the <label> will have 48 bits to its right XOR'ing
with master_salt.

In subsection "4.3.2 SRTCP Key Derivation" the text says "Replace the
SRTP index by the 32-bit quantity" which means that the DIV operator will
yield a 32-bit quantity.  Following the specification of key_id for SRTCP
the <label> will have 32 bits to its right when XOR'int with master_salt.

The implementations, including libsrtp, invokes this XOR with the
<label> at the same position as for SRTP.  According to the specification
this should be done 16 bits to the right of this, when invoking for SRTCP.

It seems to me that the most pragmatic thing to do is to update the
specification, not the implementations.  But any new implementer
will fail to exchange any SRTCP with software using e.g. libsrtp.
This prevents any i.e. PLI of being communicated.  The consensus of not
following the specification, has the same implication for [ DTLS ] as for
security-description key-derivation input, namely that all SRTCP session
material is non-compliant and thus implementers reading the specification
instead of a reference-implementation, will fail.

In support of making an errarta for update of RFC 3711 is that
the specifications way of doing this has, according to itself, has a
cryptographic weakness, related to the rationale of having the <label>.
I am not sure about the implications of this weakness, but it seems like
support for *not* following specification as its current text strictly
instructs via its DIV operator and the 32-bit quantity :  Re-keying
(non-zero key_derivation_rate as opposed to RFC 4568 ciphers) with
SRTP packet index 196608 gives identical encryption key as for SRTCP,
in the case that e.g. none of the latter has yet been sent (index zero).
The implication of any key-stream re-use was the reason of having <label>.

  - Christian S Oien