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. 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
