Re: [Syslog] Document shepherd report of AD concerns

["tom.petch" <[e-mail]>]

Thanks for that, it does allay my concerns (back in November, I got the
impression we were being discouraged from making suggestions and one of my
suggestions, close to the last post on -11, was for self-signed certs with
finger prints:-)

I would go for self-signed cert with finger prints as the minimum acceptable,
with full PKI and leap of faith as the others to mention, essentially as drafted
in -12.

But I do think that -12 gives the wrong impression, that the full
weight of PKI, or self-generating certificates, must be born by whoever is
writing the syslog daemon:-)  That I think is wrong.  Rather, if the box has
PKI, well and good, use it, it will be there for other applications too.  And,
as David has suggested, the box will most likely be initially configured by a
standalone laptop and that will be the one doing the generating, or provision of
the trust anchors, again not just for syslog.

For me, this new material belongs in 5 not 4.  I think 4 as it was in -11 lays
down what an implementor of syslog should do, and that the additional material
belongs in 5, as policy, important to consider but the concern of another (part
of the) organisation.

<rant>
Fundamentally, someone else should be doing this, a policies in security working
group, perhaps a spinoff from pkix or tls (which I know ekr will reject out of
hand:-).  We are the wrong people, IMO, to be proposing resolutions to such
questions; it should be being done for us by those whose primary role is
security, not network management.
</rant>

Finally, Rainer, as ever, is doing a grand job of keeping our feet on the
ground, what is realistic, but, at the time of rchartering, there were three
others who said they would implement this.  I would love to hear their thoughts
on these very implementation-oriented issues.

Tom Petch

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Thursday, May 15, 2008 9:35 PM
Subject: Re: [Syslog] Document shepherd report of AD concerns


> To add to David's email, and Tom's concern that "[we] should only
> change what the IESG wants us to to; and that I do not see":
>
> All the changes in version -12 were done in response to my (and
> earlier Sam's) AD review comments. However, based on the recent
> discussions, it's clear that the text isn't final yet, and needs
> some improvement.
>
> The intent of 4.2.1/4.2.2 was to specify a minimum level needed for
> interoperability, not to prevent deployments for making their own
> policy decisions. That minimum level can be pretty small -- and
> there's some room for discussing what exactly it should be -- but it
> must provide reasonable security for many typical syslog uses (and in
> this particular case, having a full-fledged PKI as the only approach
> isn't really a credible solution).
>
> Perhaps we could rephrase the text to make this more clear, and
> also explain the motivation for these requirements.  Here's a first
> shot at that text -- feedback is welcome.
>
>    To prevent disclosure of syslog message contents, the transport
>    sender (TLS client) has to verify that it is sending the messages
>    to an authorized transport receiver (TLS server).
>
>    Typically, a client application using TLS achieves this by
>    performing certification path validation (using previously
>    configured trust anchors), and comparing the certificate subject
>    name against the expected server name (or a list of authorized
>    server names).
>
>    Syslog transport senders MUST support this approach. The minimum
>    requirements for certification path validation and subject name
>    comparison are specified later in this section.
>
>    However, syslog is frequently used in environments where assuming
>    PKI deployment is not realistic. Thus, an alternative that provides
>    a reasonable level of security, while being simple to deploy, is
>    desired. This document requires that syslog transport senders MUST
>    support a mechanism where the authorized transport receivers are
>    identified by certificate fingerprints. The minimum requirements
>    for this mechanism are specified in Section 4.2.3.
>
>    However, these requirements are intended to specify only a minimum
>    level of compliance required for interoperability.  Implementations
>    MAY support additional mechanisms for expressing more complex
>    policies, validating certificates, and determining whether a
>    certificate represents an authorized transport receiver.
>
>    There can be extreme situations where it is not feasible to verify
>    that the transport sender is communicating with an authorized
>    transport receiver. A syslog implementation MAY provide an option
>    to skip this verification (i.e., accept any server certificate).
>    This option MUST NOT be enabled by default.
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: David Harrington
> > Sent: 15 May, 2008 21:02
> > To: [e-mail]
> > Subject: [Syslog] Document shepherd report of AD concerns
>

_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog