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

[Yoshifumi Nishida <[e-mail]>]

Hi Christer,

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

On Wed, Aug 12, 2020 at 1:22 PM Christer Holmberg <
[e-mail]> 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