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

Yoshifumi Nishida <nsd.ietf@gmail.com> Fri, 14 August 2020 20:53 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 ADA433A087F; Fri, 14 Aug 2020 13:53:12 -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 ewLOiR4ceX-d; Fri, 14 Aug 2020 13:53:11 -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 A77A13A0881; Fri, 14 Aug 2020 13:53:10 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id r2so9443495wrs.8; Fri, 14 Aug 2020 13:53:10 -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=A9TwvWUbfJ1pOCpvXBVBUbzQHWw66tz8Cq/LxA1tUi4=; b=RhbxvzySA7qcs7zha/XQG2zV2a7xUbpL7pWt/ABv55P26gzMsFr1S/QvqRU3L8IxY3 iQHek095I41k4e3e8vWPxx0FxeoeIgt0dCMlVoRBtHWsRX7GGLltr1B6k/239rCGEByX YL08yA5IQs0Fk+M8Dl+f6IR6JZBdggx4yFTg3++XCi2y4F+fi4/J4au/zMhU7Znfggng NhtAN+fwAg1uIZEMrIdHWMdxK4eIsw3Z6aThkaF+247NsLRH7vRiacrRBe+hIllDnaSS YCtwDDux6OQmKLLsz0ImNAR+jaM1p/wTTlu3VlScMN5uSHPwXmykRUkSZCqFYBs5wxZO 0iqA==
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=A9TwvWUbfJ1pOCpvXBVBUbzQHWw66tz8Cq/LxA1tUi4=; b=ABhCV879tC1acRnaqI5t4CYgrnsytVXyEFKZAToqU2qMgxgIwmrWwMc4Re1IvMDypO kQFeUPSYvrYIZkrHXxnDoVzbMhbnEkVcahxVlwwfElr3mpc7EysCDh31Or3xZGsKdfCR kG76+GUwk+1n/5ciPkDnV9a6TL9qRNu35ACMmvEuWZ6vr4mS6C19lLTrIfW9gHZWIZGz iUp8KvnpBF7HYJ/PNOSuCWqQHwuNApBGHoLsj9qXLMEYEfb5JgNTfpy6mNvSGKv9e4oN 1QoSeGOOT3KZufiZTnqEuzsHj156D/v/5ojpL+/coNNrD0Vl/irIZ91SCnQX0JeY4FlX fgdw==
X-Gm-Message-State: AOAM532Pyt6y038i1b2jfQM+j81pxFiw/7Wi5JwaVpOkl9xJdZa14bNJ 8wgtlZQRu4WEY4PydCQwUqKNhsczq2LwI1rKniY=
X-Google-Smtp-Source: ABdhPJwC+3ppEpxxGIdYvCRzDO9jJ8CCCk1Oj/BC7DcjOEtD55EOB/QcmShVGJ/PPoiS/I2A4PP1mpfnSlueq/pCQr8=
X-Received: by 2002:adf:f8d0:: with SMTP id f16mr4477219wrq.66.1597438389032; Fri, 14 Aug 2020 13:53:09 -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> <CAAK044R-nnwTDdok6s0KPy4=L05QhY_AJTJ-pUGKuehmtJQvOw@mail.gmail.com> <AM0PR07MB3860ABD9F40515FB1C918C1093400@AM0PR07MB3860.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB3860ABD9F40515FB1C918C1093400@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Fri, 14 Aug 2020 13:52:58 -0700
Message-ID: <CAAK044SfLw9FSk22tcfdJ79zVmzDsV0eXE44vFUuHcB7F=M3Bw@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="000000000000ba9bc305acdc9b89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/oW2vU83C0_GBMfbT-_00t0_ffgw>
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: Fri, 14 Aug 2020 20:53:13 -0000

Hi Christer,

On Fri, Aug 14, 2020 at 12:08 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Yoshi,
>
> ...
>
> >>> 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.
>
> Note that, with pure legacy MSRP, there is no guarantee that there will be
> end-to-end security. RFC 4975 says:
>
>    "For this reason, a URI with the "msrps" scheme makes no assertion
> about the security properties of
>    other hops, just the next hop.  The user agent knows the URI for each
>    hop, so it can verify that each URI has the desired security
>    properties."
>
> Perhaps I could enhance the new text I suggested to address your comment
> #1:
>
> OLD 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."
>
> NEW 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, and does not
> provide
>         a mechanism to guarantee usage of TLS end-to-end. As described in
> [RFC4975],
>         even if TLS is used between some hops TCP might still be used
> between other hops.
>         Operators need to ensure that proper policies are established in
> order to ensure
>         that the MSRP traffic is protected between endpoints."
>
>
The text looks good to me.
I don't have any more comments on the draft. Thanks for the efforts.
--
Yoshi