Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-uks

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 18:01:08 +1100

On Tue, Aug 28, 2018 at 9:16 AM Adam Roach <[email-masked]> wrote:
>
> I was asked by the MMUSIC chairs to review draft-ietf-mmusic-sdp-uks.
>
> At a high level, I don't think the proposed fix works for SIP in current
> deployments; but I also doubt that the described attack can be credibly
> mounted in SIP. Specific details below.

On the first half, maybe there's a misunderstanding about what
properties are reasonable to assume.  You assume a far worse baseline
for what is deployed, which I agree is the case, but that doesn't
invalidate this technique completely.  More below.

On the second half, I wholeheartedly agree.  I frame this as the "most
boring attack ever" when I originally presented it.

> §2.2:
>
>  >  The use of TLS with SDP depends on the integrity of session
>  >  signaling.  Assuming signaling integrity limits the capabilities of
>  >  an attacker in several ways.
>
> This is generally a bad assumption. The penetration of TLS in SIP
> deployments is
> (by my understanding) incredibly low.

Just to be clear, this isn't addressing the TLS used on the signaling
path.  It's the use of TLS with SDP, which means media path.  I hope
that's clear enough and you are just making a point about the complete
lack of integrity for SIP signaling (which I agree is the case).

I have a similar understanding regarding TLS on the signaling side.
However, the security of a=fingerprint depends critically on integrity
at some level, even if we don't concretely have it. Maybe I'm
misunderstanding your point, I might infer an argument akin to "SIP is
a complete mess, so no point fixing SDP", but I

In any case, I would rather state it as a precondition/assumption and
move on.  RFC 8122 already makes the integrity point fairly pointedly:

   It is the responsibility of
   the encapsulating protocol to ensure the integrity of the SDP
   security descriptions.   -- https://tools.ietf.org/html/rfc8122#section-7

Yes, the rest of that section goes on to mention key continuity
mechanisms and other such hand-waving, but in the end a=fingerprint
doesn't really work without integrity.

WebRTC identity and RFC 8224 (and friends) take steps to protect at
least the relationship between a=fingerprint and identities, which
goes a long way.  If those are used, it's a different story.  To the
extent that people deploy these things (we still hold hope for
PASSPoRT) we're OK with respect to our stated goals, even if the rest
of the signaling traverses hostile territory with protection less
effective than one of those little drink umbrellas.

> The unnumbered figure in this section (consider adding figure numbers)
> doesn't
> make sense to me.
>
>       Norma               Mallory             Patsy
>       (fp=N)               -----              (fp=P)
>         |                    |                  |
>       1 +---Offer1 (fp=N)--->|                  |
>       2 +-----Offer2 (fp=N)-------------------->|
>       3 |<--------------------Answer2 (fp=P)----+
>       4 |<--Answer1 (fp=P)---+                  |
>         |                    |                  |
>       5 |======DTLS1====>(Forward)====DTLS1====>|
>       6 |<=====DTLS2=====(Forward)<===DTLS2=====|
>       7 |======Media1===>(Forward)====Media1===>|
>       8 |<=====Media2====(Forward)<===Media2====|
>         |                    |                  |
>       9 |======DTLS2===========>(Drop)          |
>         |                    |                  |
>
> Presumably, DTLS1 corresponds to Offer1, while DLTS2 corresponds to Offer2?
> Please make that explicit.  Also, it took me a few beats to figure out that
> "fp=N" meant "Fingerprint = Norma," so it might be worth explaining that
> notation.
>
> Where I get lost, however, is around step 6 (refer to the step numbers
> above),
> which is described as:
>
>     Mallory also intercepts
>     packets from Patsy and forwards those to Norma at the transport
>     address that Norma associates with Mallory.
>
> This seems to introduce a much stronger requirement on the attacker; namely
> that they have the ability to intercept traffic bound for one of the
> victims.
> This should be discussed in section 2.2. I'll note that, for step 9 to work,
> the attacker must have the ability to cause packets to be dropped -- so
> merely
> being able to observe and inject traffic isn't sufficient. Mallory has to
> literally be on-path and effectively acting as network infrastructure.

Correct.  I had assumed that as part of the standard threat model:

   Applications protocol designers MUST NOT assume that all attackers
   will be off-path.   -- RFC 3552

But I will make that clear.  I don't believe that this is a general
constraint on attack here, just for this particular, implausible
example.

> The other thing that confuses me is that this scenario doesn't describe a
> credible mechanism by which Mallory might compel Norma to engage in some
> really strange call behavior; namely, the initiation of two outbound calls
> simultaneously.

I think that with the framing you suggest (strengthen generically as
opposed to block a specific exigent threat), that doesn't matter very
much.  As in, the example only exists to illustrate the possibilities
available to an attacker, not to convince someone that their
deployment is broken and needs to be fixed post haste.

> In general, I don't think this works because of the issues involving SIP
> signaling integrity that I discuss above.

The analysis we did suggests that this is OK.  SIGMA shows us that
authenticated identity protocols don't as much depend on the strength
of the binding between identity and key, but depend more on the
identity being included in the session - and validated by peers.  That
is, you don't defend against unknown key share attacks by bolstering
the CA processes and having them check that keys are controlled by
applicants.  Instead, the protocol needs to facilitate the check.
It's a little counter-intuitive, but the explanation in the paper is
really good if you want to understand this better.

