RE: [Syslog] Charter comments from IESG Review
Hi Sam & WG, I understand the reasoning behind requiring a security mechanism. I just want to remind everyone that a major drawback in Vancouver was that we had lost some backwards-compatibility to existing syslog implementations. The weeks after Vancouver we worked hard to find a minimum consensus on how we could provide the needed backwards compatibility. When we mandate a security mechanism, we must be very careful not to invalidate all these attempts. Why? Simply because any transport-layer requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with currently existing syslog implementations. So due to this requirement, we can not create a backwards-compatible spec (not even in the sense that existing receivers can put messages in the right bins). So in my point of view the only option is to use structured-data embedded signatures. As they do not modify the message format AND work over UDP, they allow old receivers to receive messages and put them into the right bins while new receivers can enjoy their benefits. In my point of view, anything further (like required confidentiality) conflicts with the backwards-compatibility approach and thus with the rest of the new charter. So I propose we update the charter to include that item and make sure syslog-sign advances. Syslog-protocol can than require all messages to be signed via syslog-sign. Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman > Sent: Thursday, January 05, 2006 11:12 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Charter comments from IESG Review > > > > Hi. The IESg reviewed the proposed syslog charter at today's telechat > and decided that it requires revision. The main concern seems to be > the lack of a mandatory to implement security mechanism. I indicated > this might be the case in the Vancouver meeting. > > so, you definitely need to have some sort of mandatory to implement > security mechanism. I'm not quite sure what needs to be said about > this in the charter. > But the working group will need to: > > 1) Identify a threat model for syslog > > > 2) Define mechanisms to address these threats. > > So, questions for the threat model include things like whether > confidentiality is important or whether integrity of mesages is > sufficient. > > Depending on the threat model here are some possible solutions: > > 1) Require some transport like syslog over TLS|DTLS be implemented. > > 2) Require that all senders implement signatures stored in structured > data as an option. > > I don't think you need to commit to one of these options now. > However, you do need to reflect the security issues in the charter. > > --Sam > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Chris, > > 1) Require some transport like syslog over TLS|DTLS be implemented. > > RFC 3195 requires the use of RFC 3080 which requires TLS. small glitch: RFC 3080 provides support for a TLS profile, but it does not mandate it. Most existing RFC 3195 implementations do NOT support the TLS tuning profile. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Tom, > > If so, yes, both S/MIME and OpenPGP support this model. > However I'll > > point oun that it is not a requirement that syslog work > that way; for > > example RFC 3195 certainly has connections. > > > I'll look at those, thanks. I agree syslog could be, perhaps > should be for > meaningful security, but often at present is not, so I wanted > to see what > security was > possible with just one way communication They use pre-shared secrets. It's probably best if you look at syslog-sign, which provides the necessary mechanisms for syslog. Please note that it still transmits data in clear-text (which I consider a requirement to remain backwards-compatible). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: Rainer> Hi Sam & WG, I understand the reasoning behind requiring a Rainer> security mechanism. I just want to remind everyone that a Rainer> major drawback in Vancouver was that we had lost some Rainer> backwards-compatibility to existing syslog Rainer> implementations. Rainer> The weeks after Vancouver we worked hard to find a minimum Rainer> consensus on how we could provide the needed backwards Rainer> compatibility. Rainer> When we mandate a security mechanism, we must be very Rainer> careful not to invalidate all these attempts. Agreed. Rainer> Why? Simply Rainer> because any transport-layer requirement (DTSL, SSL, SSH, Rainer> whatever) would NOT be compatible with currently existing Rainer> syslog implementations. So due to this requirement, we can Rainer> not create a backwards-compatible spec (not even in the Rainer> sense that existing receivers can put messages in the Rainer> right bins). Let's be clear about what backward compatibility we're looking for. Do we require that new senders be able to be configured to talk to old receivers? Or do we require that old receivers be able to put any message from a new sender into the right place? In particular what you're seeming to say implies that we cannot define new transports because doing so would be backward incompatible. I don't think that is what we said. If we do define a new transport, presumably both UDP and the secure transport would be mandatory to implement. Rainer> So in my point of view the only option is to Rainer> use structured-data embedded signatures. As they do not Rainer> modify the message format AND work over UDP, they allow Rainer> old receivers to receive messages and put them into the Rainer> right bins while new receivers can enjoy their benefits. This is a valid approach. This means delaying protocol until syslog-sign is ready. Note that Russ, Bill Fenner and I have serious questions about syslog-sign because it does not reuse CMS, OpenPGP or some other format. We would need these questions answered before it could go forward in its current form. You would also need to make syslog-sign mandatory to implement and would need to believe that people wern't going to just ignore that. Rainer> In my point of view, anything further (like required Rainer> confidentiality) conflicts with the Rainer> backwards-compatibility approach and thus with the rest of Rainer> the new charter. I'm going to ask you to do the analysis in terms of what is required from a security standpoint. If that analysis ends up being incompatible with backward compatibility requirements, then we'll have to evaluate tradeoffs. However if there is a solution compatible both ith security and backward compatibility, that's better. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: Rainer> Tom, >> > If so, yes, both S/MIME and OpenPGP support this model. >> However I'll > point oun that it is not a requirement that >> syslog work that way; for > example RFC 3195 certainly has >> connections. >> > >> I'll look at those, thanks. I agree syslog could be, perhaps >> should be for meaningful security, but often at present is not, >> so I wanted to see what security was possible with just one way >> communication Rainer> They use pre-shared secrets. Not typically. They typically use public keys. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
> -Original Message- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: Monday, January 09, 2006 1:08 PM > To: Rainer Gerhards > Cc: Tom Petch; [EMAIL PROTECTED] > Subject: Re: [Syslog] Charter comments from IESG Review > > > "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: > > Rainer> Tom, > >> > If so, yes, both S/MIME and OpenPGP support this model. > >> However I'll > point oun that it is not a requirement that > >> syslog work that way; for > example RFC 3195 certainly has > >> connections. > >> > > >> I'll look at those, thanks. I agree syslog could be, perhaps > >> should be for meaningful security, but often at present is not, > >> so I wanted to see what security was possible with just one way > >> communication > > Rainer> They use pre-shared secrets. > > Not typically. > They typically use public keys. > Sorry, yes, I was totally wrong in my wording. What I intended to say was that the keys are exchanged on a medium different then the current session (e.g. key servers). So this means some other protocol is required to obtain that information (and it is processed "outside" of the syslog protocol). Thus, I wanted to say, it does not necessarily need to change the simplex nature of syslog (but some initial negotiation is necessary, which I do not think to be a problem). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: Rainer> Sorry, yes, I was totally wrong in my wording. What I Rainer> intended to say was that the keys are exchanged on a Rainer> medium different then the current session (e.g. key Rainer> servers). This is not typically how things work for S/MIME. In S/MIME I will typically inclue a certificate (which includes my public key) in-band with some signature data. If I was generating a lot of signatures I might only sometimes include my certificate to save on space and bandwith. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Sam, > Rainer> Why? Simply > Rainer> because any transport-layer requirement (DTSL, SSL, SSH, > Rainer> whatever) would NOT be compatible with currently existing > Rainer> syslog implementations. So due to this requirement, we can > Rainer> not create a backwards-compatible spec (not even in the > Rainer> sense that existing receivers can put messages in the > Rainer> right bins). > > Let's be clear about what backward compatibility we're looking for. > Do we require that new senders be able to be configured to talk to old > receivers? I depens on what you mean with that - if "to be configured to talk to old receivers" means they must not use -protocol but rfc 3164 instead, this is not what was discussed on this list (-protocol-14 had addressed this already). > Or do we require that old receivers be able to put any > message from a new sender into the right place? Not over any transport, but the core need behind the recent changes was that -protocol/-transport-udp messages should allow an old sender to put it into the right bin. This implies plain text transmission. > > In particular what you're seeming to say implies that we cannot define > new transports because doing so would be backward incompatible. I > don't think that is what we said. > > If we do define a new transport, presumably both UDP and the secure > transport would be mandatory to implement. This looks like I misunderstood your intension. I thought that unsecured UDP should no longer be supported. So what you actually said is that we can go ahead with the unsecured UDP as long as we also mandate a (different) secure transport. If that is the case, I am reliefed, because this is something that can practically be done. And, yes, configuring a sender to use unsecured udp (-transport-udp) for one target and a secured transport for another target is definitely a good option. We just need to be able to interoperate with the "unsecured plain text udp syslog world". Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: Rainer> This looks like I misunderstood your intension. I thought Rainer> that unsecured UDP should no longer be supported. That was not my intent. Rainer> So what Rainer> you actually said is that we can go ahead with the Rainer> unsecured UDP as long as we also mandate a (different) Rainer> secure transport. What I said is that you need to have a mandatory-to-implement mode of operation that meets your security goals. You can certainly support transport-udp. One way to do this is to have a new secure transport. Another way to do this (assuming you decide confidentiality need not be a security goal) is to use something like syslog-sign. Personally I think a new transport might be more important than syslog-sign but so long as the WG clearly articulates its security goals, those goals make sense, and the wg then meets the goals, the preference between syslog-sign and transport is a WG matter. Also, I agree that you have described the threats to syslog in adequate detail already; the question is which threats do you want toaddress. You do need to explain that in your documents and you need to justify that decision. So, how much needs to be done for the charter? Well, I'd like text added to the deliverable for -protocol noting that it will require a secure mode of operation. If you are going to decide that syslog-sign is the right path, then you should add text about that to the charter. I don't think you need to choose a transport before chartering, although I caution that transport wars are a good way to lose WG momentum; look at the ISMS work over the past few IETFs for an example. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Sec 6.1: Truncation
> Rainer: > > I agree - this is better than a convoluted rule. > > I think we only have any business in defining truncation for > relays. For collectors, we have tried to stay away from > describing how messages are stored. > > For relays, I think it would be useful to state that relay > can't just drop arbitrary message parts. Your statements > about "some parts ... are lost" may be interpreted that way. Actually, this was what I meant ;) [I saw a number of use cases where it would make sense to strip some known-not-so-relavant SD-IDs to be strippedd], but ... > > I would recommend that we state that any truncation must > happen at the end of the message, which I think is what > truncation means to a lot of people anyway. This would > prevent an implementation which prefers to throw out > STRUCTURED-DATA before the MSG content. A consistent > behavior is useful for interop and, in particular, may help > in dealing with security issues. ^^^ ... this is more important. I now agree with your point. As a side-note, we had the idea that relay operations may become a separate document, so I would prefer not to dig too deep into relay behaviour. To specify what you recommend, this is not necessary, so this is not really a discussion topic here. Rainer > > Thanks, > Anton. > > > -Original Message- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 09, 2006 3:21 AM > > To: Anton Okmianski (aokmians) > > Subject: RE: [Syslog] Sec 6.1: Truncation > > > > Anton, Darren, > > > > I agree that the truncation rule is probably not really > > useful, even confusing. I think it is hard to predict for any > > potential message if the more interesting content is in > > STRUCTURED-DATA or in the MSG part. > > For example, with our current SD-IDs, I'd prefer to trunctate > > them instead of MSG. Obviously, the case is different for > > your LINKDOWN sample. I also agree with Darren that > > truncation probably happens on the transport layer, the > > application may not even see the full message. > > > > My conclusion, however, is slightly different: I recommend > > now that we remove truncation rules from -protocol. We should > > just say that truncation might happen and that in this case > > some parts of the message are lost - what is at the > > discretion of the receiver. > > > > Rainer > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Anton > Okmianski > > > (aokmians) > > > Sent: Friday, January 06, 2006 9:48 PM > > > To: [EMAIL PROTECTED] > > > Subject: [Syslog] Sec 6.1: Truncation > > > > > > Rainer and all: > > > > > > I started reading draft #16. Since we are revisiting > > everything... I > > > am not very comfortable with the current truncation rules. > > > > > > "Receivers SHOULD follow this order of preference when it > comes to > > > truncation: > > > > > > 1) No truncation > > > 2) Truncation by dropping SD-ELEMENTs > > > 3) If 2) not sufficient, truncate MSG" > > > > > > I don't think that this is a good recommendation. I would > > assume that > > > in many cases people would try to tokenize more important > data into > > > structured data and use message text as a secondary user-friendly > > > description. For example, for LINK_DOWN message, I would probably > > > encode link ID in the structured elements as this is > something that > > > should be readily available for receivers. The MSGID could be > > > "LINK_DOWN" and the MSG text may simply be "Link down". If you > > > truncate the structured data, it makes it harder. > > > > > > I also think, in general it is useful to put more important data > > > first, which is another reason for putting more valuable > data into > > > structured data in a more compact way. > > > > > > Additionally, structured data can be used to provide > > message length or > > > digest, which can help receiver to determine if message was > > truncated. > > > > > > Also, I think this statement is very convoluted: > > > > > > "Please note that it is possible that the MSG field is truncated > > > without dropping any SD-PARAMS. This is the case if a > > message with an > > > empty STRUCTURED-DATA field must be truncated." > > > > > > I think I understand what you are driving at, but I don't > see it as > > > adding any requirements or clarification. > > > > > > This sentence is not clear although I know what you are > > trying to say: > > > > > > "The limits below are minimum maximum lengths, not > maximum length." > > > > > > I propose replacing the entire section 6.1 with this text: > > > > > > "Syslog message limits are dictated by the syslog transport > > mapping in > > > use. Each transport mapping MUST define the minimum > > required message > > > length support. Any syslog transport mapping MUST support > > messages of > > > up to and including 480 octets in
RE: [Syslog] Sec 6.1: Truncation
Rainer: I agree - this is better than a convoluted rule. I think we only have any business in defining truncation for relays. For collectors, we have tried to stay away from describing how messages are stored. For relays, I think it would be useful to state that relay can't just drop arbitrary message parts. Your statements about "some parts ... are lost" may be interpreted that way. I would recommend that we state that any truncation must happen at the end of the message, which I think is what truncation means to a lot of people anyway. This would prevent an implementation which prefers to throw out STRUCTURED-DATA before the MSG content. A consistent behavior is useful for interop and, in particular, may help in dealing with security issues. Thanks, Anton. > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, January 09, 2006 3:21 AM > To: Anton Okmianski (aokmians) > Subject: RE: [Syslog] Sec 6.1: Truncation > > Anton, Darren, > > I agree that the truncation rule is probably not really > useful, even confusing. I think it is hard to predict for any > potential message if the more interesting content is in > STRUCTURED-DATA or in the MSG part. > For example, with our current SD-IDs, I'd prefer to trunctate > them instead of MSG. Obviously, the case is different for > your LINKDOWN sample. I also agree with Darren that > truncation probably happens on the transport layer, the > application may not even see the full message. > > My conclusion, however, is slightly different: I recommend > now that we remove truncation rules from -protocol. We should > just say that truncation might happen and that in this case > some parts of the message are lost - what is at the > discretion of the receiver. > > Rainer > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski > > (aokmians) > > Sent: Friday, January 06, 2006 9:48 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Sec 6.1: Truncation > > > > Rainer and all: > > > > I started reading draft #16. Since we are revisiting > everything... I > > am not very comfortable with the current truncation rules. > > > > "Receivers SHOULD follow this order of preference when it comes to > > truncation: > > > > 1) No truncation > > 2) Truncation by dropping SD-ELEMENTs > > 3) If 2) not sufficient, truncate MSG" > > > > I don't think that this is a good recommendation. I would > assume that > > in many cases people would try to tokenize more important data into > > structured data and use message text as a secondary user-friendly > > description. For example, for LINK_DOWN message, I would probably > > encode link ID in the structured elements as this is something that > > should be readily available for receivers. The MSGID could be > > "LINK_DOWN" and the MSG text may simply be "Link down". If you > > truncate the structured data, it makes it harder. > > > > I also think, in general it is useful to put more important data > > first, which is another reason for putting more valuable data into > > structured data in a more compact way. > > > > Additionally, structured data can be used to provide > message length or > > digest, which can help receiver to determine if message was > truncated. > > > > Also, I think this statement is very convoluted: > > > > "Please note that it is possible that the MSG field is truncated > > without dropping any SD-PARAMS. This is the case if a > message with an > > empty STRUCTURED-DATA field must be truncated." > > > > I think I understand what you are driving at, but I don't see it as > > adding any requirements or clarification. > > > > This sentence is not clear although I know what you are > trying to say: > > > > "The limits below are minimum maximum lengths, not maximum length." > > > > I propose replacing the entire section 6.1 with this text: > > > > "Syslog message limits are dictated by the syslog transport > mapping in > > use. Each transport mapping MUST define the minimum > required message > > length support. Any syslog transport mapping MUST support > messages of > > up to and including 480 octets in length. > > > > Any syslog receiver MUST be able to accept messages of up to and > > including 480 octets in length. All receiver > implementations SHOULD > > be able to accept messages of up to and including 2048 octets in > > length. Receivers MAY receive messages larger than 2048 octets in > > length. If a receiver receives a message with a length > larger than it > > supports, the receiver MAY discard the message or truncate the > > payload. > > > > If truncation is performed by the receiver, it MUST first > truncate the > > MSG field as necessary to meet the supported length limit. If > > truncation of the entire MSG field is not sufficient, then > > additionally, the STRUCTURED-DATA field MUST be truncated > by removing >
Re: [Syslog] Charter comments from IESG Review
Sam I was about to say that we were getting into useful detail but that we could sort out the charter without it, but you seem to saying not. That is, I was hoping that where the charter says The goal of this working group is to address the security and integrity problems it might say The goal of this working group is to identify the security problems, perform a threat analysis and document a solution to the perceived threats, without committing us to either a -sign or a secure transport approach (and yes, we did start the transport wars, some time ago, with SSH v TLS:-( Tom Petch - Original Message - From: "Sam Hartman" <[EMAIL PROTECTED]> To: "Rainer Gerhards" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, January 09, 2006 2:35 PM Subject: Re: [Syslog] Charter comments from IESG Review > > "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes: > > Rainer> This looks like I misunderstood your intension. I thought > Rainer> that unsecured UDP should no longer be supported. > > That was not my intent. > > Rainer> So what > Rainer> you actually said is that we can go ahead with the > Rainer> unsecured UDP as long as we also mandate a (different) > Rainer> secure transport. > > > What I said is that you need to have a mandatory-to-implement mode of > operation that meets your security goals. You can certainly support > transport-udp. One way to do this is to have a new secure transport. > Another way to do this (assuming you decide confidentiality need not > be a security goal) is to use something like syslog-sign. > > Personally I think a new transport might be more important than > syslog-sign but so long as the WG clearly articulates its security > goals, those goals make sense, and the wg then meets the goals, the > preference between syslog-sign and transport is a WG matter. > > > > Also, I agree that you have described the threats to syslog in > adequate detail already; the question is which threats do you want > toaddress. You do need to explain that in your documents and you need > to justify that decision. > > So, how much needs to be done for the charter? Well, I'd like text > added to the deliverable for -protocol noting that it will require a > secure mode of operation. If you are going to decide that syslog-sign > is the right path, then you should add text about that to the charter. > I don't think you need to choose a transport before chartering, > although I caution that transport wars are a good way to lose WG > momentum; look at the ISMS work over the past few IETFs for an > example. > > --Sam > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes: Tom> without committing us to either a -sign or a secure transport Tom> approach (and yes, we did start the transport wars, some time Tom> ago, with SSH v TLS:-( I really think that you need to identify your deliverables in the charter. Either sign is or is not a critical path deliverable. (Similarly, if you go the transport route, you need a critical path deliverable of a secure transport.) --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
