Greetings. Other than the issue I pointed out today, it looks like we're done with protocol and transport-udp. Once that issue is resolved I can approve both of these documents and send them to the rfc-editor.
However, in your discussions with the transport area directors you made some changes to the protocol document that have implications for the tls document. Curently, the tls document is awaiting revisions to address my latest round of comments. I'd like the working group to think about the implications of changes to protocol when revising the tls document. In particular, you are now recommending that the tls transport be used in most situations in preference to the udp transport. As a consequence, that means the tls transport is no longer just for security sensitive applications. So, the TLS document needs to reflect this wider applicability. In particular, I definitely expect it to work in cases where senders do not have certificates. The working group also needs to think about delployment issues surrounding trust anchors. You need to either convince yourselves that getting appropriate trust anchors onto devices will not be a problem in these situations or provide mandatory-to-implmenet semantics when trust anchors cannot be provided. One possible solution would be a mandatory-to-implement mode where the tls transport does not protect against active attackers and certificates are not checked on either side. If explicit security configuration is available then certificates can be checked providing defense against active attack. there are other possible solutions as well, depending on what the working group believes is appropriate leves of configuration. I just want you to actually produce a protocol that will be easy to deploy because that will be important given its expanded applicability. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
