Re: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft
John Mattsson <john.mattsson@ericsson.com> Thu, 05 March 2015 17:26 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 917531A0382 for <avt@ietfa.amsl.com>; Thu, 5 Mar 2015 09:26:09 -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 rmjPsSrwYykx for <avt@ietfa.amsl.com>; Thu, 5 Mar 2015 09:26:07 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236B01A1BA2 for <avt@ietf.org>; Thu, 5 Mar 2015 09:25:39 -0800 (PST)
X-AuditID: c1b4fb3a-f79036d000001e94-0b-54f891919ddd
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E5.7E.07828.19198F45; Thu, 5 Mar 2015 18:25:37 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.112]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 18:25:37 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Thread-Topic: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft
Thread-Index: AQHQVN+IDiuRyXO3Gk667nz/Zy+CcJ0M1ZWAgABf0gCAANSbgIAAGpHD///zswA=
Date: Thu, 05 Mar 2015 17:25:37 +0000
Message-ID: <BB863753-4A43-4338-886C-774DC0B4806B@ericsson.com>
References: <54F44F2D.4060803@ericsson.com> <41578C3E-1AD2-4AFE-AC98-EEEC1BD77197@ericsson.com> <D11D217F.46FD4%mzanaty@cisco.com> <,<7303D044-CE4E-4ACF-B7F6-46D963CD1BC6@ericsson.com> <>> <85733DA9-9EFA-4D91-A988-C207FC6ED24A@cisco.com>
In-Reply-To: <85733DA9-9EFA-4D91-A988-C207FC6ED24A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_BB8637534A434338886C774DC0B4806Bericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM+Jvje7EiT9CDOacsbB42bOS3WLtkUSL Fw/mMDkwe0z5vZHVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKuN/ez17QFVbRsuIzWwPj c48uRk4OCQETiclbnrJC2GISF+6tZ+ti5OIQEjjCKPHq5UpWCGcxo0T3/3PMIFVsAgYSc/c0 sIHYIgK6Eu9+P2MEKWIW2M8o8f/lVLBRwgLpErNX3GOFKMqQmLViOhOE7SexddVMsEEsAioS d/8eZQexeQXsJTadfAtWLyTwlVGidUYciM0pYCsx618rWJwR6Lzvp9aAzWEWEJe49WQ+E8TZ AhJL9pxnhrBFJV4+/gf1jpLEotufoeqTJU503GaB2CUocXLmE5YJjKKzkIyahaRsFpIyiLiB xPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0lvs95wo6sZgEjxypG0eLU4uLcdCMjvdSizOTi4vw8 vbzUkk2MwOg8uOW31Q7Gg88dDzEKcDAq8fBuOPY9RIg1say4MvcQozQHi5I4r53xoRAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjKtO7iz70Kw3ySP/wQeTZT/tgtT3PMmxU5Pgneuqe+6z hoYTz41jCv6xbxc//f7/f9hKa56Trcs4Fe5sCJ583LQ8PcH5T/qXp7d/T3K9vO2o7MOr1hMO mHffcziaW3R20hU/nkcPs38emiY1r90syu/xv9O+0cc/h33U3y//cOKmO+dl7ZKmCq1QYinO SDTUYi4qTgQAOOb7U68CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/u18d-2rRlg3ZvOSGx3lR35hHjHA>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.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>
Subject: Re: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft
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: Thu, 05 Mar 2015 17:26:09 -0000
On 05 Mar 2015, at 18:09, Mo Zanaty (mzanaty) <mzanaty@cisco.com<mailto:mzanaty@cisco.com>> wrote: NIST does not say this. There must be some disconnect. What do you mean with “this”? NIST SP 800-38D, Appendix C says “For any implementation that supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2, respectively, shall be enforced.” and one of these rows in Table 2 is "Maximum Invocations of the Authenticated Decryption Function = 2^17” John Mo On Mar 5, 2015, at 11:34 AM, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>> wrote: On 05 Mar 2015, at 04:53, Mo Zanaty (mzanaty) <mzanaty@cisco.com<mailto:mzanaty@cisco.com>> wrote: Where did 2^17 come from? Nist SP 800-38D, Appendix C (I assume Kevin chosed the longest length). For packets around 1KB, the authentication tag strength is only reduced by 6 bits from 64 to 58 bits. SRTCP would rekey after 2^31 packets, giving a 2^-27 probability of a single successful forgery during the key lifetime if all 2^31 packets were forgeries. SRTP would theoretically rekey after 2^48 packets, giving a 2^-10 probability of a single successful forgery during the key lifetime if all 2^48 packets were forgeries, but in reality, SRTCP will always cause rekey first assuming at least 1 RTCP packet for every 2^17 RTP packets. And this is only for hypothetical attacks which require auth fail feedback per packet which can’t be realized in SRTP. And it requires extreme packet rates causing a denial-of-service far worse than the impact of compromised auth. And even a successful attack can only forge random data since the decryption key is not compromised. I see no reason to reduce key lifetime below other modes, even under the most paranoid security considerations. This is not a real-world vulnerability in SRTP applications. Thick tinfoil hats are good, but not so thick that they pin your head to the ground. I’m fine with something like that, my only demand is that the draft does not silently ignore the NIST requirements. The draft uses NIST SP 800-38D as the reference for GCM (shouldn’t this be a normative reference just like RFC3610?) We need to have the discussion you started above, and if the wg agrees, the draft needs to state that the strict NIST requirements does not apply to SRTP, explain why, and state which requirements this puts on packet lengths. John Mo On 3/4/15, 5:10 PM, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>> wrote: On 02 Mar 2015, at 12:53, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>> wrote: 2. The AES-GCM draft is proposed to contain the following configurations: AEAD_AES_128_GCM (with 16 byte authentication tag) AEAD_AES_128_GCM_64 (with 8 byte authentication tag) Is the proposal then to include the profile from draft-ietf-avtcore-srtp-aes-gcm-12 with a maximum key lifetime of 2^17 packets? Just so that everybody understands that a rekey would be needed every 43 minutes for a codec with 20 ms payload size.
- Re: [AVTCORE] Summary of discussion with IESG and… Magnus Westerlund
- Re: [AVTCORE] Summary of discussion with IESG and… Igoe, Kevin M.
- [AVTCORE] Summary of discussion with IESG and cal… Magnus Westerlund
- Re: [AVTCORE] Summary of discussion with IESG and… John Mattsson
- Re: [AVTCORE] Summary of discussion with IESG and… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Summary of discussion with IESG and… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Summary of discussion with IESG and… John Mattsson
- Re: [AVTCORE] Summary of discussion with IESG and… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Summary of discussion with IESG and… John Mattsson
- Re: [AVTCORE] Summary of discussion with IESG and… Mo Zanaty (mzanaty)
- Re: [AVTCORE] Summary of discussion with IESG and… John Mattsson