Re: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)

Ben Campbell <ben@nostrum.com> Mon, 10 July 2017 14:45 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652C213145A; Mon, 10 Jul 2017 07:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 L047oJl2wR1t; Mon, 10 Jul 2017 07:45:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE70124B0A; Mon, 10 Jul 2017 07:45:28 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6AEjMdU034136 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Jul 2017 09:45:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <CABcZeBNNHVvQvj+GeoD19+f75D1TQKO89cL-6tSMFjQnNPEWdg@mail.gmail.com>
Date: Mon, 10 Jul 2017 09:45:23 -0500
Cc: Woo-Hwan Kim <whkim5@nsr.re.kr>, The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org, roni.even@mail01.huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, "avt@ietf.org" <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <41AF9813-C3AB-4F5B-95C0-693780ECE80C@nostrum.com>
References: <149945955972.15094.6380528023048643623.idtracker@ietfa.amsl.com> <006101d2f95f$274e2dd0$75ea8970$@nsr.re.kr> <CABcZeBNNHVvQvj+GeoD19+f75D1TQKO89cL-6tSMFjQnNPEWdg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/V29R2gyR_XI3Ngv_za_tW4cVISY>
Subject: Re: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 10 Jul 2017 14:45:30 -0000

> On Jul 10, 2017, at 7:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Mon, Jul 10, 2017 at 2:30 AM, Woo-Hwan Kim <whkim5@nsr.re.kr> wrote:
> Let me reply to the comment of Ben Campbell.
> We would like to add the below to security considerations of the previous draft(-10).
> 
> --------------------------------------------------------------------
> As a note, at the time of publication of this document, SRTP
> recommends HMAC-SHA1 as the default and mandatory-to-implement MAC
> algorithm. So all of SRTP crypto suites except GCM based ones use
> HMAC-SHA1 as their MAC algorithm to provide message authentication/
> integrity. Due to security concerns with SHA-1 [RFC6194], the IETF
> is gradually moving away from SHA-1 and towards stronger hash
> algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1
> is only used in the calculation of an HMAC, and no security issue is
> known in this case. To use a secure hash algorithm such as SHA-256
> in SRTP, the values of directly related SRTP parameters
> auth_key_length and auth_tag_length should be determined considering
> the overall security and efficiency when the crypto suite is applied.
> 
> I don't think this last sentence makes sense. We are moving towards AEAD algorithms, so I doubt we would ever want to publish <Cipher>-HMAC-SHA256. I would simply remove the sentence.

I agree. 

When I suggested text to say what would need to be done to move to newer hashes, I was thinking of something more general from a procedural perspective. Maybe something more to the effect of “Changing away from SHA1 for this purpose is out of scope for this document, and would require updates to SRTP [REF]”

On the other hand, I would also be okay with simply removing that sentence.


> 
> -Ekr
>  
> 
> [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
> Considerations for the SHA-0 and SHA-1 Message-Digest
> Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
> <http://www.rfc-editor.org/info/rfc6194>.
> --------------------------------------------------------------------
> 
> Sincerely, Woo-Hwan Kim
> 
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Saturday, July 08, 2017 5:33 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-avtcore-aria-srtp@ietf.org; avtcore-chairs@ietf.org; roni.even@mail01.huawei.com; avt@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-avtcore-aria-srtp-10: Yes
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I think it would be wise to add a paragraph to the security considerations to call out the dependency on SHA1. A mention of what would need to happen to migrate to newer hash functions could also be helpful.