Hi,

Let me remind the WG that this document is in IESG review.

We are no longer doing fine-tuning/wordsmithing. We are fixing the
problems raised by the IESG. So unless the wording is **broken** we
shouldn't be trying to fix it now.

What IESG-raised issues are we responding to?

dbh

> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial...]
> Sent: Wednesday, November 28, 2007 12:13 PM
> To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf...
> Subject: Re: [Syslog] transport-tls-11 review
>
> <snip>
> > >
> > > ===
> > > The server MUST be implemented to support certificate and
> certificate
> > >    generation,
> > > ===
> > >
> > > I do not think it is a MUST that a server must contain code
> > > to generate certificates. This should be left to the
> > > implementation. There is already the requirement to use
> > > certificates, so IMHO it is not the business of an IETF
> > > document to specify how they are provided. For example, I
> > > would provide a helper app with my syslog implementations,
> > > but not include it in the core app - it doesn't belong there.
> > >
> >
> > Need more opinion from the working group.
> >
>
> I agree with Rainer
>
> And I see some idiosynchratic wordings that MIGHT be changed.
>
> 2.  Security Requirements for Syslog
>
>    syslog messages may pass several hops
> ** not really pass, suggest transit
>
>    It is recommended to use dNSName in the certificate rather than
any
>    other type subjectAltName for certificate verification, such as
>    ipAddress.
> **suggest iPAddress (ie PKI not SNMP)
>
> 4.2.2.  Client Identity
>
>    If a server authenticates a client and the client presents a
>    certificate to the server, the server MUST validate the
> certificate.
>    Validation includes constructing a certificate path to one of the
>    configured trust anchors and validating that path.  
> However, identity
>    check is not required even if subjectAltName is presented in the
>    certificate.
> **I do not understand how failing to check the identity
> provides protection
> against Masquerade, as we claim in s.2
>
>    SubjectAltName is not necessarily unique for different
>    certificates.
> ** suggest The subjectAltName
>
> 5.1.  Authentication and Certificates
>
>   Mutual authentication means the TLS client and server are
>    provisioned with necessary trust roots
>
> **suggest trust anchors as in the next paragraph
>
> .  If a server does not
>    have a certificate and key/pair configured
> **unclear what the solidus is doing - '/' usually means either/or
>
>    The server MUST be implemented to support certificate and
> certificate
>    generation, and certificate validation MUST be implemented for
all
>    clients.  The Syslog client SHOULD be implementated to support
> **implemented
>    certificate and certificate generation, and certificate
validation
>    SHOULD be inplemented for Syslog server.
>
> **These both read oddly to me - what is the support for certificate
> (certificates?) as distinct from support for certificate
> generation and
> certificate validation?  If I support certificate (without
> qualification), then
> I expect that to convey support for every aspect thereof so
> the validation and
> generation is redundant but, as I agreed with Rainer above, I
> think that
> generation should not be a MUST.
>
>   Since a receiver may act upon received data, for syslog over
>    TLS, it is recommended that the server authenticate the client to
>    ensure that information received is authentic.
>
> **this seems to weaken the claim earlier that TLS defends
> against the listed
> threats - by now  I am feeling confused about what protection
> is being offered
> by what.  To meet the claims of s.2, I think we need both
> server and client to
> check certificates for suitable identities and to follow a
> chain to a trust
> anchor - I have no problem with describing other scenarios
> but think that each
> such scenario should then be qualified with a comment to the
> effect that this
> MAY not defend against threats ... as identified in s.2
>
> 5.2.  Cipher Suites
>
>      Operators MAY choose to disable older/weaker cipher
> suites for TLS
>    despite the tradeoff of interoperability, for example, if
> the cipher
>    suite specified in the specification is found weak in the future.
>
> **suggest
>
>     Operators MAY choose to disable cipher suites for TLS
> that are regarded as
> too weak for the environment in which this specification is
> being used,
> especially older cipher suites.  This MAY lead to a reduction of
> interoperability.  It is likely that, in time, the cipher
> suite specified here
> will become subject to attack and the use of it will too be
> deprecated.
>
>
> _______________________________________________
> Syslog mailing list
> Syslog@list...
> https://www1.ietf.org/mailman/listinfo/syslog
>



_______________________________________________
Syslog mailing list
Syslog@list...
https://www1.ietf.org/mailman/listinfo/syslog