Re: [Syslog] Towards closure of syslog-tls issues
Chris I agreed (mostly) with the actions in your e-mail but do not see them all reflected in -05. See inline Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: Miao Fuyou [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered This I see, at least the latest RFC part - note that the latest ciphers and their relative strengths may be found in BCP86 This I do not see and would like to - note that implementors and deployers should keep aware of current literature Likewise, this I do not see and would like to (This should be about 3 sentences.) snip Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Towards closure of syslog-tls issues
Hi Miao, I agree that these should be in the ID before submission to the IESG. Please make these changes for version -06 and submit to the ID Editor. Once these are in I will submit to Sam and the IESG. Go ahead and take care of the other minor nits that are pointed out in the shepherding document for -05 as well. Thanks, Chris On Thu, 30 Nov 2006, tom.petch wrote: Chris I agreed (mostly) with the actions in your e-mail but do not see them all reflected in -05. See inline Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: Miao Fuyou [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered This I see, at least the latest RFC part - note that the latest ciphers and their relative strengths may be found in BCP86 This I do not see and would like to - note that implementors and deployers should keep aware of current literature Likewise, this I do not see and would like to (This should be about 3 sentences.) snip Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues
Tom, -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 12:18 PM To: Chris Lonvick; Miao Fuyou Cc: [EMAIL PROTECTED] Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and RFC4681 as rfc-index states; the last does not include RFC4507, which I would. However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the PRF (away from MD5) inter alia and calls it TLS v1.2. IMO, that I-D is too far away from completion to be worth waiting for but, in the sentence that notes that implementors and deployers should keep aware of current literature I would include a reference to include ongoing work in the IETF on TLS. I am not sure here, but I think any reference to ongoing work will put the I-D to a hold. The reasoning is that any draft expires and after at most 6 month there is nothing left that could be referenced. If I am right with this opinion, I consider it better not to mention any specific effort. I also think that the text Miao proposed should be sufficiently enough to alert an implementor (and operator) to watch for further references. Just my 2 cts... Rainer Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: Miao Fuyou [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues Hi Miao, On Mon, 27 Nov 2006, Miao Fuyou wrote: Hi, Unfortunately (or fortunately), there are several issues raised after the chair start shepherding process. As the editor, I would like close the issues as soon as possible, and get the doucment updated. 1, Version. The wg seems have concensus on removing version from the transport mapping this time. If there is a objection, please reply. If no, I would remove it. Please remove the version. We have consensus to do this. Tom Petch does raise an important point that I will bring up to our ADs. Essentially, TLS does not have any mechanism to allow for an indication of the contents that it is protecting. This results in the need for separate ports for implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples of other secure transports) are able to embed an indication of the payload within the transport protocol and reuse their ports. To that end, even the byte-count is a bit of a problem, but we'll live with that. Remove Section 6.2 as well. 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I tend to accept the proposal. Please comment if you have a different idea! Go ahead and remove that reference. 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered - note that the latest ciphers and their relative strengths may be found in BCP86 - note that implementors and deployers should keep aware of current literature (This should be about 3 sentences.) 4, ABNF issues. I will change format back to %d format. OK 5, Receiver authentication when confidentiality is concern, from MUST to must, and probably some more sentences about receiver authentication is required. OK Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris Please feedback if you have different ideas to the proposals above! Thanks! Regards, Miao ___ 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
Re: [Syslog] Towards closure of syslog-tls issues
Hi Miao, On Mon, 27 Nov 2006, Miao Fuyou wrote: Hi, Unfortunately (or fortunately), there are several issues raised after the chair start shepherding process. As the editor, I would like close the issues as soon as possible, and get the doucment updated. 1, Version. The wg seems have concensus on removing version from the transport mapping this time. If there is a objection, please reply. If no, I would remove it. Please remove the version. We have consensus to do this. Tom Petch does raise an important point that I will bring up to our ADs. Essentially, TLS does not have any mechanism to allow for an indication of the contents that it is protecting. This results in the need for separate ports for implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples of other secure transports) are able to embed an indication of the payload within the transport protocol and reuse their ports. To that end, even the byte-count is a bit of a problem, but we'll live with that. Remove Section 6.2 as well. 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I tend to accept the proposal. Please comment if you have a different idea! Go ahead and remove that reference. 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered - note that the latest ciphers and their relative strengths may be found in BCP86 - note that implementors and deployers should keep aware of current literature (This should be about 3 sentences.) 4, ABNF issues. I will change format back to %d format. OK 5, Receiver authentication when confidentiality is concern, from MUST to must, and probably some more sentences about receiver authentication is required. OK Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris Please feedback if you have different ideas to the proposals above! Thanks! Regards, Miao ___ 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
