Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
John Mattsson <john.mattsson@ericsson.com> Wed, 25 February 2015 08:48 UTC
Return-Path: <john.mattsson@ericsson.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 F0AC81A702F; Wed, 25 Feb 2015 00:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 5yUQvElJfM5z; Wed, 25 Feb 2015 00:48:52 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B751A7026; Wed, 25 Feb 2015 00:48:50 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-41-54ed8c705226
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.94.24955.07C8DE45; Wed, 25 Feb 2015 09:48:48 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.112]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 09:48:48 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
Thread-Index: AQHQQh5oJgFl6m3W+E63IOWS9grYL5zoLHSAgAC2aACAAPjAgIAH4VuAgAZou4CABsLbgIABO96AgAD2VAA=
Date: Wed, 25 Feb 2015 08:48:47 +0000
Message-ID: <28669AE0-DF31-4910-BD97-5B319BFD1398@ericsson.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> <D110E1BC.4501E%mzanaty@cisco.com> <D11204EC.452EF%mzanaty@cisco.com>
In-Reply-To: <D11204EC.452EF%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_28669AE0DF314910BD975B319BFD1398ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM+JvjW5Bz9sQg72fjS1e9qxkt1j57Tqr xdojiRYz/kxktri66g+7xYsHc5gspu+9xu7A7jHl90ZWj7XdV9k8liz5yeTx5fJntgCWKC6b lNSczLLUIn27BK6MQ0desRZsPc1YcWDLfZYGxqZjjF2MnBwSAiYS/77vYYKwxSQu3FvP1sXI xSEkcIRR4tD8DnYIZwmjxPVXz1lAqtgEDCTm7mkAqxIRmMAo8f/vFWYQh1lgCpPEmZVdzCBV wgIZEj/737KC2CICmRJH386HspMknu78AraPRUBV4sbGF2BxXgF7iU8dq1gg1u1llZh/+gc7 SIJTQF9i7+PtYDYj0IHfT60Ba2YWEJe49WQ+1OECEkv2nGeGsEUlXj7+xwphK0pcnb4cqj5Z 4tXv2cwQywQlTs58wjKBUXQWklGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofsELaGROucuVC2 tcS2AyeYkdUsYORYxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREY1Qe3/FbdwXj5jeMhRgEO RiUe3gLFNyFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCU mK7/LPfri+9shm97Xi3n0Uy6VO+Xf678WcRped27+04JSP8TdnwbJFba6G9ju7JSS+q8zBXO T98muH+YzvNR7eqFG959tw3OOX9P2uZxdSqX0YmHHZdWd9521rLlPLHK/LFSt4eg8FH/S8aP 1YunH+76s0hKVYM9RF323hfPGb45edYZD38rsRRnJBpqMRcVJwIA7cW2I8sCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/TYYcAPIw8hsXKdzBcch_QsUGk0M>
Cc: "avtcore-chairs@tools.ietf.org" <avtcore-chairs@tools.ietf.org>, "David McGrew (mcgrew)" <mcgrew@cisco.com>, "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: Wed, 25 Feb 2015 08:48:55 -0000
I am fine with keeping only the 6 suites suggested by David. On 2015-02-24 Mo Zanaty wrote: > I also agree with John that 64 bit auth tags are sufficient for SRTP even using GCM. The reason GCM_64 was removed was because I pointed out that the draft should follow the NIST requirements in SP 800-38D, Appendix C. Kevin and David chose to remove GCM_64 instead. Cheers, John On 24 Feb 2015, at 19:07, Mo Zanaty (mzanaty) <mzanaty@cisco.com<mailto:mzanaty@cisco.com>> wrote: I would like to point out the strongest argument for the sufficiency of 64 bit auth tags, taken directly from the SRTP RFC. http://tools.ietf.org/html/rfc3711#section-9.2 ...when 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s)… Note: in most typical applications (assuming at least one RTCP packet for every 128,000 RTP packets), it will be the SRTCP index that first reaches the upper limit, although the time until this occurs is very long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is enough to secure approximately 4 months of communication. This should make it clear that any potential weakness in GCM auth that reduces the effective strength of 64 bit auth tags by 7-12 bits (for 2-64 KB packets) is moot due to the SRTCP 31 bit limit and SRTP 48 bit limit. An attacker would hit rekey criteria before achieving 0.1% chance of a single successfully forged packet (of chosen cipher text but random plain text since decryption keys are not compromised). DOS criteria would likely be hit much sooner at such extreme numbers of packets. Furthermore, this reduced effective strength of auth tags only applies against attacks which are anyway impossible in SRTP due to no auth failure feedback. So 64 bit auth tags should be sufficient for SRTP applications. (As long as the auth transform has no truncation issues.) Mo On 2/23/15, 6:16 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote: 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 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Stephen Farrell
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Stephen Farrell
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Martin Thomson
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Alissa Cooper
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… John Mattsson
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… David McGrew
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Igoe, Kevin M.
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Stephen Farrell
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Stephen Farrell's Discuss on draft-… John Mattsson