[dcc2] Multi headers + metadata

[codemastr]

> I agree.  For encryption I think we should standardize on the fastest
> "acceptably secure" encryption method,  blowfish seems to fit this quite
> well.
Blowfish is bad. To use blowfish, if I remember correctly, you need to
transmit the key. The same key is used for encryption and decryption. So
here is the sample session:
sender> KEY 1234
receiver> OK
sender> DATA kjsdhkjhfdskfhsdhfsdhfdjhrejnfsdjhfieohfsdjhfsdhfsdhje...

Then the receiver decrypts that data using key 1234. Well, you just defeated
the whole purpose of encryption! You're trying to prevent packet sniffing
and such. Well, the key is going to be transmitted in plaintext. So the
packet sniffer can get the key and use it to decrypt the data. All security
benefits are lost. Hence why asymmetric encryption was created, so you don't
need to transmit a key/password. If you're using blowfish, there is no
reason to do any encryption at all since you're not adding much security,
and you're making the transfer size larger.

Furthermore, SSL does more than just encrypt, it does identity verification.
When you are excepting potentially dangerous files from people, being able
to tell who is who is a very good thing. Lastly, I definately want to see
compatibility with small devices maintained, but not at the expense of
everyone else. With XML, changing to another format doesn't really harm
anyone. But, switching from SSL to Blowfish causes a loss in security and
authenticity. That's a big hit in my mind. Of course though, the encryption
system was designed to support multiple algorithms. The draft mentions SSL3
and TLS. More could be added, that's fine by me (though I still think
symmetric encryption is a bad idea), but I would not say get rid of the
other features just because some won't support it.

> I'm not entirely sure that we should go with a weak compression algorithm
> however.  While I personally see encryption as a necessary feature that
> should be supported by every client, compression I see more as a nice
thing
> that should be incoperated into the standard, but not 100% neccessary.
> Mainly because the lower-memory machines you refer too are unlikely to be
> transfering files large enough for the lack of compression to matter
> signifigantly,  or the slowness of it to really matter signifigantly.

The memory availability/processor speed is not the only factor when
determining about encryption. For example, the JVM that most browsers use,
does not support encryption, so Java applets cannot implement DCC2. You also
have legal issues. Why is it that most clients don't implement IRCS (SSL
over IRC)? US law. If a US developer releases a program containing
cryptographic code, he/she must ensure that the program will not be
downloaded in nations on the State Department's list of terrorist nations.
That is nearly impossible to do. Therefore, US programmers (especially
open-source programmers who can't afford a lawyer) generally do not release
cryptographic programs on the web. So basically, what this does is, it makes
it so virtually all U.S. made IRC clients can no longer exist. Even more so,
if I remember, encryption is still illegal in China. So by requiring DCC to
support encryption, 1/6th of the world's population can no longer use IRC
because it would be illegal for them to have a client that contains
encryption technology. I agree, encryption is a good thing to have, but it
should not be required to use DCC.

> I know gzip allows you set how aggressively compressed a file is.  Could
we
> allow the client to specify what level of compression it would like?  for
> example: compression=0...9 where 0 is no compression andn 9 is maximum
> compression.

Well do keep in mind that not all compression mechanisms allow this. To be
robust, you want to do something like HTTP, where new compression tokens are
able to easily be added. Meaning, if tomorrow someone invents an algorithm
that gives you 99% compression, you are certainly going to want to be able
to use that instead of gzip! So you need to design it with universal support
in mind. If you add the compression level, you remove that ability, or at
least hinder it.

If it were added though, some specifics would need to be worked out. What
happens if the sender does not oblige? You say you want it to be 2 and I
give you 7. Does it get dropped? Does it just accept whatever I give? Also,
you ask for 9, but I can't do 9. My PC is too slow. What am I to do? Should
I just disregard and send a lower compression level? Or just terminate the
send? Also, what happens if a client advertises that it will now send using
4, but the data is actually compressed using 6?

-- codemastr