Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

[Bo Burman <[e-mail]>]

Thanks, I believe that addresses almost all of my concerns (see also inline).

Just a final nit for section 4.1 (also listed in the below);
"...Once the second session completes, Mallory might cause DTLS packets
> sent by Norma to Patsy to be dropped.  It is likely that these DTLS packets will
> be discarded by Patsy as Patsy will already have a successful DTLS connection
> established."
[BoB] I think there can still be confusion what you mean with "Once the second session completes"; suggest changing to "Once the second session is established", if that was the intention.
Also, a couple of sentences before "Though Patsy...", there's one too many "is complete" in this sentence: "Once signaling is complete on a session, ostensibly between Mallory and Norma, is complete."

Cheers,
/Bo

> -----Original Message-----
> From: Martin Thomson <[e-mail]>
> Sent: den 1 mars 2019 07:04
> To: Bo Burman <[e-mail]>; mmusic <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
> 
> Thanks for reviewing Bo,
> 
> I've got the changes I've made up at
> https://github.com/martinthomson/sdp-uks/pull/7
> 
> The changes look like a lot, but that is mostly because of some reordering of
> text.  I've reworded a few things to improve clarity.  I appreciate having a
> new set of eyes on this.  I find I tend to miss places where the text assumes
> too much prior knowledge.
> 
> I'll put a second PR up for Flemming's review shortly.  That will stack on top of
> this one.
> 
> On Tue, Feb 26, 2019, at 00:23, Bo Burman wrote:
> > Hi Martin,
> >
> > I've now also reviewed this and have a set of comments and questions,
> > after taking Magnus' comments and your suggested edits in response to
> > that into account:
> >
> > Section 2.1:
> > * In bullet 2, "complete communications" is slightly unclear (more so
> > if "complete" is used in other contexts further down in the text). Do
> > you with "complete" mean "accept", or perhaps "accept setting up"?
> 
> Yes, I can see how this could be confusing. Reworded to:
> 
> "2. No entity will successfully establish a session with a peer unless they are
>    willing to participate in a session with that peer."
[BoB] OK, good.

