DNS & SIP Traffic

[VoipMan]

Hello,

We are implementing secure VOIP calls using TLS/SRTP in the next update of our softphone. Is there a way to handle the DNS part of this using Namecoin so countries cannot block the traffic or registration process?

Thanks.

VoipMan

[domob]

I'm neither an expert about DNS nor SIP, so please take my response with a grain of salt. But I think that Namecoin is potentially a very good solution for secure VoIP calls. Here's what I would do, though: Use id/ names instead of domains (you want to call a person, not a website, so SIP contact details seem to fit perfectly to id/ in my opinion). In the id/ name, you can put whatever you need to make the connection (SIP phone number, IP address if it is fixed, whatever - I don't know what would be best for this). Even better, you can also put in the SRTP key / certificate fingerprint - so you get authentication of the certificate for free.

[phelix]

Be aware all blockchain data is public, though.

[VoipMan]

The first issue in my mind is to be able to make calls without the country blocking the calls. The second issue is the security function of the calls. If we're able to just get the former, that would be fine too. The country blocking is the main issue. I'm sure there is a way to get around this once and for all.

It's less likely they can block based on the stream being encrypted. It's more likely they block based on IP or the type of packets/port number.

I think we need a form of distributed/decentralized way of registration or sending the packets without using the same IP every time. There must be a way to do this.

Thanks.

[johnc]

The first issue in my mind is to be able to make calls without the country blocking the calls. The second issue is the security function of the calls. If we're able to just get the former, that would be fine too. The country blocking is the main issue. I'm sure there is a way to get around this once and for all.

It's less likely they can block based on the stream being encrypted. It's more likely they block based on IP or the type of packets/port number.

I think we need a form of distributed/decentralized way of registration or sending the packets without using the same IP every time. There must be a way to do this.

Thanks.

So no real phone numbers, only virtual addresses for voip calls should be factible. I don't know if you notice but most betamax providers accept bitcoin now, and allow free standalone program user-to-user calls.
You could also somehow encrypt the actual number with something very easy but difficult or time consuming to check, like

id/username
{
name:username
twitter-enc:ehwthwerthedt
voip-enc:4thw9gsurgr
encrypt-version:0.1
encrypt-salt: salt
}

so, some fields are "hidden" with a encryption using the id/name & the salt. this way the program can very easily decrypt it but it's difficult to read over the blockexplorers. Maybe even your program can have another passphrase that is added.

For the IP problem, for example, if you are in china, you really need a VPN.

If you can't you are doomed, some ISP blocks all voip traffic and you have to use a random port and hide the protocol (change the package format or pass it fully encrypted).

It it's very difficult to protect yourself against a global actor, even TOR states that.

[VoipMan]

Let me clarify.

The main type of calls I'm talking about is softphone to real phone number calls. In this scenario the softphone to our server is secure if it's a secure call or just able to transit the country blocking problem. The second type of call can be a softphone to softphone call within our network. That is not as high a priority for us.

We do accept Bitcoin payment for services and probably were one of the first companies to do so a long time ago. We just never promoted it. BTW, any suggestions on who we can use to promote our services in the Bitcoin arena?

http://www.diamondcard.us.

Thanks.

[biolizard89]

The first issue in my mind is to be able to make calls without the country blocking the calls. The second issue is the security function of the calls. If we're able to just get the former, that would be fine too. The country blocking is the main issue. I'm sure there is a way to get around this once and for all.

It's less likely they can block based on the stream being encrypted. It's more likely they block based on IP or the type of packets/port number.

I think we need a form of distributed/decentralized way of registration or sending the packets without using the same IP every time. There must be a way to do this.

Thanks.

So no real phone numbers, only virtual addresses for voip calls should be factible. I don't know if you notice but most betamax providers accept bitcoin now, and allow free standalone program user-to-user calls.
You could also somehow encrypt the actual number with something very easy but difficult or time consuming to check, like

id/username
{
name:username
twitter-enc:ehwthwerthedt
voip-enc:4thw9gsurgr
encrypt-version:0.1
encrypt-salt: salt
}

so, some fields are "hidden" with a encryption using the id/name & the salt. this way the program can very easily decrypt it but it's difficult to read over the blockexplorers. Maybe even your program can have another passphrase that is added.

FYI, there is already an effort to standardize encryption of blockchain data. See https://forum.namecoin.info/viewtopic.php?f=5&t=2078 . I like your idea of requiring work rather than a key for some cases; can you bring it up in that thread so that we can keep track of the various desired features of encryption?

For the IP problem, for example, if you are in china, you really need a VPN.

If you can't you are doomed, some ISP blocks all voip traffic and you have to use a random port and hide the protocol (change the package format or pass it fully encrypted).

It it's very difficult to protect yourself against a global actor, even TOR states that.

Namecoin is very well-designed to protect the owner of a name from being censored, because it is difficult to seize names. It is also very well-designed to protect the viewer of a name from being surveilled, because reading a name from the Namecoin blockchain doesn't generate network traffic (all the wiretapper can see is that you downloaded the Namecoin blockchain). However, when a name links to an external resource, Namecoin is not particularly useful in preventing that external resource from being censored. For example, if a .bit domain links to an IP, the person viewing the .bit domain can be blocked from accessing that IP by their ISP. To fix that, you need some kind of proxy, preferably Tor or I2P or something like that. However, note that Namecoin can provide secure, human-readable names for Tor and I2P services, which Tor and I2P don't provide on their own. I've done VoIP over Tor before using Tox; it wasn't that great an experience, but if I absolutely needed it for my safety, I would find it totally usable.

(As an aside @johnc, Tor is not all uppercase. Sorry, I'm OCD about that. )

[cassini]

The initial problem VoipMan needs to solve is how to fetch the latest DNS data from the Namecoin blockchain. Depending on Diamondcard's infrastructure, e.g. whether a registrar server's IP can be changed easily, and if there are registrar servers inside or outside the blocking countries, the softphone software could do this, for example:

voip_minimal_blockchain_data

voipman.png (56.17 KiB) Viewed 6568 times

This "Namecoin read-only client" could be anything that simply establishes a connection to one of the several hundred Namecoin peers in the peers.dat file, updates the peers.dat file, downloads the latest 200 blocks and looks for the relevant id/ or d/ record. A few hundred lines worth of Python code should be sufficient for these tasks. This scenario, however, requires updating the Namecoin record once a day (hence the 200 blocks).
Alternatively, the softphone code could contain a Namecoin read-only SPV client. I have no idea, though, how much memory the SPV code consumes and how much coding effort this requires.