Re: [secdir] [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

[Gunnar Hellström <[e-mail]>]

Version -17 of the draft is submitted, with intention to have all Genart 
and Secdir review comments resolved.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17


Best Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
[e-mail]

Den 2021-05-07 kl. 19:47, skrev Gunnar Hellström:
>
> Thanks.
>
> I have added this sentence to section 3.19
>
> " Further general security considerations are covered in
>    Section 11."
>
> Regards
>
> Gunnar Hellstrom
>
> -- 
> Gunnar Hellström
> GHAccess
> [e-mail]  <mailto:[e-mail]>
>
>
> Den 2021-05-07 kl. 18:13, skrev Salz, Rich:
>>
>> Thanks for the explanation and update. Your updated draft addresses 
>> my concerns.  Perhaps 3.9 should have a forward link to Sec 11
>>
>> *From: *Gunnar Hellström <[e-mail]>
>> *Date: *Friday, May 7, 2021 at 11:45 AM
>> *To: *Rich Salz <[e-mail]>, "[e-mail]" <[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>, 
>> "[e-mail]" 
>> <[e-mail]>, "[e-mail]" 
>> <[e-mail]>
>> *Subject: *Re: [AVTCORE] Secdir last call review of 
>> draft-ietf-avtcore-multi-party-rtt-mix-16
>>
>> Rich,
>>
>> Thanks for the review.
>>
>> I am composing a new version because of the Gen-ART review, and want 
>> to propose changes to satisfy your comments.
>>
>> You ask if it is common to have the mixers being trusted.
>>
>> In the expected first implementation environments for this draft, it 
>> is. That is in emergency service networks. Also in personal 
>> communication services it is.
>>
>> The first implementation environments are also expected to use the 
>> SIP centralized conference model (RFC 4353 etc.) where all media are 
>> expected to be mixed centrally. Thus the security aspects would be 
>> similar for audio, video and real-time text.
>>
>> I have tried to elaborate a bit more on this in a modified security 
>> considerations section, currently looking like this and being ready 
>> for submission together with the changes because of the Gen-ART 
>> review. Would this satisfy your concerns?
>>
>> --------Proposed security concerns--------------------
>>
>> 11.  Security Considerations
>>    The RTP-mixer model requires the mixer to be allowed to decrypt,
>>    pack, and encrypt secured text from the conference participants.
>>    Therefore the mixer needs to be trusted to achieve security in
>>    confidentiality and integrity.  This situation is similar to the
>>    situation for handling audio and video media in centralized mixers.
>>    The requirement to transfer information about the user in RTCP
>>    reports in SDES, CNAME, and NAME fields, and in conference
>>    notifications, for creation of labels may have privacy concerns as
>>    already stated in RFC 3550 [RFC3550], and may be restricted for
>>    privacy reasons.  The receiving user will then get a more symbolic
>>    label for the source.
>>    Participants with malicious intentions may appear and e.g., disturb
>>    the multiparty session by emitting a continuous flow of text.  They
>>    may also send text that appears to originate from other participants.
>>    Counteractions should be to require secure signaling, media and
>>    authentication, and to provide higher level conference functions
>>    e.g., for blocking, muting, and expelling participants.
>>    Further security considerations specific for this application are
>>    specified in Section 3.19.
>> ----------------------------------------------------------
>> Regards
>>
>> Gunnar
>>
>> -- 
>> Gunnar Hellström
>> GHAccess
>> [e-mail]  <mailto:[e-mail]>
>>
>> Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:
>>
>>     Reviewer: Rich Salz
>>
>>     Review result: Ready
>>
>>     This review is for the benefit of the Security AD's. Nobody else should read
>>
>>     this. Or, if you read it, treat it as any other last call review :)
>>
>>     I know very little about WebRTC, AVT, etc.
>>
>>     I thought Section 1.2, summary of the alternatives, was great. I wish more
>>
>>     documents did this kind of thing. And similar for all of section 2. The details
>>
>>     in Section 3 about how to comply seem very clear. If I were implementing this,
>>
>>     I could use easily use this as a checklist and test suite. Section 3.19 is the
>>
>>     most important one for transport security. Not knowing the operating
>>
>>     environments, it seems reasonable.
>>
>>     The security considerations seems a little scant, given the opportunity for
>>
>>     privacy concerns of participants and for intruders to disrupt calls. Is it
>>
>>     common that the mixer is a trusted entity? A statement on that either way would
>>
>>     be useful.
>>
>>     _______________________________________________
>>
>>     Audio/Video Transport Core Maintenance
>>
>>     [e-mail]  <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/avt  <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/avt__;!!GjvTz_vk!ChNP_4C8_-IG9lEq-LDl930w9i9b8GYIlpcFoBp1nUK7LGxO78Q0hXyqr7QT$>
>>
>> -- 
>> Gunnar Hellström
>> GHAccess
>> [e-mail]  <mailto:[e-mail]>
> -- 
> Gunnar Hellström
> GHAccess
> [e-mail]

-- 
Gunnar Hellström
GHAccess
[e-mail]