Re: [MMUSIC] Input wanted for draft-ietf-mmusic-sdp-uks


On 6/15/18 12:14 PM, Martin Thomson wrote:
> Thanks for reviewing this Flemming.
>
> This is definitely a difficult attack to understand (and therefore
> also explain).  I took a look at the description we have in the draft
> and tried to improve it a little.  I pointed out that the basic attack
> can be extended to session concatenation in the overview section, and
> tweaked the wording in a few places.
Ok
> However, I don't think that details of signaling would make this
> clearer.  Though it's possible that this is eliding a few things that
> seem obvious to me.  Of course, I'm too close to this to be sure.
> Maybe we can discuss how this works and maybe we can figure out how to
> improve the text.
Sounds good - assuming you are in Montreal, maybe we can discuss further 
in person there.

> This has been pretty widely reviewed, but I can provide another nudge
> for the related working groups to have a look.
That would be great, since I do think we will need to hear from those 
groups as well (speaking with my chair hat on on this last point).

-- Flemming


>
>
> On Thu, Jun 14, 2018 at 2:43 PM Flemming Andreasen <fandreas@cisco.com> wrote:
>> I took a look at the document and have a couple of comments:
>>
>> I was initially expecting the unknown key share attack to be about what the document refers to as Session Concatenation (in Section 5), however the attack overview in Section 2.1 describes two other attack scenarios instead. I think it would be helpful to be clear on all the attack scenarios up front.
>>
>> Secondly, I find it very difficult to follow the "two concurrent calls" attack scenario described. The overview is very high-level and the example in Section 2.3 omits too many details for me to fully understand the attack (there seems to be more going on between Mallory and Patsy than explained in the text and there are subtleties around what Mallory actually does with the respective SIP, DTLS and media packets for each session that are not entirely clear to me). Without a solid understanding of the attack, it is difficult to determine if the proposed solution truly mitigates it (I was in fact wondering about how the solution would work with session concatenation in the absence of somehow securely associating the session identifier with a particular SIP signaling session, which the document gets more into later in Section 5).
>>
>> A similar concern applies to the WebRTC use case, since I'm not familiar with the details of how that works, and hence would benefit from more details.
>>
>> On that note, there are solution elements here that span TLS/DTLS, SDP, and WebRTC/RTCWeb, and we should ensure those groups review the document as well. Have the authors circulated the document in those groups ?
>>
>> Thanks
>>
>> -- Flemming (as individual)
>>
>>
>>
>>
>> On 5/21/18 9:44 AM, Bo Burman wrote:
>>
>> WG,
>>
>>
>>
>> We have not seen any discussion on the list for this draft since it was submitted late January 2018. Please consider reviewing and commenting if you have interest in progressing the draft. It is a short document (only 13 pages in total).
>>
>>
>>
>> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks/
>>
>>
>>
>> Cheers,
>>
>> Bo
>>
>> MMUSIC co-chair
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
> .
>