Hi.
Participants who attend the meetings are expected to also join the
list. It is the consensus on the list that should be driving the
working group, not what decisions are being made in meetings.
--Sam
___
Syslog mailing list
Greetings. I'd like to draw yo;ur attention to section 4 of RFC 2418.
This section requires area directors to consult with a working group
prior to concluding that working group. At the meeting in Vancouver I
started such a consultation by noting that once the next set of
milestones is
Hi. Last week had the largest telechat schedule since I've joined the
IESG. I was fairly busy working on document review. Now I'm working
on a long document I need to get done by Wednesday. I hope to finish
early--possibly by lunch today.
Reviewing the syslog charter proposal will be high
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
Chris == Chris Lonvick [EMAIL PROTECTED] writes:
Chris Is Section 8 in draft-ietf-syslog-protocol-16.txt
Chris sufficient? Alternatively, Section 6 in RFC 3164 is fairly
Chris comprehensive.
Both of these look good. My main question with them is whether you
believe it is a
Tom == Tom Petch [EMAIL PROTECTED] writes:
Tom Sam I struggle to think what a security system would look
Tom like when the protocol is purely simplex, apart from a MAC to
Tom give integrity with some shared secret transmitted totally
Tom out of band.
By this do you mean without
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
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
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
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
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.
Hi.
Can you explain what actions on a part of an attacker are prevented in
terms of attacks on message integrity without authenticating the
source of the message?
In general, the security community is very suspicious of mechanisms
that provide integrity without authentication. If you are going
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
I'm concerned that your analysis seems to be based on what is
easy to implement.
Rainer Well, I have to admit that in the world of syslog people
Rainer vote with their feet. If it is not easy to implement
Rainer (better
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
Rainer I now understand. But wouldn't it then make sense to
Rainer create a separate document for it? I have the feeling that
Rainer would focus us better than when the discussion is split
Rainer among different
May I recommend TLS PSK or TLS in anonymous DH mode in preference to
inventing your own transport that does not use PKI?
Also, before doing something based on shared secrets carefully
consider the requirements of RFC 4107.
___
Syslog mailing list
Hi. I'm pleased to report that your charter has been approved. It
will take a few days for official word to come out but you can move forward
under this charter.
--Sam
___
Syslog mailing list
Syslog@lists.ietf.org
I'll get back to you on the generic certificates issue. For now, I
recommend you read RFC 4107. Also note that each device needs a
unique MAC address so the manufacturing process tends to have a step
for making a device unique.
So, it sounds like all forms of authentication are optional in
I failed to write this up yesterday.
Your protocol document uses ISO language identifiers rather than BCP
47. Please either use BCP 47 or explain for all the language sets
that BCP 47 can identify but your choice cannot why syslog
implementations will not care.
Mark == Mark Andrews [EMAIL PROTECTED] writes:
- 'The syslog Protocol ' draft-ietf-syslog-protocol-19.txt as
a Proposed Standard
Mark draft-ietf-syslog-protocol-19.txt recommends using a
Mark reliable protocol. Existing implementations of syslog do
Mark this and
As I said before if you are not going to use BCP 47, you need to
clearly explain for each class of languages BCP 47 supports and your
application does not support why it is OK to be unable to label those
applications.
___
Syslog mailing list
Miao == Miao Fuyou [EMAIL PROTECTED] writes:
Miao Section 2 identifies masquerade as a major security threat
Miao for syslog. In the draft, client authentication and server
Miao authentication are SHOULDs(server authenticaiton may be not
Miao spelled out explicitly). After
Moehrke, == Moehrke, John (GE Healthcare) [EMAIL PROTECTED] writes:
Moehrke, I would recommend against constraining the key
Moehrke, management in -tls-. This is a POLICY decision, not a
Moehrke, protocol decision. (as highlighted by RFC4107)
I'm not sure I disagree with your
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes:
I wonder why an operator would choose to use a TLS transport
without authentication, rather than simply using a non-secure
transport.
Rainer To prevent casual observation. In my experience, this is
Rainer the primary
What part of 4646 allows non-ASCII characters? How is encoding an
issue?
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
The description of non-ascii characters in the registry refers to
non-ascii characters in the description field, etc. The subtags are
ascii.
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
So, I shouldn't have asked my question and tom shouldn't have replied:
the answer is in the charter.
The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by
I recommend that you drop message stream modification if my analysis
[At this point, we're still figuring out what we want to say.
I'm speaking as an individual not an AD.]
of the charter is a correct analysis and we meant for that to apply to
syslog-sign.
I recommend you split out peer entity
It sounds like trust anchor selection (what security people talk about
when the rest of the world talks about set of root CAs) is actually
very important to you. It's just that you don't actually consider the
traditional root CAs part of your trust anchor set; you have a much
smaller trust anchor
Eliot == Eliot Lear [EMAIL PROTECTED] writes:
Eliot And that leads to my other question. Why are we
Eliot implementing a separate TLS protocol when 3195 and its
Eliot successor both exists and has been implemented? That seems
Eliot to me rather redundant, and violates a tenant
Hi. Thanks for the new draft.
There are a lot of changes in this version; it will definitely require
a new ietf last call. I'd recommend that the WG evaluate the changes
and ask whether at this stage in the process they are actually
required. Perhaps they are.
1) You cannot use originator
Hi, folks.
I think the WG made a mistake trying to address Chris Newman's comment
about Unicode TR36 and made the situation worse.
My understanding of what the WG was trying to do is to require that if
a BOM is present in a string, then the implementation can enforce
strict checks because it
Greetings. Other than the issue I pointed out today, it looks like
we're done with protocol and transport-udp. Once that issue is
resolved I can approve both of these documents and send them to the
rfc-editor.
However, in your discussions with the transport area directors you
made some
If the WG is OK with my proposed text, I'll handle it in an rfc editor note
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
33 matches
Mail list logo
