My observation about ciphersuite: 1, TLS wg can do a better job on ciphersuite selection than a profile developer. 2, TLS specification will be updated if the mandatory cipher is too weak to provide appropriate protection, but profile-specific suite may not be updated accordingly. 3, Before TLS mandate a stronger cipher suite, TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog application. If a operator want a stronger cipher suite for highly sensitive syslog application, he still has the freedom to specify one, mandatory cipher suite is only MUST to implementer rather than operator.
So, my view is ciphersuite is not neccessary to be defined in this specification, and it is not good to specify in this specification. Thanks, Miao > > > > Tom and I discussed this issue on the mailing list. TLS > protocol has > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > specification says that if application profile(syslog-tls in this > > case) does not specify a mandatory cipher suite, TLS > mandatory suite > > will apply. So, no need to specify one in this specification. > > Ahh... that was the message I did not find in the archive. > Thanks for bringing it up again. That obiously solves the > interop problem. However, I am still of the view that we > should advise operators to use strong suites in the security > considerations section. > > <tp> > > I raised it because I wanted a cipher suite spelt out in the > I-D rather then leaving it as an exercise in ingenuity for > the reader to find where it is specified. The pro and con of > not specifying it in our I-D is that as the views in the > security community change (and some would regard the default > as too weak - eg US government) so the mandatory to implement > is changed for us without us noticing. > > Tom Petch > > ___ _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
