Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Mon, 23 February 2015 23:16 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CCA1A1A62; Mon, 23 Feb 2015 15:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUuE2Ofq52KX; Mon, 23 Feb 2015 15:16:41 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C147C1A1A45; Mon, 23 Feb 2015 15:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4065; q=dns/txt; s=iport; t=1424733400; x=1425943000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7oKSRzk4xNcnC65Qx//foYge+coLDLPO3XkQEnhEtvQ=; b=dBT1I4pnsJxyteF1lpzOWOQvd5cyiSATp9HwytT7gB7OIWDFxc0xA/4Z YpftaTk7qZL4UZmjNnRAaEe8+rAXbmkx6/HPcBB/pwtVFKFMRA9JJ/bvP +rUzRTlkl7W0dvEGM6JX/fKP3azI+zkxOokRpc3Sa1SBEhcbfJ6CFVb+9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ApBQDOs+tU/5BdJa1bgwZSWgTDCwqFcAKBJEMBAQEBAQF8hBABAQQBAQEJbQ4CAgEIGCcHGwwLFBECBAENBYgvDdMsAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEiw+EbgeEKwWFYoQ6hTaJQ5MzIoIygTxvgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.09,634,1418083200"; d="scan'208";a="398501850"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 23 Feb 2015 23:16:40 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1NNGeuc004409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Feb 2015 23:16:40 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 23 Feb 2015 17:16:39 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "David McGrew (mcgrew)" <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>
Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
Thread-Index: AQHQT77GzgiGf2lZgk+Ajujhv6SsqA==
Date: Mon, 23 Feb 2015 23:16:39 +0000
Message-ID: <D110E1BC.4501E%mzanaty@cisco.com>
References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <B1821703-9D09-41C5-AAC1-5EBB9CE2ACC4@cisco.com> <54516572.8020601@cs.tcd.ie> <D825D4F3-26D3-49BE-9E32-0E4FFF89BC40@cisco.com> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <E1F851A6-B098-4F8C-8AE1-B88BD1E1DCD9@cisco.com> <54E608E5.1070102@ericsson.com>
In-Reply-To: <54E608E5.1070102@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.150.30.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <BB9BD8E2D2E7BD4AA33460558CA01302@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/7LeXqfrSjORlb9RNO3_WW35lG3k>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "avtcore-chairs@tools.ietf.org" <avtcore-chairs@tools.ietf.org>, "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" <draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org>, IETF AVTCore WG <avt@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 23 Feb 2015 23:16:42 -0000

I am fine with keeping only these 6 suites by eliminating 96 bit auth tags.

However, I do wonder if any SRTP application will ever use CCM with full
length tags or 256 bit keys, rather than using GCM. If not, another 3
suites can be eliminated, leaving only 3 suites:

AEAD_AES_256_GCM
AEAD_AES_128_GCM
AEAD_AES_128_CCM_8/64

I also agree with John that 64 bit auth tags are sufficient for SRTP even
using GCM. The NIST recommendation is key rotation after roughly 2^40
packets of 1.5 KB, which is many years for a 100 Mbps SRTP stream! And
this is to protect against an attack where the receiver/victim notifies
the sender/attacker of every auth failure, which is not possible in SRTP
since no such feedback exists. And as John mentioned, the DOS of so many
forged packets and auth failure messages would be a much worse consequence
than compromising the auth tag.

So I would also be fine with only 64 bit auth tags for both GCM and CCM.

AEAD_AES_256_GCM_8/64
AEAD_AES_128_GCM_8/64
AEAD_AES_128_CCM_8/64

If we go this final route, I suggest updating section 14.2 with a table
for 1.5 KB packets (not just 64 KB), and more concrete guidance on what
the security ramifications are. In particular, that these (many) forgeries
can only inject random data since the decryption key is unknown. That is,
they inject a chosen cipher text but a random plain text after decryption
since the decryption key is unknown and not compromised by this auth key
attack. The security ramifications of this auth key attack are minor in my
opinion, especially relative to the major denial-of-service caused by so
many forgeries and auth failure feedback.

I would not be fine with anything less than this. One GCM is not
sufficient, we need both 128 and 256 bit keys. GCM is not sufficient, we
also need CCM (128_8/64).

Mo



On 2/19/15, 11:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com>
wrote:

On 2015-02-15 15:09, David McGrew wrote:
> 
> My opinion is: it would be best to preserve the existing specification
> and implementation work, and retain all ten crypto suite definitions.
> But if we want to make SRTP-AEAD be the first instance in which the IETF
> will  prioritize simplicity over variety and diversity, I¹m good with
> that, because I certainly see the value of simplicity; then my
> recommendation would be to eliminate the four 12-octet authentication
> versions.  That would leave just six crypto suites, with two different
> modes of operation, two different key sizes, and two different tag
> lengths (but not all tag lengths for all modes), like this:
> 
>       srtp-crypto-suite-ext = "AEAD_AES_128_GCM"    /
>                               "AEAD_AES_256_GCM"    /
>                               "AEAD_AES_128_CCM"    /
>                               "AEAD_AES_256_CCM"    /
>                               "AEAD_AES_128_CCM_8"  /
>                               "AEAD_AES_256_CCM_8"  /
> 

Stephen, WG

Having looked at the feedback provided in this discussion so far, I
think the above set of 6 are a reasonable selection without unduly
limiting functionality, but removing the four least necessary profiles.

My proposal is that if no one is disagreeing with this in the next week
(Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a
discussion at the informal IESG telechat on how to proceed.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt