Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft

Magnus Westerlund <> Wed, 01 June 2011 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9E44E0692 for <>; Wed, 1 Jun 2011 04:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 50rVruuy9ZxY for <>; Wed, 1 Jun 2011 04:36:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 03816E0670 for <>; Wed, 1 Jun 2011 04:36:20 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-93-4de62433d95d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D9.74.20773.33426ED4; Wed, 1 Jun 2011 13:36:20 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 1 Jun 2011 13:32:42 +0200
Message-ID: <>
Date: Wed, 01 Jun 2011 13:32:42 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Glen Zorn <>
References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, "Igoe, Kevin M." <>
Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2011 11:36:22 -0000

On 2011-06-01 12:26, Glen Zorn wrote:
> On 6/1/2011 3:09 PM, Magnus Westerlund wrote:
> ...
>> My immediate reaction is if one can define profiles that are not SuiteB
>> but use the same encryption and authentication algorithm so they are bit
>> compatible, but not policy compatible?
> My understanding is that Suite B is all about policy & packaging; no new
> algorithms are defined (thankfully!).

I am not certain about that. RFC 6188 appears to define the crypto part
matching SuiteB requirement for SRTP, but not the authentication
algorithm, thus from an SRTP perspective there appear to be new stuff in

I am uncertain if there is differences between the PRF for the RFC 6188
and the SuiteB draft.

So, this specification clearly brings new combinations of encryption and
authentication and might in fact be a completely new crypto suite if the
PRF is different with RFC 6188.

The question I have to the WG is if it is worth handling the actual SRTP
crypto transform defintion from the actual profiles and the additional
requirements on key management. Thus allowing the usage of the crypto
transforms themselves outside of a SuiteB context, which clearly can't
be called SuiteB but which for example is AES-256 with SHA-256 in SRTP
and some other key management.

>> Independent I think you need to make it clear in the document that
>> SuiteB does contain these policy rules.
> I don't really understand this comment: the very first sentence of the
> Abstract says The United States government has published guidelines for
> "NSA Suite B Cryptography", which defines cryptographic algorithm policy
> for national security applications.
> ^^^^^^
> I don't know how it could be made much clearer or more obvious.
> ...

What I meant is the fact that SuiteB key management is not allowed to
use Security Descriptions nor MIKEY per policy. The stress on the quoted
sentence are "these" where "these" referring to forcing usage of DTLS.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: