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

Magnus Westerlund <> Wed, 01 June 2011 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACEB1E07FD for <>; Wed, 1 Jun 2011 06:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.307
X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zhZd+tWZOt+U for <>; Wed, 1 Jun 2011 06:57:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65E2BE07FE for <>; Wed, 1 Jun 2011 06:57:23 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ea-4de64542e731
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A2.D1.20773.24546ED4; Wed, 1 Jun 2011 15:57:22 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 1 Jun 2011 15:57:22 +0200
Message-ID: <>
Date: Wed, 01 Jun 2011 15:57:21 +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 13:57:37 -0000

Glen and Kevin

Please see inline.

On 2011-06-01 15:12, Glen Zorn wrote:
> On 6/1/2011 6:32 PM, Magnus Westerlund wrote:
>> On 2011-06-01 12:26, Glen Zorn wrote:
>>> On 6/1/2011 3:09 PM, Magnus Westerlund wrote:

>> 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.
> [disclaimer: I am _not_ a cryptographer!]
> RFC 6188 specifies the use of AES-CM (AKA AES-CTR) with 192- and 256-bit
> keys for the encryption of data, but the draft in question specifies the
> use of AES-GCM with 128- and 256-bit keys.  My understanding is that CM
> & GCM are significantly different; in addition, 6188 uses HMAC-SHA1 for
> authentication, while the use of AES-GCM obviates the need for a
> separate authentication function.  So it appears to me that a new
> cryptosuite is being defined, regardless of whether or not the PRF is
> identical...

Yes, I agree with that assessment. It is a new crypto suite, I missed
the CM vesus GCM difference. I am also not a cryptographer.

But the procedural point here is that they SuiteB does define a not
previous existing definitions of combinations of crypto operations in
the SRTP context.

>> 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.
> Maybe I'm just dull, but I'm still not getting the point.  It looks to
> me as if the authors are just stating what it will take to get an SRTP
> implementation approved for US government usage in certain situations.
> Why would you want to tell them that they can't?  Further (if my
> presumption is correct), why is it necessary for the document to go
> through this WG at all, given the intended status of Informational?  If
> avtcore wants to specify a million different ciphersuites that's fine,
> but what does it have to do with this draft?

Lets separate the issues here. The first one is if they need to go
through the WG. I think to be strictly correct they are not required to
go through the WG. The only procedural point they are strictly required
to meet are the one of the DTLS protection profiles, which is
specification required. So NSA could based on a NIST specification with
all these details that are in the draft request IANA to register the
DTLS protection profile identifiers.

I do however hope they are here for getting a bit of IETF review of it
and the potential benefit in visibility for the profiles by having an
RFC. So assuming that they want an RFC:

The draft is defining procedures for SRTP crypto transforms that doesn't
exist before. If someone like to reuse those for other key management
systems like Mikey or Security Descriptions they need something to
reference. It would be preferable that this is published as an RFC. And
maybe we should discuss intended status also.

I also don't think I have said anything that they can't get it done. I
have only raised a few things that I think the WG should discuss. And
the reason for that is the following charter text for this WG:

The AVTCORE working group will coordinate closely with the Security Area
while working on maintenance and enhancements to the SRTP Profile.

I would claim that new crypto suits are "enhancements" to SRTP and thus
falls under the this charter item if they want to publish an RFC.

There is an downside to a large amount of crypto suits as it hurts
interoperability. At the same time I think we need to be very permitting
against different nations desire to define how their national standards
are used in SRTP.

>>>> 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. 
> I'm not sure that it is solely a matter of policy; does MIKEY have a
> profile that uses elliptic-curve cryptography?  IIRC, that was
> intentionally omitted due to IPR concerns.  Furthermore, SDP is an
> unauthenticated protocol.

I fully understand that there are security concerns here also. And it
depends on the whole combination in the system if it meets the security
requirements one has. From that perspective I am understanding why
SuiteB defines DTLS only.

Please understand that the main case I try to avoid is that we get
unnecessarily many crypto suit definitions when in a SuiteB and "foobar"
specification both uses AES-256 CGM and SHA-256 authentication but in
fact has different definitions of everything that has to do with SRTP
except the underlying crypto algorithms. I rather see that foobar can
reuse most aspect of it and just have its own variations for certain


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: