[dcc2] Multi headers + metadata

[Phoenix Fyrestar]

My idea behind sending a key through SSL was (and remember, I could be way
off base here with my limited knowledge of crypto) was that if we wanted to
have a spec for some higher level of encryption than SSL offers, or for some
other reason didn't want to use SSL as the primary encryption means, that
sending just a key over SSl might be a viable way of doing things.

I think the way the current spec is written is pretty much what I was trying
to say, so I don't really have any problems there.

On 4/28/04 9:18 PM, "Jeremy Iverson" <jeremy at algenta.com> wrote:

> 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
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2