[dcc2] Hi all :)

[Szymon Stefanek]

On Tuesday 10 February 2004 04:59, Dan Smith wrote:

> I agree that the SID must be present in each negotiation, but I am not sure
> about making positional parameters.  In fact it may be better to have no
> positional parameters, and just use boolean tokens and name=value pairs,
> even for the dcc2-command token.  We can still make the token required as
> you suggest without specifying a position, and the parsing may be even
> easier (tokenize on whitespace, then equals).

This is also a good approach.
I have tried to write down a couple of DCC2 messages following the token=value convention and
I even like how they look :D

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6,SSLv2,NAT

Immediately a couple of considerations:

One usually *requires* the connection to be encrypted. In fact, this is probably the most common case.
There should be a way to specify mandatory and non mandatory options. A first solution might be:

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6 Require=SSLv2,NAT
	"The sender requires the connection to be encrypted with SSLv2 and asserts that it is unable to listen"

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6,SSLv2,SSLv3 Require=NAT
	"The sender asserts that it is unable to listen and offers the possibility of encrypting the connection with SSLv2 or v3"

There is a problem when one simply wants the connection to be encrypted with one of the available protocols.
Again a first solution might be:

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6 Require=SSLv2,SSLv3,NAT
	"The sender requires the connection to be encrypted with either SSLv2 or v3"

This , in turn , lacks extensibility: it doesn't allow the clients to advertise new encryption protocols.
For example:

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6 Require=SSLv2,SuperSSL,NAT
	"The sender requires the connection to be encrypted with either SSLv2,SSLv3 or SuperSSL"

If the receiving client didn't know that SuperSSL is an encryption protocol it would be forced to reject the connection.
A better approach would be the following:

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Options=IPv4,IPv6,SSLv2,SSLv3,SuperSSL Require=CRYPT,NAT
	"The sender requires the connection to be encrypted and advertises three encryption protocols"

For better readability this could be even splitted in:

	DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 Encryption=SSLv2,SSLv3,SuperSSL Protocols=IPv4,IPv6 Require=CRYPT,NAT

This gives the additional information that SuperSSL is an encryption protocol.

...

> This may be a better approach if, aside from the DCC2 ctcp message, we wish
> to also create a historic DCC backward compatibility.  Jesse suggested (for
> historic dcc send and chat requests) we can append all the DCC2 tokens
> after the command, and if the client supports DCC2 then negotiation could
> take place with DCC2 ACCEPT.  If not, then we would follow the historic
> procedure for connection.  This would mean our clients would support both
> the new DCC2 and historic dcc with a DCC2 compatibility layer.

I think that this could work, but it requires several additional efforts from the programmer.
It would also require experimenting with the old clients to verify that most of them
handle correctly the messages with trailing "garbage". KVIrc, for example, would handle
the messages but warn the user about the additional data in the request.

> >- LIST and GET transactions
> Yes!  A way to specify shared files would be quite useful, but should we
> keep the DCC2 namespace only for connection negotiation?  We could define
> these in some other location that might be more fitting in the CTCP
> framework, perhaps CTCP LIST or OOB in a direct connection?

I think that the commonly implemented sub-protocols (e.g LIST,GET and maybe VOICE and WHITEBOARD)
should be included in the DCC2 standard.
Obviously they can end up in a separate document. The protocol developers should
keep these protocols in mind when designing the negotiation message exchange.
For example, the VOICE protocol requires the clients to agree on the codec, the rate and sample size.
Forcing the client to exchange these parameters outside of the DCC2 negotiation is somewhat bad design:
the receiving user would be first asked if he wishes to accept the connection and after that the connection
could fail because of a lack of common codecs.
The DCC2 spec should be flexible enough to accomodate additional parameters for each sub-protocol.
Even more: it should explicitly give the guidelines for adding new parameters to accomodate
new sub-protocols.

> Also, a solution to this might be the MULTI file sharing that is specified
> in a draft on dcc2.org.  This allows for sending multiple files and
> directories, but since the receiving client specifies which files to send
> from the XML list, it could easily be seen as a file listing and requesting
> mechanism! :)  It would also support file metadata, transfer privacy, and
> integrity checks plus anything else we want to add to the multi schema.

Yes, it could be done too. But I think that LIST is just an easier way.
MULTI could be an alternative option.

> That is a neat idea!  Exchanging auth passwords is still in plaintext if
> done over irc and there is a possibility of snooping.  Would it be better
> to do this out of band over a direct connection?  maybe an
> AUTHTYPE=basicpass DCC2 token to allow for different standardized
> authentication types and a handshake over a direct(encrypted) connection
> could be possible.  Perhaps we can incorporate this into MULTI. Any ideas
> on that?

I absolutely agree on the snooping problem. There should be different auth methods.
For example Auth=pass would expect an additional parameter Pass=<something>
while Auth=login would expect the client to send the pass in the direct connection.
In the handshake method the problem is still the same: think of a "GET" request.
The receiving client would need to first accept the connection then verify the
password and eventually drop it if the authentication fails. This would also happen
very often since many clients could simply "try" to get/send a certain file
specifying a random passowrd forcing the receiver (of the request) to accept the connection.
Another approach could be to add a two-stage handshake. The username would
be sent in the DCC2 negotiation and would allow filtering the "random" requests.
The password, then would be sent over the direct connection.

-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- Somewhere, something incredible is waiting to be known.
-
------------------------------------------------------------------------------