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

[Yoshifumi Nishida <[e-mail]>]

Hi Christer,

On Fri, Aug 14, 2020 at 12:08 AM Christer Holmberg <
[e-mail]> 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