Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04

Alissa Cooper <alissa@cooperw.in> Thu, 03 April 2014 17:28 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0D1A024E for <mmusic@ietfa.amsl.com>; Thu, 3 Apr 2014 10:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 kxxlkGnMtNbY for <mmusic@ietfa.amsl.com>; Thu, 3 Apr 2014 10:28:30 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB41A0273 for <mmusic@ietf.org>; Thu, 3 Apr 2014 10:28:27 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 27C0D20720 for <mmusic@ietf.org>; Thu, 3 Apr 2014 13:28:23 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Apr 2014 13:28:23 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=wzKXvHaQhflrDDAtnpp0YGPIN7g=; b=w8AjNstIsz5zHwNCflQ/Y40dZH3w yxy160bgqWZBLaKcFv8Ey3XdHmKVWjRyuEvXNVUeSfSv/bzWuegCkylV8lq6/IWr PVqejfepUH65nT65CqbMSdI5Pm76ZJ0O0lTIVIs2e8OMams05Iyy0bzPyEWoPyXy grJqMVd7qRPUINY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=wzKXvHaQhflrDDAtnpp0YG PIN7g=; b=Ry35eMa4j8La1fSFIcnAbn2ch1LSEqKGS6TtGs9I+sg85H54EWIGBU vR/c+TgPrqiHaicE8VrJ28836lEAJpG4QmI6cg42h7by2gXxWXlcXcmyj2CuTKNt Ouj00nDHw9hjYLOWC7iTfStquSYduLaHTIMP+Z4VYeuRTgIoe5EGg=
X-Sasl-enc: O0XMAWSSlrI8NsYSpCY9Kb5uKP2YDj65A7NxB2CKgMsF 1396546102
Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 8AEC5C007B2; Thu, 3 Apr 2014 13:28:19 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Thu, 03 Apr 2014 10:28:16 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: Dan Wing <dwing@cisco.com>
Message-ID: <CF62E5DD.2FFDF%alissa@cooperw.in>
Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04
References: <CF489B5D.25EB0%alissa@cooperw.in> <CAPvvaaKM7S0jRA1dQgCZLGfg4ryNRriMfvSM3V6sD+=3TX4Jzw@mail.gmail.com> <CF6053C5.2F454%alissa@cooperw.in> <D89856F8-9E74-4612-88D8-D9E1EE27BE36@cisco.com>
In-Reply-To: <D89856F8-9E74-4612-88D8-D9E1EE27BE36@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uOe1rJ5CLOmHMPtSdMZmWxA0Tyo
Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2014 17:28:36 -0000

Hi Dan,

On 4/1/14 11:42 AM, "Dan Wing" <dwing@cisco.com> wrote:
>
>>> The draft suggests use of SRTP for authenticating media which does
>>> resolve the security issues (from a privacy/confidentiality
>>> perspective). 
>> 
>> I was more concerned with the DoS aspect.
>
>The DoS aspect of authenticating incoming SRTP packets to the SBC?

The DoS aspect that is described in the paragraph Emil quoted below.

>
>
>> 
>>> That's part of section 5:
>>> 
>>>  Naturally, SRTP [RFC3711] would help mitigate such threats and should
>>>  be used independently of HNT.  For example, in cases where end-to-end
>>>  encryption is used it would still be possible for an attacker to
>>>  hijack a session despite the use of SRTP and perform a denial of
>>>  service attack.  However, media integrity would not be compromised.
>>> 


>> I think something like the following might capture the
>> situation better:
>> 
>> OLD:
>> Due to the security issues presented in Section 5, the latching
>>mechanism
>> is considered inappropriate for general use on the Internet unless all
>> security considerations are taken into account and solved.
>> 
>> 
>> NEW:
>> Due to the security issues presented in Section 5, the latching
>>mechanism
>> is considered inappropriate for general use on the Internet, and in
>> controlled environments unless all security considerations are taken
>>into
>> account and solved.
>
>"General use on the Internet" and "in controlled environments" are 100%
>of all networks, so perhaps simplifying to:
>
>NEW:
>  Due to the security issues presented in Section 5, the latching
>mechanism
>  is considered appropriate only when all security considerations are
>taken into
>  account and solved.

I think the text in the -04 is preferable to this, as it is more specific.

I would be interested in others' thoughts on the text I proposed above.

Thanks,
Alissa