[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: STARTTLS and ircd
Quoting Thomas Kuiper <engerim@xxxxxxxxxx>:
> > but maybe it's time for cleaning up the C:line and append a
> > new field ... something like 'options' (C(rypt), Z(ip),
> I think "abusing" the port field in most cases or adding another
> decimal field is the best (so you can use hex lines like with services).
Mh, Port field is mostly used :)
A new field at the end would be the best, I guess - if it doesn't
exist, there are no options, so the link is neither crypted nor
zipped.
> You can still use zip compression over a SSL link :)
That was my oppinion.
> > If u have too much time, u could implement a re-negotiation
> > on active links (if config changes) too, but thats for fun :)
> if sendq > 400000 zip = true? :)
No, if new options after rehash, establish them on active links.
As I said - just in case u're bored :)
> > And maybe it might be better to add a general future-friendly
> > "options negotiation" than implementing special protocol tags
> > for every new feature.
> Yes. Maybe make ircd ESMTP like, telling you what commands he
Or telnet. I'd prefer a telnet like negotiation.
something like:
WANT CZ (or SUPPORT?)
USE Z (what's with USE ZC? :))
New features start after the USE, not after the WANT, so the remote
service just can refuse/ignore them (I guess, SUPPORT sounds better -
giving it a more optional touch) - maybe it doesn't know them.
Neither SUPPORT nor USE are mandatory for connection establishement,
can be sent as long as a connection lives, can be sent prior to
PASS but not before USER/SERVER has been sent - to give the "victim"
a chance to prevent Denial of Service.
A USE can be sent more than once - the link will be reconfigured then.
Or if u want it verbose:
SUPPORT TLS gzip Rot13
USE gzip TLS
Well, maybe hex too ... I don't care :)
But... Character Strings or option lists allows to be more flexible
and put up some semantics ... e.g.: compressing a crypted link or
crypting a compressed link?
(Don't tell me something about crypto like "ever crypt the zipped
thingy" - what, if I want a second crypto layer over the first one?)
Hex avoids them.
As u like it :)
Oh, we don't need a STOP or something, to fall back :)
SUPPORT TLS gzip Rot13
USE gzip TLS
[compressed crypted traffic]
USE TLS
[crypted traffic]
... something like that :)
> supports by sending EHLO or so, but I think that needs more thinking.
Of course.
But we had tenths of years without crypto, so I guess, we can live
without it two weeks longer, if the two weeks are the design phase
for some intelligent negotiation making it possible to implement
(and use!) new features faster for the future :)
(My suggestion is not intelligent, it's just a result of 10 mins
typing, so it's only a suggestion, not a proposal :))
regards,
--
Mario Holbe <Mario.Holbe@xxxxxxxxxxxxxxxx> http://www.tu-ilmenau.de/~holbe/
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten
-----------------------------------------------------
This mail sent through IMP: http://web.horde.org/imp/