> I think you need to somehow
> bind the
> PASSPoRT identity into the DTLS signaling, rather than using yet another
> identifier that isn't bound to identity. I haven't worked through all the
> details here, but it probably looks a lot like what you've proposed for
> WebRTC.

This is right.  I didn't integrate PASSPoRT defenses originally
because that was in flux.  But the same technique we use for WebRTC
identity works for PASSPoRT.  The two are very similar in form, which
isn't accidental, so the same technique works perfectly.  I've updated
the draft for that.

The worst wrinkle there is that the the short form of a PASSPoRT
doesn't work.  That would be vulnerable to a duplicate signature key
selection attack, the likes of which hit ACME a few years ago (see
https://www.agwa.name/blog/post/duplicate_signature_key_selection_attack_in_lets_encrypt).
We'll need the full form.

> §3.1:
>
>  >  Endpoints MUST check that the "id" parameter in the extension that
>  >  they receive includes the "tls-id" attribute value that they received
>  >  in their peer's session description.  Comparison can be performed
>  >  with either the decoded ASCII string or the encoded octets.
>
> What is the distinction being made here between "decoded" and "encoded"
> forms?

I've tried to clarify.  In this case, most internal representations of
"string" and "sequence of octets" will have the same pattern of bits
in memory, so the risk of an actual problem is low, but there are
domain transformations in play here.

> I'm a little surprised not to see a discussion of cryptoagility in here.

Hadn't you heard?  It's a post-cryptographic-agility world now.  The
view here is that it is easier to define a whole new TLS extension
than it is to deal with the possibility that the codepoint you used to
signal which function you used has ossified.  I'll add a note.

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Oct 2018 14:00:17 -0500

> lack of integrity for SIP signaling (which I agree is the case).

Yes, this comment was about signaling integrity.

> a complete mess, so no point fixing SDP", but I

No; however, I think it bears mention in the document that SIP as it is 
typically deployed today needs significant operational updates before it 
meets this precondition. Acknowledge it and move on.

> effective than one of those little drink umbrellas.

That's the headline point, and why I suggest a move from session ID to 
PASSPoRT.

> constraint on attack here, just for this particular, implausible

There's probably not much point in debating whether that's true, since 
the flaw stands either way. My complaint here is mostly one of 
readability: until this point, it was not clear that the attack being 
described required Mallory to be on-path. I had to infer it from this 
capability.

> deployment is broken and needs to be fixed post haste.

Sounds good to me.

> We'll need the full form.

That sounds good. I haven't had a chance to read over the SIGMA paper 
yet, but taking your statements on their face, it sounds like we have a 
reasonable path forward.

> domain transformations in play here.

I look forward to seeing the clarification. :)

> signal which function you used has ossified.  I'll add a note.

Today I learned...

(Are these bits of institutional knowledge being collected anywhere? I 
reviewed TLS 1.3, and don't recall seeing this principle described.)

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Oct 2018 11:05:56 +1100

Thanks Adam,

I realize that I failed to push the update, but you should be able to
preview the changes here:

https://martinthomson.github.io/sdp-uks/draft-ietf-mmusic-sdp-uks.html

Thanks for clarifying on the signaling integrity point.  That helps a lot.

> That's the headline point, and why I suggest a move from session ID to

This might be asking for a bigger change that what I've implemented,
and I might not be able to do that sort of change quickly.  Are you
suggesting that the identity bindings stuff (WebRTC and PASSPoRT) be
made the primary focus of the document?  I think that I agree, but
I'll need a bit more time to knock this into shape.  I've taken ill,
so I'm working at reduced capacity, even if there weren't the usual
pre-meeting deluge to deal with.  I can tweak things to shift the
emphasis more if that helps.

> reviewed TLS 1.3, and don't recall seeing this principle described.)

No, this design choice is an extension of the ideas from
https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-00 and
other places.

I should be less trite in my explanation.  Cryptographic agility is
still hugely important.  Being able to deploy new crypto is a critical
design consideration.

However, the view is that where existing, well-tested mechanisms can
be used to deploy new crypto, we should rely on that as much as
possible rather than adding new secondary points of articulation that
might fail when we need them.

In this case, I expect SHA-256 to remain in use a very long time.  If
we added a new field for the hash algorithm, that would be a new
extension point.  That extension point is unlikely to see any use in
the foreseeable future (it's SHA-256 all the time!).  Come the time we
want to change it to Kangaroo Twelve or whatever the next hot thing
is, we might find that implementations choke.  That makes a new
extension point more of a liability than an asset.

In this particular case, new extension codepoints aren't scarce enough
to worry about having to burn another one when the time comes to
update the algorithm.  So that's the best option.

Sadly, RFC 7696 doesn't capture this idea well, it even seems to
discourage the practice.  But there you go.

(Sorry, that was long.  Hot-button topic, I guess.)

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Oct 2018 19:58:37 -0500

On 10/30/18 7:05 PM, Martin Thomson wrote:
> I'll need a bit more time to knock this into shape.

I think that's the practical upshot, yes -- both because I think it's a 
much better solution to the problem and because it seems a lot more 
sound to apply effectively the same mitigation to both SIP and WebRTC. 
Can you quantify "a bit more time"? I wasn't expecting a final version 
by Thursday's MMUSIC session; but "some time next year" would be cause 
for reconsideration of a few things.

> I've taken ill,

I'm sorry to hear that, and I hope you get to feeling better soon.

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Oct 2018 12:08:59 +1100

> for reconsideration of a few things.

I think that I can probably manage something before the end of November.