Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-msrp-usage-data-channel-23

Yoshifumi Nishida <nsd.ietf@gmail.com> Thu, 13 August 2020 17:52 UTC

Return-Path: <nsd.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00213A0FB8; Thu, 13 Aug 2020 10:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 z-qPB8B1U68y; Thu, 13 Aug 2020 10:52:07 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 2AA243A0F20; Thu, 13 Aug 2020 10:52:06 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id 88so6091330wrh.3; Thu, 13 Aug 2020 10:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=in/SlLqAU9M/MhNwTWd6PTZ5JYTPJ3Uibd+EThp/iqI=; b=S3eoicbcpTKGTJLE1SZC6no2kP4UG8F+JpGa3PEMITBQcE1o03OY+wRJiqrz1rNZTB LxfsJaLOd2sgnFAfCWZmO3VDgoE6Jrc1tpmbPQKvuFUrVDVpKIQpVGPQizUXXBvW78HL oVnyXXyzDqq8+gV3OOHwxFj9V1mPcEbTgj+m/58phC3GZXE/sUfdg7jxyMUKtyquDcrd fX8vcEdman/wvxhgvCC/sN59b9ey1ED56LYfMWTFFHA5VRmmhAYCgx4BXLlRP9iKhU1q oEGjOx6imJhRNrWqvxeqPs0BneTKHyhJpq9AhMQ5BUNIONS3BnHQLqG8klT+7V1GgO48 7yXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=in/SlLqAU9M/MhNwTWd6PTZ5JYTPJ3Uibd+EThp/iqI=; b=PnM7DEomingV8Pc6M/0giQfftxu95yldIB+cAvHEEX4kREg1hZ/wd/RQf8g9HWjVb5 6BFH8ZPQEgiB3SNQ8tvg95vTzoVqsCEW2VI6bRimh38vEulCIz5R0dmNlZeDraSZ8LuT BctJnawSliWMsK+BuNJgU3UDf6hIsKe39YMN0MVezrw/dWFjNAJdQswug2m9A6LliIad 8IRKIqtFbQKrw3avRr1p4oq1Xa731eH4iHgxbmtBg1QeXMCeFmdkm2lQs+QEOWegwvUZ havEtoBuRZCmqwTW5wJo7fPyfcOtk2AXwx352WdM18Ysqs/8FuEP6RS+gfeYm0s/H5DQ kgAg==
X-Gm-Message-State: AOAM533mnMUolOoBh3hFX9s4dbaZqxsk8V59/0GDV9gGaz1GoTSV4dW0 xj6Yp/JWmYFCsp0F2jETeve3UBex7/hbJuTlefQ=
X-Google-Smtp-Source: ABdhPJz+n4jAt/rtPZuv0pHIu+Mn5nMr/mxJqFdX5/0KLyYKA3UqvFVBU6MKXlr8yzYMnLRvM0IET2cmigmw9EGQiE0=
X-Received: by 2002:a5d:60cb:: with SMTP id x11mr4755495wrt.281.1597341124407; Thu, 13 Aug 2020 10:52:04 -0700 (PDT)
MIME-Version: 1.0
References: <159726112563.26648.17930656676102307453@ietfa.amsl.com> <AM0PR07MB38606E636828DE0C77B3071A93420@AM0PR07MB3860.eurprd07.prod.outlook.com> <CAAK044QtLDXWXgGRduEQdyNTyQS6nKhEKt6rwCAc3jQPaVQP_A@mail.gmail.com> <AM0PR07MB3860B7095F706574D138A33893430@AM0PR07MB3860.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB3860B7095F706574D138A33893430@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Thu, 13 Aug 2020 10:51:53 -0700
Message-ID: <CAAK044R-nnwTDdok6s0KPy4=L05QhY_AJTJ-pUGKuehmtJQvOw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-msrp-usage-data-channel.all@ietf.org" <draft-ietf-mmusic-msrp-usage-data-channel.all@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e353b05acc5f686"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/M5ZZlToEd05mAPXE96ZApQSH55o>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-msrp-usage-data-channel-23
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 17:52:09 -0000

