Direct End to End Secure Chat Protocol: Difference between revisions

Revision as of 03:16, 15 April 2015

Latest revision as of 23:59, 21 August 2025

(8 intermediate revisions by 5 users not shown)

Line 1:

{{unreferencedrefimprove|date=AprilAugust 20152025}}

The [[Internet Assigned Numbers Authority]] (IANA) officially assigned port 4605 to the SixChat End2End Direct secure messaging protocol created by Sixscape Communications, Pte. Ltd. The assignment was issued by IANA on 11th11 September, 2014, and.<ref>It is listed in the official IANA resource registry at httphttps://www.iana.org/assignments/service-names-port-numbers</ref>

The [[Internet Assigned Numbers Authority]] (IANA) officially assigned port 4605 to the SixChat End2End Direct secure messaging protocol created by Sixscape Communications, Pte. Ltd. The assignment was issued by IANA on 11th September, 2014, and is listed in the official IANA resource registry at http://www.iana.org/assignments/service-names-port-numbers

There are a very limited number of port numbers, which are assigned by IANA for protocols recognized as viable, complying with current protocol design standards, and not already covered by existing Internet standards. For example, port 25 was assigned to the SMTP email protocol many years ago. This provides a standard port and reduces conflicts with other protocols. The technical review of the SixChat protocol was performed by [[Lars Eggert]], the distinguished chair of the [[Internet Research Task Force]].

Line 9 ⟶ 8:

End2End Direct messaging requires globally routable ("public") IP addresses for all nodes involved. It is incompatible with NAT (Network Address Translation). It can work within a private internet (a subset of the IPv4 Internet that uses a flat address space with no NAT), or between any two nodes on the public IPv6 Internet. NAT prevents incoming connections, so any user to user messaging must use intermediary servers.

End2End Direct Messaging has several advantages over indirect messaging via intermediary servers. End2End Direct traffic is highly decentralized, going only via the shortest network path between communicating parties. This makes it more difficult to intercept, monitor or block. Intermediary servers introduce reliability, salability and security issues. It is much easier to monitor or block network traffic that must go through a small number of "choke points".

It would be possible to use DNS for nodename resolution (mapping nodenames to IP addresses) for End2End Direct messaging, but DNS is increasingly insecure, has no per-user authentication for registration or updating, and takes a long time to propagate. IRP provides a highly secure address registry with per-user authentication (usually using X.509 certificate based Strong Client Authentication). Registered information is immediately available.

It would be possible to use DNS for nodenamenode name resolution (mapping nodenamesnode names to IP addresses) for End2End Direct messaging, but DNS is increasingly insecure, has no per-user authentication for registration or updating, and takes a long time to propagate. It has no good way to publish X.509 client digital certificates for users, and can only publish the address of a given network node, not the node most recently used by a particular person. IRP provides a highly secure address registry with per-user authentication (usually using X.509 certificate based Strong Client Authentication). Registered information is immediately available. IP addresses of highly mobile nodes (e.g. smart phones) may change frequently as the connect to different WiFi access points. This does not work well in the DNS model.

The SixChat End2End Messaging protocol is a streamstreaming protocol (tcp based, connection oriented). It cannot be secured with TLS, which is an inherently Client/Server technology. It provides mutual strong authentication using only X.509 client digital certificates (no server cert involved), and symmetric session key exchange (via public/private key encryption or Ephemeral Diffie Hellman Key Exchange). ItThis handshake is based on the design of TLS, but is not Client/Server, rather between peers. Unlike TLS, it lies entirely within the Application Layer the protocol messages are based on XML.

Nodes supporting End2End Direct messaging are neither client nor server, but must be able to originate and accept network connections (hence have characteristics of both clients and servers). Such a node is called a "User Agent".

==References==

The SixChat End2End Messaging protocol is a stream protocol (tcp based, connection oriented). It cannot be secured with TLS, which is an inherently Client/Server technology. It provides mutual strong authentication using only X.509 client digital certificates (no server cert involved), and symmetric session key exchange (via public/private key encryption or Ephemeral Diffie Hellman Key Exchange). It is based on the design of TLS, but is not Client/Server, rather between peers. Unlike TLS, it lies entirely within the Application Layer the messages are based on XML.

{{reflist}}

[[Category:Network protocols]]

{{uncategorised|date=April 2015}}{{stub}}