Subject: [Syslog] RFC3195bis

From: "David Harrington" <[email-masked]>
Date: Fri, 26 Jan 2007 10:15:20 -0500

Hi,

[speaking as co-chair]

It appears to me that somehow we got out of sync. I want to make sure
we are all in sync, so let me review where we are and where the chairs
think this WG needs to go to get our ***chartered*** work done.

Chris and I discussed the syslog-sign WGLC, and the need to update
RFC3195 last week. The driving factor has been the syslog-sign WGLC.
It is difficult to complete syslog-sign because it has dependencies on
RFC3195. RRC3195 was written before the WG completed much of its
current work, and there have been numerous WG consensus points reached
since RFC3195 was published. 

Chris and I reached some agreement about what we felt was WG consensus
on some of the issues, and we discussed with Sam (via email) what we
believe is a necessary change to our charter - to bring RFC3195 into
compliance with the WG consensus points achieved since its
publication, before completing the work on syslog-sign. 

Our charter currently includes the completion of syslog-sign, and does
not include RFC3195bis, so updating RFC3195 first might require a
change to the charter. So we asked Sam if we could add RFC3195bis to
our charter to complete it before completing syslog-sign. Sam told us
he would be OK with such a change, and that we should draft a charter
change, but to feel free to start the work in the meantime.

Let me be very clear - we do not have the AD official approval of the
charter change yet, just a verbal approaval of our intent. Making such
a change to the charter might be able to be done without discussion
with the WG, but I would like the WG involved in the decision to make
such a change.

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.
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. 
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.

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. 

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.

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.

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.

And do not misinterpret "do people desire any other changes" because
we are not accepting new proposals. We are trying to complete the work
on our plate.

Hopefully, this helps clarify the proposed WG work plans.

As part of having the change made to the charter, Chris and I have
also discussed updating the WG deadlines, since we missed our November
deadlines for -sign- and -mib-. We plan to post a new schedule soon.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
Co-chair, syslog WG

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 26 Jan 2007 16:57:21 +0100

David,

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 4:15 PM
> To: [email-masked]
> Subject: [Syslog] RFC3195bis

[.. big snip ..]
 
> in the future, under a different charter or as an individual draft.

I agree that COOKED should be obsoleted. Reasons are in my other mail
from earlier today.

Even though I did not consider it before, obsoleting RAW also seems
right to me. The reason is that this greatly simplifies interoperability
between new (to be written) and existing applications. If we define a
TARTARE mode, the BEEP greeting precisely tells sender and receiver what
to expect. Keep in mind that RAW and TARTARE (or RAWbis) are
incompatible to each other. This stems back to the fact that 3195
demands printable characters only as well as LF as a record delimiter.
This does not work with a -protocol formatted message. The appropriate
BEEP solution to that problem is to define a new profile. So creating
"TARTARE" is the right thing to do. Everything else would be a bad
compromise.

I see your concerns in regard to the charter. I also understand John's
concern. I like you proposal to simply obsolete 3195, then complete
-sign and then work on a new version of 3195. There is no need to hurry
in getting that done. Very few implementations are using it today and
they continue to work (at least if somebody finally deploys them ;)).
There is also no need to have a BEEP transport mapping ready in order to
get -sign published. The whole point of the discussion was that -sign
should be transport-independent. If it is independent, anything we
specify now can also work with a later TARTARE BEEP transport. So there
is no actual relationship. One might now argue that so -sign messages
can not be used with 3195. This is right. But this is right in any case.
Existing 3195 transports will never work with -sign.

My conclusion: simply obsolete 3195, remove references to it from -sign
and let's finish -sign quickly. Then recharter.

Rainer

[.. big snip ..]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Jan 2007 15:34:35 +0100

> Hi,

Hi.

> 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.
> mapping independent of protocol processing. 
As RAW and what we have dubbed TARTARE are just that - raw, this should 
be no great difficulty.
> proposed to Sam as the change to our charter (I wasn't as wordy in the

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-.

> 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.
> 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.
> 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.

> 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

---

From: "David Harrington" <[email-masked]>
Date: Sat, 27 Jan 2007 10:15:09 -0500

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-masked] 
[email-masked]
[email-masked]

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Saturday, January 27, 2007 9:35 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Syslog] RFC3195bis
> 
> 
> > Hi,
> >   
> 
> Hi.
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Jan 2007 16:21:13 +0100

> their impact, and decide whether to accept the draft as a WG item at

Our pleasure.  Look for one this week.

Eliot