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:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 12:13 PM > To: Miao Fuyou; 'Rainer Gerhards'; [EMAIL PROTECTED] > 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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
