Hi Eliot, Having discussed this further with you and Rainer, I tend to agree the changes are smaller than I originally thought.
So that the WG can properly assess this, can you produce an individual draft with the proposed changes, so the WG can discuss the changes and their impact, and decide whether to accept the draft as a WG item at this point? Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: Eliot Lear [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 27, 2007 9:35 AM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] RFC3195bis > > > > Hi, > > > > Hi. > > > The WG consensus points that affect syslog-sign dependencies on > > RFC3195 are: > > > > 1) remove RFC3195 references to RFC3164, and use the WG -protocol- > > document as the appropriate replacement reference. > > > In most cases this is fairly straightfoward. As I indicated in my > email, and as Rainer discussed, there seem to be one or two > points that > will require discussion, but I envision that discussion being short, > quite frankly. > > 2) There should be a separation of transport mappings from protocol, > > in the same way that the UDP and TLS transport mappings have been > > separated from the protocol. i.e., make RFC3195 a BEEP transport > > mapping independent of protocol processing. > > > As RAW and what we have dubbed TARTARE are just that - raw, > this should > be no great difficulty. > > 3) syslog-sign should remove dependencies on specific transport > > mappings, to make it transport-mapping-independent. This would allow > > us to remove the syslog-sign dependencies on RFC3195. > > 4) As a result of the RFC3195bis work, the status of RFC3195 would > > become "obsolete". > > > > That is what Chris and I agreed to, and that is effectively what was > > proposed to Sam as the change to our charter (I wasn't as > wordy in the > > request). > > > > -- > > Chris and I also discussed RAW and Cooked mode. > > > > Achieving #3 may be straightforward vis-a-vis RAW mode. > > > > Achieving #3 may be difficult vis-a-vis COOKED mode. Cooked mode > > creates interdependencies between the BEEP transport and syslog > > processing. This creates complications with achieving #3, but there > > are probably workarounds. It appears that Cooked mode has not been > > widely implemented, and Chris and I agreed that previous discussions > > on the list indicated limited interest in cooked mode. As > part of this > > work, we recognized that we might reach WG consensus to eliminate > > cooked mode from RFC3195bis. > > > > -- > > Something got lost in the translation to the editors. > > > > Chris and I did not agree that Cooked mode should be obsoleted. We > > agreed that it should be discussed on the list to see if that was WG > > consensus. > > > > If one is going to do an update of RFC 3195 one should take > into account > deployment experience since it was written, as well as other relevant > facts. As Rainer has mentioned, neither he nor the authors > know of any > deployment of COOKED mode - modulo the one comment made on > this list. > In addition, it is my understanding that this group has just gone > through great lengths to allow for transmission of structured > data that > is independent of transport. This model is not reflected in the > existing COOKED mode. Were one to take RFC 3195 to draft > standard one > would in essence do exactly what we are doing. The only > reason NOT to > take this document to draft will be its normative reference > to -protocol-. > > > Chris and I did not agree that RAW mode should be obsoleted and > > replaced with a new mode. That is new work that is NOT in > the current > > charter, and is not in the proposal to Sam for a minor change to the > > charter. That is simply out of scope for the current WG. > > Rainer has spoken on this point, but I'll add that the change of the > length limitation necessitates on its own a new profile, lest new > implementations start sending messages larger than can be handled by > those implementing the old profile. That in itself is a > security concern. > > > > > > To my knowledge, there has been no discussion of such a change, and > > there is no current WG consensus to do this, even if it > were in scope. > > As co-chair, I would not take such a proposal to Sam because we have > > work that is not yet completed, and that needs to be > completed before > > we start working on new proposals. > > > > You have misunderstood the nature of the change, Dave. Your > choices are > these: > > * Either allow for a new profile; or > * Do not take on the work in this group to update RFC 3195. > > Anything else is dangerous, and the addition of a new profile > is not a > substantial piece of work. Indeed in the author drafty > draft, the new > profile is cut and paste from the old RAW profile, and small > numbers of > words are changed. > > If there is WG consensus to obsolete both RAW and COOKED modes, then > > we can simply obsolete RFC3195 and move forward with > sylog-sign. A new > > proposal for a TARTARE mode can be proposed as a new > transport mapping > > in the future, under a different charter or as an individual draft. > > > > I believe the authors are perfectly happy to see this work go forward > individually or within this group. Whichever you prefer. > The changes > envisioned are not dramatic. > > > Security considerations in RFC3195 would obviously need to > be reviewed > > and possibly rewritten in light of the use of -protocol- rather than > > RFC3164. That does NOT open the door to redesigning RFC3195 in any > > substantial manner to address algorithm agility. We may need to do > > this, but that has not yet been discussed on the list, with the > > chairs, or with the AD. Currently, I would consider that > out of scope, > > while recognizing that we may need to make modifications > before it can > > be submitted for standardization. > > > > The existing standard lists 3DES a SHOULD for TLS. Clearly > that is no > longer appropriate. Russ Housley (the other Security AD) has made it > clear that further work on encrypted transport MUST take algorithm > agility into account. The authors are attempting to honor > his explicit > wishes. One presumes these same agility issues will be a matter for > discussion for -signed-. > > Please note that there are other algorithm choices within the > document > that will need to be reviewed, and in particular, use of the > MD5-DIGEST > SASL profile. This co-author at this time saw no need to > change what is > listed, but I could be persuaded by knowledgeable security folk. > > In summary, the authors believe that the changes we are proposing, > modulo those Rainer has asked for, are a minimum set of > changes anyone > would have to make to update 3195, regardless of what it says in > anyone's charter. > > Eliot > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
