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

[Adam Roach <[e-mail]>]

On 10/30/18 2:01 AM, Martin Thomson wrote:
> On Tue, Aug 28, 2018 at 9:16 AM Adam Roach <[e-mail]> 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).


Yes, this comment was about signaling integrity.


> 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


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.


> 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.


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


>> 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.


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.


>> 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.


Sounds good to me.


>
>> 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.


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.


>> §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 look forward to seeing the clarification. :)


>> 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.


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