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 03:45 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 C23633A1628; Wed, 12 Aug 2020 20:45:35 -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 BeJzzlaIbxN8; Wed, 12 Aug 2020 20:45:34 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 43C033A166C; Wed, 12 Aug 2020 20:45:30 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id f12so3880722wru.13; Wed, 12 Aug 2020 20:45:30 -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=PmrfvjeIAQgGK0c+vSkLWyzbUpQNBuRnciQN6CR7rO4=; b=kswf7qgKlYnxYysrkfCg98Y1Tk0z1eT6hlUR4zXPNcBsG4MccY7n7VrgzxoBvUyKaF DiV8wNVIIA+XXzLdWOA9fEJhDUMehvZGdGpOdpnd7ld39qW9PrvIx9paE+vFs7ZHs+aj xfbDh1ObnfeDlupUJcSCVMO+mdFOkaqDxCWzu/GxjwMllOsHeumY1nP/XeFBQ/fOXybt YnE8XfIzunOjVcnxECIPsNaU4goItOhqga7KSVUqbym4yKaGdEtPzlKBNOVBrYrVcxtj Jh2SQ6ix/8jcjLIrrjC89kGbrpIBgSYU2UcYx0w3Xgqnk8jGxpLrzFCho5O6Q5GosCl9 1zVg==
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=PmrfvjeIAQgGK0c+vSkLWyzbUpQNBuRnciQN6CR7rO4=; b=I8IVqEcJmXEgtyuHNzVRZKvtTTwlvsP+PEy9S5n+0gzHWJg4pQ0pp8BmQlziyiksbH DGeSPs6TulZfnRCAVHYyqAUGQuIBZ3rQd2i38mupuOXsBv0tRLGjgdF2vmn1TZ8FSsSp 2OvYTAjjGMhRV4X/NNP4Vm99S17PUzd3lFR2yzbZX9work+tlDc5bqybLsjOaIspX3si AWoYpYJiruZvFwAxAoVV6JKLAIUEbCVKTmOT5f1stKBf4PfAC4NmhBg73TftECZcAVnT Ljf2SuwuYlG9ZbDWmbNyEe6XDMebW88p204Xq4IZlY4tTcH9lt6/sJKDE91enCoY64vj 5yQw==
X-Gm-Message-State: AOAM531y10gZvIB2z5lnmP82e7s4D4tcK+NNEprWZpYyHbn/hsraIrO0 4xv/H6rjZyuHhcvj8Fzfb3raWyWFJGj6uB+Xl3Y=
X-Google-Smtp-Source: ABdhPJxWJRLFTMfbQmgygsIq29irL06hgO2VgF0gdcDAf2x11ZKPb64k8PenW2HEDTPo65KPAL8zpi3tufxyYIF0AeE=
X-Received: by 2002:adf:94c3:: with SMTP id 61mr1814830wrr.289.1597290328687; Wed, 12 Aug 2020 20:45:28 -0700 (PDT)
MIME-Version: 1.0
References: <159726112563.26648.17930656676102307453@ietfa.amsl.com> <AM0PR07MB38606E636828DE0C77B3071A93420@AM0PR07MB3860.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB38606E636828DE0C77B3071A93420@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 12 Aug 2020 20:45:17 -0700
Message-ID: <CAAK044QtLDXWXgGRduEQdyNTyQS6nKhEKt6rwCAc3jQPaVQP_A@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="000000000000a50cce05acba22a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/AwRYQY4Au5CVe6r3BHk8ksVt4lE>
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 03:45:40 -0000

Hi Christer,

Thanks for the reply. I put my comments in lines.

On Wed, Aug 12, 2020 at 1:22 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Yoshifumi,
>
> Thank You for the review! Please see inline.
>
> >Summary: This document is almost ready for publication, but I think it
> will be better to clarify the following points.
> >
> >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.

> 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 gareway 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.


>
> > 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.

Thanks,
--
Yoshi