This looks like a suitable message to respond to:-) Yes, Joe has produced a -12 and yes, I understand the state in the state transition diagram of the RFC production process of where we are at.
Which means we are only changing things that the IESG have raised as problems. So what are these IESG problems that have causes section 4.2 to acquire these Editors Notes? I cannot find a record of what it is that Pasi or Sam did or did not say to cause this. Any one help me? Tom Petch ----- 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 1: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? > > 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 > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
