Re: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Thu, 05 March 2015 17:14 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 97BF61A1B65 for <avt@ietfa.amsl.com>; Thu, 5 Mar 2015 09:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 yVunyAcVk3Bo for <avt@ietfa.amsl.com>; Thu, 5 Mar 2015 09:14:53 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D85E1A064C for <avt@ietf.org>; Thu, 5 Mar 2015 09:09:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8320; q=dns/txt; s=iport; t=1425575380; x=1426784980; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DAojUwVeLPuIRU8ldimtrkhEoPXShvt79epBx6lF7kY=; b=iHnsKjZ9A/DciNhXG3oK8iSXObBWj+56uL7wdHWOwDbu0o0t7PAGtYMw VlcJ3dg5Ko/ZPscVOQlT9bsIJSDAyb/KAJZiYLp2bm6L6Vpti75cZl7RQ NrxMB/FmmCUlTqppXcm0ElAW9TtqmJcpUbHFWvi0BfvzMvc9pKyFkpfiD Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A4CADQjPhU/5BdJa1agkNDgSy7OotuAoE4TQEBAQEBAXyEEAEBBB1cEAIBCD8HMhQRAgQOBYgv2CEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEbgeDF4EUBZAHiU2BGo8Tg0IjggIcFIE8b4JDAQEB
X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208,217";a="129221569"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 05 Mar 2015 17:09:39 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t25H9dKi005191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 17:09:39 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 11:09:38 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: John Mattsson <john.mattsson@ericsson.com>
Thread-Topic: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft
Thread-Index: AQHQVN+IDiuRyXO3Gk667nz/Zy+CcJ0M1ZWAgABf0gCAANSbgIAAGpHD
Date: Thu, 05 Mar 2015 17:09:38 +0000
Message-ID: <85733DA9-9EFA-4D91-A988-C207FC6ED24A@cisco.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>
In-Reply-To: <7303D044-CE4E-4ACF-B7F6-46D963CD1BC6@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_85733DA99EFA4D91A988C207FC6ED24Aciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/FIo1dmiYYfj9nJPdi_oesPwLbfg>
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:14:54 -0000

NIST does not say this. There must be some disconnect.

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.