> 
> > * Don't understand what is meant with "...second condition..."; is it
> > bullet #2, or is it referring to "...joining two separate sessions"?
> 
> Bullet 2, but see below.
> 
> > * Also don't really understand in what way that second condition is
> > "not necessary"; to limit the attacker capabilities (related to bullet
> > #2), for the attacker to join two sessions, or something else like
> > "for the attack to succeed"?
> >
> > * Just to confirm, does "removing this constraint" refer to removing
> > use of an identity binding?
> 
> Does this make more sense?
> 
> "Systems that rely on strong identity bindings, such as those defined in
> {{WEBRTC}} or {{!SIP-ID}}, have a different threat model, which admits the
> possibility of attack by an entity with access to the signaling channel.
> Attacks under these conditions are more feasible as an attacker is assumed
> to be able to both observe and modify signaling messages."
[BoB] Yes, that's much better.

> 
> > Section 3:
> > * Is the "victim" of the first paragraph the same or another victim
> > compared to the one mentioned in the next paragraph?
> >
> > * Is "another entity of the attacker's choice" also to be considered a victim?
> 
> Yes, there are really two victims here, so I've reworded to use first victim and
> second victim.
> 
> "An attacker causes an
> identity binding to be created that binds an identity they control to the
> fingerprint of a first victim.
> 
> "An attacker can thereby cause a second victim to believe that they are
> communicating with an attacker-controlled identity, when they are really
> talking to the first victim.  The attacker only needs to create an identity
> assertion that covers a certificate fingerprint of the first victim."
[BoB] OK

> 
> > * The last paragraph in section 3, just before section 3.1 "The same
> > technique..." seems a bit misplaced, after text talking about a
> > solution. Should it perhaps be moved just before the paragraph "The
> > problem..." in section 3? Or, is this "same technique" referring to
> > what is described in section 4?
> 
> Yes, this was a little light.  I've moved it up with the attack synopsis.
> 
> "A variation on the same technique can be used to cause both victims to both
> believe they are talking to the attacker when they are talking to each other.
> In this case, the attacker performs the identity misbinding once for each
> victim."
[BoB] OK

> 
> > Section 4:
> > * First sentence, "similar attack"; similar to what?
> 
> Yeah, that lost context.  How about:
> 
> "Even where the integrity of session signaling can be relied upon, an attacker
> might still be able to create a session where there is confusion about the
> communicating endpoints by substituting the fingerprint of a communicating
> endpoint."
[BoB] OK

> 
> > Section 4.1:
> > * Believe it would be helpful for the reader to better understand why
> > "Mallory has no real interest in seeing that session complete"
> 
> The next sentence is intended to explain this point: Mallory needs Patsy to
> maintain her end of the communications, lest Norma believe that the session
> is broken.
> 
> > * Same sentence, does "session complete" mean "session setup
> complete"?
> > I first interpreted "complete" as "conclude" in the meaning "terminate".
> >
> > * Same paragraph, should "call completion" be "call setup completion",
> > and "session completes" be "session setup completes"?
> >
> > * Same paragraph, "will likely be discarded by Patsy"; believe it
> > would be helpful to say why.
> 
> Here's what I ended up with:
> 
> "Though Patsy needs to believe that the second signaling session has been
> successfully established, Mallory has no real interest in seeing that session
> also be established.  Mallory only needs to ensure that Patsy maintains the
> active session and does not abandon the session prematurely.  For this
> reason, it might be necessary to permit the signaling from Patsy to reach
> Norma to allow Patsy to receive a call setup completion signal, such as a SIP
> ACK.  Once the second session completes, Mallory might cause DTLS packets
> sent by Norma to Patsy to be dropped.  It is likely that these DTLS packets will
> be discarded by Patsy as Patsy will already have a successful DTLS connection
> established."
[BoB] I think there can still be confusion what you mean with "Once the second session completes"; suggest changing to "Once the second session is established", if that was the intention.
Also, a couple of sentences before "Though Patsy...", there seems to be one too many "is complete" in this sentence: "Once signaling is complete on a session, ostensibly between Mallory and Norma, is complete."


> 
> > Section 4.2:
> > * I believe the first paragraph ("An attack on... ...vulnerable to
> > attack.") would also be helpful as first text of section 4. Move? Copy?
> 
> Good suggestion.  I moved it up.
[BoB] OK

> 
> > * "Validating that peers..." -> "Successful validation that peers..."?
> 
> Yep.  Expanded to
> 
> "Successful validation that the identifier matches the expected value means
> that the connection corresponds to the signaled session and is therefore
> established between the correct two endpoints."
[BoB] Good

> 
> > Section 4.3:
> > * "When used with SDP, the value includes..." -> "When used with SDP,
> > the value MUST consist of..."?
> 
> Thanks.
> 
> > Section 5:
> > * "Use of the "external_session_id"
> >    does not guarantee that the identity of the peer at the TLS layer is
> >    the same as the identity of the signaling peer"; sounds a bit
> > strange - isn't this what the draft is supposed to solve? Is "... when
> > used with session concatenation" meant?
> 
> This is a fundamental restriction of the design and with DTLS-SRTP in the
> absence of some sort of identity bindings.  As described here, an attacker can
> establish two sessions, call them A and B, with two different parties, call
> them Alice and Bob if you like.  It can send Bob's connection parameters (ICE,
> fingerprints,etc...) to Alice, and forward Alice's details to Bob in the same
> way.  This creates two signaling sessions (or 3pcc if you like), one between
> Alice and Attacker, and one between Attacker and Bob.  But there is only one
> media session between Alice and Bob.
> 
> I've done some rearranging here in an attempt to improve the flow of the
> section.  There are a few more words.  Let me know if it makes sense.
[BoB] Had a look at the pull request and I think the resulting text looks good.

> 
> > * "Similarly, data from one TLS connection..."; I assume "data" means
> > "security-related information", not "user data" (TLS payload)?
> 
> Yep, thanks.
[BoB] Changed text looks good.