On Mon, 27 Apr 2020 at 18:08, Michael Thomas <mike@xxxxxxxx> wrote:
On 4/27/20 8:13 AM, Christopher Morrow wrote:
> (Don't have an answer, but a question or three)
>
> On Mon, Apr 27, 2020 at 10:34 AM Michael Thomas <mike@xxxxxxxx> wrote:
>>
>> On 4/27/20 7:28 AM, Dave Cridland wrote:
>>
>>> Yeah, I just noticed that Zoom claims to use SIP poking around.. The question is not whether it's SIP per se, but whether there will be inter-carrier anything. If there is inter-carrier, then the problem will remain, especially when it traverses an intermediary proxy.
>>
>> Zoom interoperate with SIP, I think. But they used to interop via XMPP as well, and I believe they use XMPP internally. They stopped external interop with XMPP when Google and Facebook ceased to use it, I think.
>>
>> Ok, that probably what I was seeing. I wasn't actually setting out to see if they used SIP :)
> So, if you setup a service (zoom, for your example here) and you
> 'guarantee' to your users that the path is encrypted (for instance),
> and you enable federation in the XMPP sense, how do you keep your
> guarantee?
You can't unless the payload itself is encrypted with keys known by each
end user. That's what my guess is going on with Whatsapp, but I know
nothing about it.
Well, WhatsApp is bastard-son-of-XMPP, and has end-to-end cryptography based on the Signal ratchet, with key distribution based on trust-on-first-use. But it's also single-provider, so the question isn't really answered.
But normal XMPP works the same way as email, really - I can be assured that my connection to my server is encrypted. If I trust my provider, I can accept their assertion that their connection to the other party's server is also encrypted, and finally if I trust that provider I can accept that the other party's server session will be encrypted. To get more provable than that, we need to perform end-to-end encryption of some form (OMEMO - another Signal variant - or in the future MLS), and then do some kind of identity key verification to assure the endpoints.
[I accept we may be seeing an alarming amount of topic drift here].
But to get somewhat back on topic, this is only signalling - if you can establish media, then that can prove the endpoint as well, and that has an entirely different encryption path - and "all" you need to do there is pass a signed [derivative of the] [public] key through the [untrusted] signalling path, I'd have thought. Assuming you can use PKIX to do the heavy lifting here, that seems like a reasonable start to cryptographically provable caller identity.
[I accept we may be seeing an alarming amount of topic drift here].
But to get somewhat back on topic, this is only signalling - if you can establish media, then that can prove the endpoint as well, and that has an entirely different encryption path - and "all" you need to do there is pass a signed [derivative of the] [public] key through the [untrusted] signalling path, I'd have thought. Assuming you can use PKIX to do the heavy lifting here, that seems like a reasonable start to cryptographically provable caller identity.
>
> repeat with gtalk or facebook-chat or aol-instant-messenger...
>
> For the shaken/stir conversation what's the actual problem trying to be solved?
> I thought; "Did the person I see calling me actually make this call?"
> or perhaps: "Is the identity I see really the identity that initiated
> the call?"
It's is exclusively trying to bind an e.164 address(range) -- either
directly from a tel: uri, or harvested from a sip: uri -- to the carrier
to whom it is delegated. I haven't read enough of the documents to
understand exactly how they are doing that, but one trip through SS7
land breaks any end to end traceability so I'm sort of dubious how well
this will work in practice. Scammers are not dumb, after all.
Which is why I think it's solving the wrong problem. At least with
email, DKIM and widespread adoption of SMTP-auth gives you a pretty
reasonable expectation that if it says that it came from gmail, it
actually came from a person with access to that gmail account (legit or
otherwise). It would be nice to have a similar level of confidence for
non-e.164 address sip: uris were they to become popular for some reason.
For identity verification on XMPP, I trust my server and in turn it can prove the remote domain, and beyond that trust (or not) that domain's servers not to lie about the user identity within that domain. On SIP, like email, I understand it to be more complicated, because the path is not nearly as constrained as it is with XMPP, but fundamentally with DKIM etc you are proving the provider's identity (ie, the domain) and not that of the end user. That may well be enough in most cases, but it's somewhat reliant on having a few providers with much to lose.
But again, what we can do relatively easily is prove the endpoints of the RTP security - we might be able to do that prior to accepting media, along the signalling path, but the worst case is that we establish media in order to get a cryptographically established caller (or responder) identity.
Dave.
