I would recommend against constraining the key management in -tls-. This is a POLICY decision, not a protocol decision. (as highlighted by RFC4107)
John > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 10:14 AM > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; [EMAIL PROTECTED] > Subject: RE: Relays was Re: [Syslog] AD Review > fordraft-ietf-syslog-transport-tls > > Hi WG, > > [speaking as co-chair] > > As co-chair, I will need to advise Miao to remove support for generic > certificates unless there is overwhelming WG consensus to keep them, > and the explanation of why reuse of private keys is necessary will > need to be compelling. Please read RFC4107 (which is short). > > There are ambiguities in the TLS document regarding who MUST > authenticate that will need to be tightened up. As the email from Tom > reflects, part of the problem is the ambiguity in the definition of > relay; I think it needs to be made clearer in the -protocol- document > that a relay is a receiver and is a sender, and clearer in the -tls- > document that authentication is hop-by-hop. > > Personally, I think we should make authentication more mandatory than > is currently described, but the WG needs to reach such a consensus. If > we keep the optional authentication(s), then the WG should justify in > the document why it makes "protocol sense" for the authentication(s) > to be optional. > > The WG needs to develop the table showing how the various > authentication options mitigate threats, especially MITM threats, and > we should have text that describes this as well. > > Please work with Miao to address these issues. > > Thanks, > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > co-chair, Syslog WG > > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 31, 2007 12:53 PM > > To: Miao Fuyou; 'Sam Hartman'; [EMAIL PROTECTED] > > Subject: Relays was Re: [Syslog] AD Review for > > draft-ietf-syslog-transport-tls > > > > <inline> > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Miao Fuyou" <[EMAIL PROTECTED]> > > To: "'Sam Hartman'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Wednesday, January 31, 2007 5:50 AM > > Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > Hi Sam, > > > > > > Thanks for the review! My response is inline. > > > > > > Regards, > > > Miao > > > > > > > -----Original Message----- > > > > From: Sam Hartman [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > I do have some concerns with the TLS draft. > > > > > > <snip> > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > use that certificate? > > > > > > > > > > It is not required, but it is preferrable for some deployment > where > > > malicious senders may send lots of messages to overwhelm > > the receiver. > > > > > Sam > > > > I have a slightly different view. To quote the I-D, where it says > > "The sender/relay should initiate a connection to the receiver" > > I take that as the sender initiates a connection to the > > receiver if no relay is > > present or to the relay (when present), the relay (when > > present) initiates the > > connection to the receiver (collector). Relay and receiver > > become TLS Servers > > and insofar as TLS Servers have certificates, the relay will have > one! > > > > When the next paragraph says > > "When a sender/ relay authenticates a receiver it MUST > > validate the certificate" > > I take that to mean that the sender authenticates the > > receiver if no relay is > > present or the sender authenticates the relay (when present) > > and the relay > > authenticates the receiver. > > > > relay and sender are TLS clients. > > > > I appreciate that this is hop by hop security and not ideal > > end to end security. > > > > Tom Petch > > > > --Sam > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
