Starting from TCP and then upgrading to tls is quite different to current tls transport mapping document. If we decide to do UPGRADING, we may first need a TCP transport mapping for Syslog, and then define a specific string to indicate the other side to upgrade to TLS. We currently assume Syslog has a IANA allocated port for tls transport mapping, we may not need such complexity on upgrading.
FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to this draft, RFC2817(Informational) is on upgrading. > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 06, 2006 2:51 AM > To: Balazs Scheidler; Chris Lonvick > Cc: [EMAIL PROTECTED] > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > Working GroupLastCall: syslog-tls document > > ----- Original Message ----- > From: "Balazs Scheidler" <[EMAIL PROTECTED]> > To: "Chris Lonvick" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, September 05, 2006 9:18 AM > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > Working GroupLast > Call: syslog-tls document > > > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > > Hi All, > > > > > > Please do consider the version field. If we don't have one, we > > > would have to live forever with the decisions we are making now. > > > Having a version number in there would allow a future group to > > > re-decide things (like byte-count v. special character) > and to just > > > change the version number rather than go asking for a new > port number - or have a flag day. > > > > > > Please review the document and send in your thoughts on this. > > > > Sending the version field is a good idea in general, however I feel > > that adding it to _every single_ message in a conversation is too > > redundant, apart from the extra bandwidth used, it causes > ambiguities > > what to do when different messages use a different version number. > > > > The version should be associated with the channel, and not > individual > > messages. > > > > Having a simple negotiation at the start would IMHO be way better. > > Something like: > > > > HELLO <capabilities> > > OK <capabilities> > > START > > OK > > <message stream> > > > I too like starting with a simple negotiation. I notice that > other applications that started with TCP and then added > security have used character strings such as AUTH TLS which > has the advantage of readily adding in SSH (or anything else) > in the future. > I also like being able to add later a choice as to which end > is client and which server since I foresee problems here with > security credentials (most other applications have the server > on a well-connected device well able to verify secuirty > credentials, something a remote network box is less well able to do). > > Tom Petch > > > -- > > Bazsi > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
