Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Fri, 09 August 2019 01:26 UTC

Return-Path: <rdd@cert.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3989512007A; Thu, 8 Aug 2019 18:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 JnyaSP8wacNE; Thu, 8 Aug 2019 18:26:42 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3F512006E; Thu, 8 Aug 2019 18:26:41 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x791QbAk003561; Thu, 8 Aug 2019 21:26:37 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x791QbAk003561
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565313997; bh=EGZZwib7lKJeFG1w5auNR4gnMEJ3KA6kKeqll5NSDcM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B328E7Hv3siNrN3u+VsPJZ2bnBh4H7hDoiGHygLRXJOQ92SHR2f1/kYroy2Pb0bCi kakJCNCsrfPJIU24TlpiaPTW/UK4CLTN8bD39U/n9X8E64PS/mXlcdhyNOSzHG13RG BINTFJ+NF+iQ37Y3f9+3YIjPTJ19cCYu2Pv51/d0=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x791Qb5O039896; Thu, 8 Aug 2019 21:26:37 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Thu, 8 Aug 2019 21:26:37 -0400
From: Roman Danyliw <rdd@cert.org>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: "fandreas@cisco.com" <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-ice-sip-sdp@ietf.org" <draft-ietf-mmusic-ice-sip-sdp@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)
Thread-Index: AQHVS/6tjWg4BE1sB0SFynsU3YUPIqbwV1eAgAFVyYCAACUmgIAAN8MQ
Date: Fri, 09 Aug 2019 01:26:35 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3403075@marchand>
References: <156505852285.2142.10774832459273251927.idtracker@ietfa.amsl.com> <d9877c1a-e36e-7e53-ce72-433f23090687@nostrum.com> <83DA6259-42DE-4A2F-94AB-DE2735FAE743@ericsson.com> <F196E71C-5D41-40CC-9615-D88A0DD8E991@ericsson.com>
In-Reply-To: <F196E71C-5D41-40CC-9615-D88A0DD8E991@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/GEALk2SDZLDi1cDBd21c4USEENM>
Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Aug 2019 01:26:44 -0000

Hi Christer!

Adam and you clarifications; and this pull request addresses my discuss points.  Please go ahead and publish.  

I appreciate it the quick iteration.

Thanks,
Roman

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Thursday, August 8, 2019 2:04 PM
> To: Adam Roach <adam@nostrum.com>; Roman Danyliw <rdd@cert.org>;
> The IESG <iesg@ietf.org>
> Cc: fandreas@cisco.com; mmusic-chairs@ietf.org; mmusic@ietf.org; draft-
> ietf-mmusic-ice-sip-sdp@ietf.org
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> I have now updated the pull request based on the discussion below. Again,
> the changes related to the Security Considerations are at the end of the pull
> request:
> 
> https://github.com/suhasHere/ice-sip-sdp/pull/18/files
> 
> Regards,
> 
> Christer
> 
> 
> On 08/08/2019, 18.50, "Christer Holmberg"
> <christer.holmberg@ericsson.com> wrote:
> 
>     Hi Adam,
> 
>     Thanks for Your input! A few comments from me inline.
> 
>         >> (1) Section 8.1. Per “These require techniques for message integrity
> and
>         >> encryption for offers and answers, which are satisfied by the TLS
> mechanism
>         >> [RFC3261] when SIP is used”, the guidance is right (use TLS), but this
>         >> reference is outdated.  Section 26.2.1 of RFC3261 provides rather old
> guidance
>         >> on the ciphersuite.  Is there a reason why not to use BCP195 for
> guidance on
>         >> versions/ciphersuites?
>         >
>         > As much as SIP has a convoluted layering story, the separation
> between
>         > SIP and SDP remains pretty clean (both from a protocol perspective
> and
>         > organizationally within the IETF). While it's likely the case that RFC
>         > 3261 could use some updating to its security story [1], I don't think it
>         > makes sense to hold up this document on that work. It's really rather
>         > far outside the purview of this document to make changes to the
>         > underlying cipher suite; in fact, I would argue that doing so would be
>         > disallowed in MMUSIC, since it is part of the core protocol work that
>         > clearly falls in SIPCORE's charter.
> 
>         I agree. If we need to update the security properties of SIP, let's do it
> properly in SIPCORE.
> 
>         ---
> 
>         >> (2) Section 8.2.1, The “voice hammer attack” appears to be an artifact
> of SDP.
>         >> The text explicitly notes that this attack is not “specific to ICE but that
> ICE
>         >> can help provide a remediation” (aside, should “remediation” be
> “mitigation”).
>         >> However, the preceding introductory section (8.2) explicitly says
> “there are
>         >> several attacks possible with ICE”.  These two statements aren’t
> consistent.
>         >
>         > It seems that the solution for this would be to promote section 8.2.1 to
>         > its own top-level section inside the security considerations section.
>         > Would that work for you?
> 
>        I would be ok with that.
> 
>        However, I think it would be good to add text to 8.2.1 saying that a
> "Voice hammer attack" attack can take place even when the
>        attacker is an authenticated user, and then go on describing how ICE can
> be used to prevent the attack.
> 
> 
>        ---
> 
>         >> (3) Section 8.2.2.  This section reads like an operational
> consideration.  The
>         >> setup scoped in the parent Section 8.2, “there are several attacks
> possible
>         >> with ICE when the attacker is an authenticated and valid participant
> in the ICE
>         >> exchange”, isn’t discussed here (i.e., how is the presence or absence
> of an ALG
>         >> germane to an attacker who is a participant in the ICE exchange)
>         >
>         > It seems that the solution for this would be to promote 8.2.2 to its own
>         > top-level section within the document, preceding the Security
>         > Considerations section, possibly with a renaming along the lines of
>         > "Operational Considerations: Interactions with Application Layer
>         > Gateways and SIP". Does that work for you?
> 
>         I am fine making it its own top-level section. But, do you think it should
> be a normative section, or an Appendix?
> 
>         > I note that making both of these changes leaves section 8.2 empty save
>         > for the introductory text; I propose that we simply remove the section.
> 
>         I am fine with that.
> 
>         ---
> 
>         >> (4) Section 8.  Is there a reason why the security considerations from
> RFC8445
>         >> are not noted as also applying (e.g., Section 19.1 - .4.
>         >
>         > Would the addition of text at the top of section 8 that says "Please
>         > note that the security considerations from sections 19.1 through 19.4
> of
>         > [RFC8445] also apply to this document." address your concern?
> 
>         Others have commented on this, and there is a pull request addressing
> it:
> 
>         https://protect2.fireeye.com/url?k=fc78358d-a0f2175b-fc787516-
> 0cc47ad93dcc-
> f3a799884e91abda&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2F
> ice-sip-sdp%2Fpull%2F18%2Ffiles
> 
>         Please see the last change in the pull request.
> 
>         Regards,
> 
>         Christer
> 
> 
> 
>