Hi Christer,

On Thu, Aug 13, 2020 at 6:34 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Yoshi ,
>
> >>>1: If the other endpoints is on a TCP connection, It seems to me that
> it can look downgrading the security level of the connection.
> >>>   If this is the case, do we need some guidance here?
> >>
> >> I assume you are talking about the gateway.
> >
> > Yes.
> >
> >> It is true that "legacy" MSRP allows TCP transport. RFC 4975 describe
> the security issues associated with that.
> >>
> >> I suggest to add the following text to the Security Considerations.
> >>
> >> OLD:
> >>
> >>   "MSRP traffic over data channels is secured, including
> >>   confidentiality, integrity and source authentication, as specified by
> >>   [I-D.ietf-rtcweb-data-channel]."
> >>
> >> NEW:
> >>
> >>   "MSRP traffic over data channels is secured, including
> >>   confidentiality, integrity and source authentication, as specified by
> >>   [I-D.ietf-rtcweb-data-channel]. However, [RFC4975] allows transport of
> >>   MSRP traffic over non-secured TCP connections. In a gateway scenario,
> >>   unless the operator mandates usage of TLS, the MSRP traffic will not
> be
> >>   secured all the way between the MSRP endpoints. [RFC4975] describes
> >>   the security considerations associated with non-secured MSRP traffic."
> >
> > Thanks. Works for me.
>
> Great.  I will modify as suggested.
>
> ---
>
> >>> 2: 'If the non-data channel endpoint does not support MSRP CEMA,
> transport level interworking mode is not possible,
> >>>   it needs to act as an MSRP B2BUA.'
> >>>   -> This may sound like it falls back to B2BUA when CEMA is not
> available.
> >>>        But, I guess there might be a case where users don't want
> fallback.
> >>
> >> I don't think the users really care. CEMA is a transport connection
> establishment feature. Even with legacy MSRP, there
> >> could be a fallback if one of the endpoints don't support CEMA, but
> users are not informed about whether CEMA is used or not.
> >
> > I agree that users don't really care about if CEMA is used or not
> in general.
> > But, how about the cases where the gateway uses a non-secured TCP
> connection after it found CEMA is not available.
> > I guess some users might care about the security level is downgraded.
>
> The usage of TCP or TLS has nothing to do with whether CEMA is used or
> not. CEMA can be used with both TCP and TLS, and both TCP and TLS can be
> used with or without CEMA :)
>
> CEMA is basically about what SDP information elements you use to exchange
> the IP address information where to send your MSRP messages. CEMA uses
> generic SDP offer/answer rules, while non-CEMA uses a more MSRP-specific
> way.
>

OK. I am just concerned about the situations where a user specifies msrps
but msrp is used at the other endpoint and the user cannot aware of it.
if this won't happen, I don't have any more comments here.

>>> 3: As the doc mentions the use of B2BUA, it might be useful to refer
> security consideration in RFC7092 in Section 9.
> >>
> >> I assume you mean Section 6?
> >
> > Sorry.. I meant the security consideration section in the doc which is
> Section 8. But, Section 6 is also fine for me. I don't have a strong
> opinion here.
> > My point is that I'm not worrying about the use cases without gateways
> and the use cases with CEMA enabled gateway.
> > But, I'm concerned about the case where B2BUA gateway is used as the
> draft simply mentions that it can be used.
> > So, I am thinking that something in the security consideration in
> RFC7092 (e.g. B2BUA can be a tempting point of attack) might be useful for
> readers.
>
> Gotcha.
>
> So, I could add the following paragraph to the Security Considerations.
>
> "[RFC7092] describes security considerations associated with B2BUAs."
>

Thanks. works for me.
--
Yoshi