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

Adam Roach <adam@nostrum.com> Tue, 30 October 2018 19:00 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726CB130DFA for <mmusic@ietfa.amsl.com>; Tue, 30 Oct 2018 12:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muPCPtcxvRvM for <mmusic@ietfa.amsl.com>; Tue, 30 Oct 2018 12:00:25 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB3F130EA4 for <mmusic@ietf.org>; Tue, 30 Oct 2018 12:00:25 -0700 (PDT)
Received: from Svantevit.attlocal.net (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9UJ0Ns2065499 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Oct 2018 14:00:24 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.attlocal.net
To: Martin Thomson <martin.thomson@gmail.com>
Cc: mmusic@ietf.org, draft-ietf-mmusic-sdp-uks@tools.ietf.org
References: <deaaef8c-3cb9-ede3-c94b-1774f7c4c880@nostrum.com> <CABkgnnVkAdf0+Drz7xh3Q39AY_YjcdykgkV31OAyzBRTQsHSaA@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <f5cda451-fb30-c080-5fd0-d2629c0a6ec1@nostrum.com>
Date: Tue, 30 Oct 2018 14:00:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CABkgnnVkAdf0+Drz7xh3Q39AY_YjcdykgkV31OAyzBRTQsHSaA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/HA3n_yEKCt_JbiD8PgSiVcq5A4o>
Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-uks
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 19:00:37 -0000

On 10/30/18 2:01 AM, Martin Thomson wrote:
> On Tue, Aug 28, 2018 at 9:16 AM Adam Roach <adam@nostrum.com>; 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