[dcc2] Multi headers + metadata

[Jeremy Iverson]

Regarding encryption (and compression) in the draft: the way it
currently reads is that the initiating client sends a list of
capabilities, and the other client decides whether it can communicate
with it. If it can, a connection will be established; if not, the 2nd
client will refuse to connect, and let the first client know why. So
the first client can tell the second client that it supports SSL3,
TLS, and plaintext. If the second client doesn't know encryption, the
connection will be in plaintext. Optionally, the first client could
NOT send plaintext as an option, in which case the second client will
have to refuse the connection if it cannot handle the encryption.

When dealing with symmetric encryption algorithms (ones that require
key exchange), yes, sending the key over SSL is a secure way to do
this key exchange. Of course if the key is going over SSL anyway, a
point might be made for just having the entire connection over SSL.
Any thoughts on that?

Jeremy


-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
Of Phoenix Fyrestar
Sent: Wednesday, April 28, 2004 9:00 PM
To: DCC2 Working Group List
Subject: Re: [dcc2] Multi headers + metadata

You make a number of convincing arguments.

As far as the problem with having to send the key over the network,
thereby eliminating the benefit of encryption, what about the
possibility of sending a key over ssl?  My knowledge of cryptography
is rather limited, so I'm just throwing a few ideas out there.

The problems with the legal difficult of distrubuting a cryptography
enabled program from within the us is a more difficult one, but I
think that we should not omit it from the protocol just because an
opressive regime in the US is stifeling it's citizens privacy.  If a
client chooses not to support encryption for whatever reason, then
that client will simply choose to talk only in an unencrypted manner.

What I was referring to when I said that I saw encryption as a
neccesity is that I think it is something that should be defined in
the protocol for sure, and should be able to be either included or not
included by the client authors.  There should be a way of handling
this, perhaps sending a request for an encrypted chat that the client
can either accept or decline.

With regards to the question of a compression mechanism, I agree that
there should be room to add another compression method later, but we
should still dictate a universal bottom line I think.  Something to
say that all compression enabled clients will support at least
compression algorithm foo.

The compression levels I reffered to were there only as an idea if we
accepted a supporting compression algorithm, and as a means to show
one possible benefit of choosing gzip.

I think I can better explain the idea I had about choosing a
compression level though.

The client either chooses by default or allows the user to choose a
maximum compression level.  In the file send meta-file there would be
a line that gose something like:
	maxcompression="6"
or whatever.  That way the receiving client would know what the
maximum requestable compression level is, it could then either by
default, by a stored value, or by asking the user, send in it's reply
the requested compression level.

Of course it is possible that some rouge client may send higher or
lower level compression than is asked for,  but I do not see that as a
protocol problem so much as a social one.  The same senario could be
said for anything.  What if the user wants to engage in an encrypted
chat and tells the reciever that the key is "12345" when it is really
"54321", the person on the reciving end will just not deal with that
person anymore.


_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2