Thread-index: AcaTi5xhytEuUEfZQZCKwibPxvjz7gAeKT8A
Section 9 of RFC4346 says: "In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA." It is OK to mandate a ciphersuite for application profile(Syslog/TLS). But, note that the ciphersuite you suggested is the same one mandated in RFC4346. Maybe it is not necessary to mandate twice. RFC2818(HTTPS) does not specify ciphersuite. I believe TLS_RSA_WITH_3DES_EDE_CBC_SHA is one of the commonest ciphersuite and satisfies IESG, RFC4346 is relatively new and comes after Bellovin-Rescorla analysis. Server certificate is a MUST for non-anonymous key-exchange in section 7.4.2 of RFC4346, in which the relationship between certificate and ciphersuite is defined. This may the same case to whether ciphersuite should be specified in application profile. > -----Original Message----- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Monday, June 19, 2006 5:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] ciphersuites was > draft-ietf-syslog-transport-tls-01.txt > > Reading this I-D (-02 actually), I seem to recognise wording > from the TLS RFC but, I think, not enough to make clear what > TLS does and does not offer. The I-D talks of strong mutual > authentication, compression and encryption but fails to > mention ciphersuites. Compression is negotiated per se but > key exchange (eg RSA), authentication (eg SHA) and encryption > (eg 3DES-EDE) come as a package, a predefined list of > ciphersuites, and if the combination you want is not > predefined, tough (go write your own RFC). Equally, NULL, > NULL, NULL is a valid TLS ciphersuite, but rather weak on security. > > This may be all very familiar but I think it needs spelling > out because one ciphersuite must be REQUIRED to ensure > interoperability. As the I-D stands, this will be > TLS_RSA_WITH_3DES_EDE_CBC_SHA which, as the name suggests, > calls for a certificate with RSA public key valid for > encryption, 3DES_EDE and SHA. > > Earlier, I queried the support for TLS and was pointed at the > 220,000 hits on Google; my follow up question is, what is the > commonest ciphersuite in use, amongst those secure enough to > satisfy the IESG? (DES40_CBC will not do:-) > > Is this default what we want? SHA is fine for me. > Certificates are not present in all ciphersuites; the I-D > takes them for granted but fails to specify which. > Is encryption always wanted? As I have said before, it is an > irrelevance for the environments I am familiar with (although > I accept it is a requirement for > others) but do we insist it is always present? > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > [EMAIL PROTECTED] > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
