----- Original Message ----- From: "David Harrington" <[EMAIL PROTECTED]> To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Miao Fuyou'" <[EMAIL PROTECTED]>; "'Rainer Gerhards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 29, 2007 12:12 AM Subject: RE: [Syslog] transport-tls-11 review
> 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? My substantive issue is the one of applicability, essentially replying belatedly to Chris's post of 15Oct07 which in turn I see as a response to Sam's post of 7Sep07. I think that the new text does not sit well with the old text, that we need to spell out more clearly eg that if you do not have a client certificate, then TLS will not perform client authentication and so unless you are authenticating by another means, there will be no defence against masquerade eg the new section 5 may require us to modify section 3. Also, there are forms of TLS with authentication where no certificates are required and we should cater for those; they may become - I hope - quite widespread. I know - it would have been better to have made these comments in October:-( Tom Petch > > 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
